Sorry your browser is not supported!

What I think I'm seeing with the built-in physics of AppGameKit is that it's calculating the physics stuff (movement, collisions, etc) in something like "real time", regardless of how fast the game runs.
But I need it to just use the speed of the game, i.e. not the pre-set value of SetSyncRate(), but the actual value of ScreenFPS() at any given moment. Otherwise, as the framerate slows down, the physics processor skips to keep up with what the framerate should be. But the player can't do that. Their input is bound to the speed at which the program can run, which is ultimately limited by how fast their computer is.

My game is a platformer with a main character whose jump height is determined by how long you hold down the jump key (with an upper limit). Because the character is a physics sprite, the jumping and other input-driven movements of this character use setspritephysicsimpulse(). When the game is running at its maximum framerate, holding down the jump key and not releasing it will result in the "jump" signal being detected for the maximum number of program loops, giving the character the maximum jump height that I intended. But as I put more and more things into the game, or as more and more sprites are spawned, the value of ScreenFPS() starts to drop off, and as a result the "jump" signal is detected for fewer and fewer program loops as the main character sprite moves upward, causing it to fail to reach the maximum intended jump height before the force of gravity causes it to start moving downward again. Running my program in a browser, which slows things down even more, quite noticeably reduces the maximum attainable jump height.

tl;dr = Is there a quick way to make the built-in physics processing match an inconsistent framerate (caused by computer performance), or do I just have to get more efficient at coding so my program doesn't slow down, and/or advise players to have a fast computer?

Call this...

StepPhysics( time )

typically with GetFrameTime() as the argument or the time elapsed since your last frame.

I´m pretty sure you can use a fixed StepPhysics value to get reproducible physics behaviour regardless of fps actually. No need to change it to match GetFrameTime I think.

Ohhhh, excellent. Thank you!

From the documentation



The question was about making it MATCH real time so ...No you cant

No, he wanted a consistent result of the physics, ie. a jump that would always go the same (max) height when holding a key:



From the documentation:



Also, I am pretty sure the engine itself already does something like StepPhysics( GetFrameTime() ) with each Sync() or Update() internally.

The thread tile was leading me towards the idea that the physics step he was using was a constant rather then varying it but I think I see what you mean!

For consistant physics results it is indeed a good idea to step the physics repeatedly with a fixed value (Eg...1mS) so that the physics is calculated consistantly and rounding etc is the same accross systems running at a different FPS.

Typically this involves calculating the frame delta time then repeatedly calling it until the remainder time left is less than your step. This remainder is then added to the next frame time so that no time is lost. So something like this:


This way only a fixed stepsize is called. i originally thought that it was a problem of calling the stepsize with a value that wasnt related to the frame time as it (GetFrameTime()) gets limited to a maximum of 0.2seconds according to the documentation Its never higher than that. Im still not really sure TBH? Well spotted...your right that its more likely that is the case!

Yeah, don't worry about it! I think the issue with his code probably is with how he handles the 'long press equals higher jumping', as that's something much more vulnerable to lower frame rates than the actual physics calculations. You'd need to have a lot physics stuff going on before it will slow down and skip full frames anyway. In fact, speaking of frame rate independent, I was wondering how AppGameKit manages that anyway. As most other game engines require you to multiply by a frame time for calculations that would go crazy with significantly higher (or lower) fps. Not entirely sure though how those manage things.