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.

AppGameKit Classic Chat / [SOLVED] box2d physics have anomalies when moving the window [Possible bug]

Author
Message
brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 16th Feb 2021 02:56 Edited at: 16th Feb 2021 03:01
I've been talking about this problem for a few days on discord, and blinkOk recommended me to make a thread about it

I have some problems with box2d physics

Moving the window or click on the title bar causes non-sleeping sprites to behave strangely
like here for example, where the sprite gains negative velocity and starts to jump.
https://streamable.com/czy5xi


and notice that the framerate goes down when you move the window, this could be the cause of the problem

Here is another example where the ball loses speed when the window is moved
https://streamable.com/2nlbjs



happens only in sprites that are not sleeping

I found a temporary solution to this, changing the update() to as fixed value, but this causes problems especially if the hardware running the game is unable to maintain 60fps

as seen here the sprite doesn't jump, and the problem is solved, but this has its bad parts, if the game is running at 30fps

https://streamable.com/bj081v




the cause of this may be because the game loses framerate when the top bar is clicked or moved as MadBit said here https://forum.thegamecreators.com/thread/219478?page=3#msg2662817

The author of this post has marked a post as an answer.

Go to answer

adambiser
AGK Developer
8
Years of Service
User Offline
Joined: 16th Sep 2015
Location: US
Posted: 16th Feb 2021 04:07
Here's my take. Others might know better or be able to explain better:

Quote: "I found a temporary solution to this, changing the update() to as fixed value, but this causes problems especially if the hardware running the game is unable to maintain 60fps"

Or call "StepPhysics(FIXED_FRAME_TIME)", which causes sync to not step the physics based on that frame's rate. By stepping the physics at a constant rate, you guarantee that the physics will behave the same no matter what the render frame rate is.

From the StepPhysics help page:
"Stepping the physics simulation by a large time value (greater than say 0.1) may result in undefined behaviour and physics objects moving through each other."
While the title is clicked, the box moves below the bottom of the window and gets a negative velocity to move it back up. GetFrameTime is limited to 0.2 seconds so it doesn't fly up when you hold the mouse button longer.

More from StepPhysics:
"By using a fixed time step every frame your physics will perform exactly the same across all devices and all frame rates, but a reduction in fps will result in the physics appearing to go slower, as it will always step the same amount of time whether the frame was quick or slow to draw. "

So you can try something like this to maintain a constant physics rate across FPS that are faster:

This separates the physics and rendering so that the box falls at the same rate at 60 FPS and 1000 FPS. 30 FPS will be half speed due to the fixed rate time value. Set your physics to the slowest your game should run, even if the render rate is faster.
Also, the physics and render rates don't have to match.
brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 16th Feb 2021 14:21
that is in fact a better solution than i have

however i cannot set the stephysics to 0.0333 (30fps), joints have many problems when running at low framerate, they just don't work

the joints start to break and do things they shouldn't, for example this
https://streamable.com/tjeoqh


definitely having a fixed value for step physics is the best idea, because SetSpritePhysicsmpulse depends entirely on the framerate
but unfortunately if the game is running at 30fps with fixed frametime of 60 everything is in slow motion
and I can't set the frametime to 30 because joints don't work at 30
adambiser
AGK Developer
8
Years of Service
User Offline
Joined: 16th Sep 2015
Location: US
Posted: 16th Feb 2021 14:42
Maybe try stepping physics twice with 0.016667 instead of once with 0.0333? Larger steps can become more erratic because objects can move farther during the larger time period.
brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 16th Feb 2021 15:26
but doesn’t that speed up physics more if the framerate is more than 30?

changing SetPhysicsGravity and SetPhysicsScale can fix this, i think

brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 16th Feb 2021 15:32 Edited at: 16th Feb 2021 15:34
I think I have an idea
it is very unlikely that the game will run below 60fps regardless of the machine (if they are modern)

but if it runs lower, it will be at 30fps, for example on a laptop when the battery is not charging (for example, from HP), all games will be played at 30fps
so I can detect if the game is at 60 or 30 and change the times it passes through the stepphysics, if it's 30fps, do it 1 time, if it's 60fps, do it 2 times
adambiser
AGK Developer
8
Years of Service
User Offline
Joined: 16th Sep 2015
Location: US
Posted: 16th Feb 2021 15:37
Then you lose the benefits of a constant physics step.

brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 16th Feb 2021 16:08
now the physics are at the correct speed regardless of the framerate

but, sprites that use SetSpritePhysicsImpulse or SetSpritePhysicsVelocity stutter a lot, but it only happens if above 30fps.
brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 16th Feb 2021 17:47 Edited at: 16th Feb 2021 18:44
it seems that the problem comes from here, the ViewOffset, that follows the character in the middle of the screen
this only happens above 30fps



changing the smooth variable to something smaller removes the stutter but stops following the character correctly


adambiser
AGK Developer
8
Years of Service
User Offline
Joined: 16th Sep 2015
Location: US
Posted: 16th Feb 2021 21:04
I'd have to see more complete code (a small example project) to see what I can figure out.
brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 17th Feb 2021 01:34
I made here an example of what is happening


adambiser
AGK Developer
8
Years of Service
User Offline
Joined: 16th Sep 2015
Location: US
Posted: 17th Feb 2021 02:25
This post has been marked by the post author as the answer.
Try moving all physics-related stuff into the block where the physics is stepped, and only call StepPhysics(PHYSICS_STEP) once.

brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 17th Feb 2021 03:26
it's great now!! Thanks a lot for the help!
I am not seeing any problems so far.

if someone in the future has the same problem I will leave the code here with the complete solution
adambiser
AGK Developer
8
Years of Service
User Offline
Joined: 16th Sep 2015
Location: US
brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 4th Mar 2021 14:58
is it possible to change RENDER_FRAME_TIME and PHYSICS_STEP to higher values ​​for the physics to be smoother?
I have tested with some values ​​but with no good results

the way it is, the physics are always locked at 30fps, which is good because it solved the previous problem.
But sprites with physics are not as smooth as sprites that have no physics

and I found that joints don't have the same behavior that they do at 60fps
joints at 30fps don't work very well
adambiser
AGK Developer
8
Years of Service
User Offline
Joined: 16th Sep 2015
Location: US
Posted: 6th Mar 2021 20:35
I haven't messed with the sprite physics much more than I have for this thread. I think you can try out whatever values you want to determine what works best for you.
brunuu
5
Years of Service
User Offline
Joined: 4th Jun 2018
Location:
Posted: 22nd Mar 2021 19:19
I will leave this in this Thread, in case someone in the future has this problem

I found that this can also solve the problem of physics that behaves strangely when the window moves

if GetFrameTime() > 0.1 then StepPhysics(0)

but it will not make physics independent of the framerate, for that I recommend the adambiser solution

Login to post a reply

Server time is: 2024-04-19 20:24:15
Your offset time is: 2024-04-19 20:24:15