I’m asking out of curiosity - this is not a suggestion.
Why is the Average Frame Rate independent from the Logic Tic Rate?
I was recording a test video for a project with a frame rate limiter at 30fps, and tell me if this isn’t odd:
The average frame rate was limited to 30fps but the logic tic rate stayed at 60fps. So it seems like the average frame rate ignores the logic tic rate. Why?
This really screws with you if you have a lot of frame based events because the game is shown at 30fps while the logic is being updated at double that. In other words, if you use framerate to count seconds, since the logic updates faster, it would actually count two seconds in the span of one second.
There are things that are frame rate dependent though. (well logic tic dependent now I guess)
I used a simple example for the purpose of explanation but consider this (still a simple example, but it’s better for the explanation):
There is a ray that detects the ground and snaps you to the ground when you’re close to ground. The interval in which the player snap to the ground is 0.1BU - pretty small. So once the bottom of the player gets 0.1BU from the ground he snaps to the ground.
If we don’t touch the framerate at this point, things go wrong. If a player falls from a high place, the displacement of the player between frames gets higher and higher. This is fine if your game is running at 60fps, because the displacement is still small between frames. But what if there’s a drop by 30 frames? Someone’s computer can’t go the full 60fps maybe.
The displacement of the player when falling is doubled, and the small 0.1BU interval could be missed causing you to fall through the ground. Now, you could increase the size of the interval in an accelerated matter by somehow making it bigger depending on the velocity, but even then, at semi-low frames, this gets messy.
Not to mention there’s no way to increment animation frames without taking into account the framerate, and you need to do this because the BGE API offers a crappy action-playing-system for python. It either forces you to use like 100 action actuators or to hack your own action system if you want to edit actions on the fly.
Luckily, making this stuff dependent on Logic Tic Rate fixes most problems since that’s what actually matters when making calculations every frame.
So I don’t think it’s lazy… I think it’s sometimes necessary - logic tics at least.
This means this is the frame rate you actually see (on your monitor).
It is not:
the frame rate you want to see
the target frame rate you set up in the configuration
the animation frame rate
the frame rate the logic is running on
the frame rate the physics is running on
In general, the rendered frame rate drops, when the time limit for one cycle of the game loop exceeds the limit.
Typically the rendered frame rate should match the target frame rate (60fps).
If the game loop is faster it will wait and everything is fine.
If the game loop is slower the BGE will blame rendering. The BGE skips rendering up to 5 times. It tries to stay within the time limit (1/60) with this method. The logic and physics keep their frame rate while you do not see any updates on screen. This is the fallback scenarios.
Recording a game, adds very high pressure on your system. This can easily lead to the dropped frames (and frame rate).
I looked at the code. It seems that it is called “average” because all times spend within a frame (e.g. logic, physics, render) are added to determine the complete processing time of the current frame.
The rate is 1/processing time.
m_average_framerate = 1.0/tottime
(source=KX_KetsjiEngine line 533)
Edit: it is average as the tottime is the sum of the average of each single component. Means they are measured over time. Just now I do not know how much measurements(frames) that are.
I’ve complained about this numerous times. Look at my profile’s started threads.
Games should always be tic dependent, not frame rate – that way a PC that runs at 30fps doesn’t play the game at half the pace of a machine that can do 60fps. It prevents inconsistency in physics and logic.
You can do something about it for non-physics games in bge:
from bge import logic
fps = logic.getAverageFrameRate()
fix_fps = fps if fps > 1 else 1
#you cannot use min() with logic.getAverageFrameRate() for some reason.
logic.tic = 1 / fix_fps
logic.setLogicTicRate(fix_fps)
Then multiply the speed of everything by logic.tic.
Anyone have any data or experience on how this affects animations? I’m thinking of using the restrict animation updates check box and around a 30fps animation rate (it’s fine for the human eye, you can tell the difference, but it’s not noticeably jerky or anything).
This cuts my animation drain in half, and maybe more, but I’m a little worried about how slowdown might affect animation speed. I’ve already noticed that setting the animation rate to different values changes the speed of the animation playback (instead of just skipping frames which would be preferable).
I do not expect any performance changes on changing the animation frame rate.
Reason:
The animation frame rate tells how long it takes to play a single animation frame.
The default the animation rate is 24 while the default logic frame (and render) frame rate is 60.
This means one animation frame lasts 0.416 seconds while one logical frame lasts 0.0166 seconds.
The consequence is that the animation proceeds 0.4 animation frames per logic frame (24/60).
You can compare that by playing the same action at two objects. Play one object with in automatically in play mode and play the second in property mode by increasing the property (by 0.4).