One utterly painful feature of the bge is how the games speed adjusts to the framerate. So for example if I have a property constantly counting upwards, at 200 fps it will add numbers to the property far faster than it would at 100 or lower. What this means is when a game lags the whole thing not only plays fundamentally differently, but also makes the actual lag that much more unbearable. How does one disable this feature.
delta time. blender has some time related functions in the logic module.
- Use the timer property, which counts upwards at 1.0 per second
- Make sure your game always runs at 60FPS…
I have it locked at 100 but occasionally it dips below
How would one implement this, i don’t really know anything about coding.
So I think I’ve found a fix. Under the world tab under physics is something called world steps, increasing this apparently forces the engine to more accurately sync up with realtime.
Are you counting the time or are you counting events?
He wants whatever changes that happen over time to be normalized regardless of whether the framerate drops or raises…
like moving an object multiplied by the time it takes to draw one frame…is my assumption…frame_time? I would like to see how this is done as well…
I guess you can get the time it takes to draw each frame and get an average(mean)value and multiply whatever you are doing by that average…just a guess…I have not thought much about it…
I do miss the ‘* Time.deltaTime’ method in unity 
@JustinBarret:
Create your own deltatime by running this once every frame. Eg:
import bge
def update_time(cont):
if 'prev_time' not in cont.owner:
cont.owner['prev_time'] = bge.logic.getFrameTime()
current_time = bge.logic.getFrameTime()
cont.owner['delta_time'] = current_time - cont.owner['prev_time']
cont.owner['prev_time'] = current_time
#monster, don't kill me (much) for this:
bge.logic.deltaTime = cont.owner['delta_time']
Better yet, instead of storing it in bge.logic.deltaTime, write a scheduler, or store it in the outermost layer of abstraction for your game.
Or if you’re feeling estoric, here’s another one where you just have to run the init function, and then deltaTime will work until the scene ends.
import bge
def init_time():
bge.logic.getCurrentScene().post_draw.append(_update_time)
bge.logic._prev_time = bge.logic.getFrameTime()
def _update_time():
current_time = bge.logic.getFrameTime()
bge.logic.deltaTime = current_time - bge.logic._prev_time
bge.logic._prev_time = current_time
If you get even more devious, you can make self perpetuating scene pre-draw callbacks so it survives scene transitions…
Pal I hate to break it to ya… but you might as well be speaking spanish. I don’t know bupkiss about coding.
I’m sorry…not trying to be offensive in any way, but you will be very limited in what you can accomplish in the GE without some coding…
…just take it slow…think of the first thing you want to do e.g. move your player…then do a google search ‘BGE move object’ or something…do some home work, and if you fall flat on your face come back here and ask a question…
There is no problem in asking questions, every one here is very helpful…I ask at least once a week, and get a response fairly quickly…but not trying first is generally frowned upon everywhere you go…if you just need a simple function like ‘move’ or some thing…just ask.
Quite frankly, we don’t have enough information to help.
If you increment a counter every frame, then yes, you will have framerate lock issues. But if you use the timer property instead, then you won’t. The timer property counts upwards at 1 per second (and 0.16 per 60hz frame, and it accommodates frame drop properly etc. It is the TIME).
So what is your exact issue? This is more of a design issue, and there is no magic “make it not framerate dependent” button if you have things tied to per-frame counters.
How about this: Don’t have a hard dependency on tick rate. This isn’t a BGE issue, this is a programmer issue.
If, for some reason, you still want to count upwards using frame rate (which is stupid, don’t do that), you need the live tick time, the live tick rate and you need to do some math.
Example:
If you want to count to 100 in 1 second, and you’re running at x frames a second, your tick time is 1/x. Meaning you need to increment your counter by (1/x*100) if you want to count to 100 in 1 second.
This seems exactly like an XY problem.
I’m not offended, but as I said before I managed to find a solution that works perfectly fine. In essence to better explain the issue I had, Imagine I have a game running at 60fps every 2 seconds an object hits the floor. If for whatever reason the framerate drops to 30fps the entire game would run slower. So instead of the objects hitting every 2 seconds they might only every 4.
Furthermore aside from potentially a saving mechanic which I will look into I don’t really need coding for the project. The logic editor is fine for what I’m doing. Its not that I don’t want to learn to code, I will, but my focus right now is finishing the project rather than diverting my focus to other things, such as learning to code.
I’m not offended, but as I said before I managed to find a solution that works perfectly fine. In essence to better explain the issue I had, Imagine I have a game running at 60fps every 2 seconds an object hits the floor. If for whatever reason the framerate drops to 30fps the entire game would run slower. So instead of the objects hitting every 2 seconds they might only every 4.
Then how are you launching the cubes? Specific details.
The physics engine is framerate independent (mostly) so you shouldn’t be having issues there: ie at 30FPS and 60FPS, gravity will still pull an object down at 9.8 meters per second.
The issue with lags is that precision gets lost. The physics will calculate the effect between two frames. As less time between the frames is as more precise the result will be (and vice versa).
When your system results in lags it means the time between the lags will increase which will result in less precise physics calculation. You can’t compensate e.g. be calculating the frames in-between as … there are lags the system is already busy.
Lags mean the system is not running as it should be. The game experience will not be as expected.
You do not need care the lagging situation that much, better invest to avoid lags.
As far as I remember, this is an old issue of bge, it depends on how the main loop does time computation for the physics update and yap, the faster the framerate, the faster physics related stuff happens.
There is a test one can do to prove that (and also check that the bug is still there): create a scene with a box dropping on a floor, set the framerate at 30 and measure the time it takes for the box to fall, set the framerate at 100 and repeat the measurement. The second test should complete in less time.
Perhaps the problem - which is monumental - has been fixed in upbge (possibly in a more sensible way than my fix, which basically threw away the entire game loop and the animation recording feature :D).
I was merely giving an example. My game has a lot more going on than just a few cubes.