Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / Can built-in physics speed be matched to the real program performance speed?

Author
Message
AK
1
Years of Service
User Offline
Joined: 13th Feb 2017
Location: NZ
Posted: 13th Feb 2018 00:17
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?
Bengismo
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 13th Feb 2018 08:57 Edited at: 13th Feb 2018 08:59
Call this...

StepPhysics( time )

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

PHeMoX
User Offline
Joined: 9th Jan 2018
Location:
Posted: 14th Feb 2018 00:07
Quote: "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.
AK
1
Years of Service
User Offline
Joined: 13th Feb 2017
Location: NZ
Posted: 14th Feb 2018 08:35
Ohhhh, excellent. Thank you!
Bengismo
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 14th Feb 2018 08:46
PHemox wrote: "
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. "


From the documentation

Quote: "By using a fixed time step every frame your physics will perform exactly the same across all devices and all frame rates, but a reducuction in fps will result in the physics appearing to go slower, "


The question was about making it MATCH real time so ...No you cant
PHeMoX
User Offline
Joined: 9th Jan 2018
Location:
Posted: 17th Feb 2018 17:58 Edited at: 17th Feb 2018 17:58
Quote: "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:

Quote: " 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. "


From the documentation:

Quote: "For example if your game depends on a physics entity falling and bouncing to the same height each time it is run then you should use a fixed time step. If the position of physics objects is not important to you game logic then a variable time step may be best. "


Also, I am pretty sure the engine itself already does something like StepPhysics( GetFrameTime() ) with each Sync() or Update() internally.
Bengismo
User Offline
Joined: 20th Nov 2017
Location: Yorkshire, England
Posted: 17th Feb 2018 18:21 Edited at: 17th Feb 2018 20:10
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!
PHeMoX
User Offline
Joined: 9th Jan 2018
Location:
Posted: 17th Feb 2018 18:57
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.

Login to post a reply

Server time is: 2018-09-20 09:21:37
Your offset time is: 2018-09-20 09:21:37