Physics and vsync / different refresh rates

Post reply
0 favourites
  • 12 posts
From the Asset Store
Visual Novel Anime Music Pack
$19.99 USD
This music pack covers differents situations for visual novels, anime games and many more!
Audios_With_Love's avatar
Audios_With_Love

  • I know this has been discussed before, but it seems that no satisfactory solution has been found. I know about frame rate independent settings and all that

    Anyway, I only have 60hz displays to test right now and of course it works fine, but I know that it does not work fine on let's say 144hz, not even close. Not doing anything complicated, just launching a ball in certain direction by applying force at angle.

    On a 60 hz monitor it goes fast, on a 144hz monitor it barely moves ( not using gravity either, physics world gravity is 0 so nothing to slow it down other than the refresh rate ).

    In testing trying/changing to Unlimited ( fullframes ) in project properties if I calculate the frame rate and then multiply the force applied by fps/60 it seems to work OK, but since frame rates are all over the place it gets a little janky.

    I am hoping that this would be smooth on a real 144hz display because fps would be steady 144, and a simple solution

    Example. I apply force of 400 in certain direction/at angle this works fine v-synced at 60hz

    if somebody plays it on a 144hz monitor force applied would be 960 ( 400*(144/60 ) )

    Does that make any sense?

    I'm working 1/2 blind until I can test it out myself on a 144hz monitor, but it seems to work when testing with unlimited frame setting

  • It should just work. The default physics stepping mode is 'Framerate independent' which uses delta-time time steps. You don't need to change any physics forces or settings, the physics engine just uses time steps to match the framerate. I tried the 'Physics catapult' example and it works pretty much identically to me at both 60 FPS and in unlimited framerate mode running at something like 6000 FPS.

    You can set the physics stepping mode to 'Fixed', but then you get framerate dependence issues, i.e. it will go faster with a higher display refresh rate.

    The main downside with framerate independent physics is it's not a deterministic simulation. As delta-time is based on clock readings which have tiny amounts of variance, the simulation is not guaranteed to go exactly the same way every time. Different display refresh rates will also use a different time step and that can also introduce another source of non-determinism. You may have to design levels and such with some tolerance to allow for variance in the simulation.

  • I thought so too, but it does not work as expected.

    Can you try this version https://www.deusx.com/volley-master/

    When you kick the ball at 60 hz it works as expected, but I saw some people playing at high refresh rates and it just bounces a little without reaching the goal ( Then I tried with unlimited frames and yeah, got the same result.

    Ball uses physics in x,y only, gravity is disabled. I coded my own gravity with z-elevation, but that should not affect the actual physics

    Ok, I linked to the published version

  • Maybe you are using apply impulse every tick instead of apply force or using apply fore only once instead of apply impulse.

    Or you are multiplying by dt in apply force, which already calculates dt itself...

    There are many ways you can add framerate dependency with your implementation.

  • No, it's as simple as can be. Apply force at angle when player kicks the ball.

    Because I had to simulate gravity myself, I had to simulate drag and slow the velocity slightly as it flies, but I tested without that line of code, same thing.

    There is absolutely nothing being applied physics wise to the ball once it's kicked and moving.

    But you may have provided a solution . Using impulse at angle instead of force produces similar results. Sort of a WTF moment for me Shouldn't either way work the same at different frame rates? Why is one more consistent than the other at different fps?

    I guess I should have been more careful in differentiating those two. I'm testing it and impulse seems to work so far

    Thanks

  • right it should be apply impulse instead of apply force as apply force automatically applies dt. It should be used when you continuously apply the force for a period of time. Apply impulse is intended for one off stuff like kicking a ball

  • One of my testers noticed that my framerate independent physics based game was running slowly (or at least parts of it were) on his 120Hz iPad Pro. Fortunately I guessed that this was because I was applying an impulse to some of my objects, so changed to applying a force and all is good now.

    I'd need to do some more testing - likely build a minimal test app - but to me it looks like impulse doesn't work correctly with framerate independence/non-60Hz screens/changing time scales - I'm guessing all these issue are related?

  • Not sure. With my game it was/is opposite. I was using force and it worked great on 60hz, but got screwed up with higher refresh rates. Changing to impulse seems to have fixed it. It may vary slightly, but is fine. With applying force it was unplayable.

    Impulse should be applied just once when you hit something ( as fedca mentions above ). Maybe you were applying it every tick?

  • Impulse should be applied just once when you hit something ( as fedca mentions above ). Maybe you were applying it every tick?

    Sorry, should have said - yes, I was.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • The 'Physics catapult' example uses an impulse to catapult the player-controlled character. It looks like it works for me the same at 60 FPS and ~6000 FPS (100x faster). So it looks to me like impulses are working correctly even at substantially different framerates.

  • How long are you applying the force for (in seconds)? Or is this a one-tick force and not a force applied over time? I think you're probably applying force over time, but I can't be certain from your question.

    Box2D compensates for framerate by modifying the each-tick result of an applied force depending on delta time. The idea being that, when a force is applied over a period of time then the change in velocity will always be the same no matter what the frame rate. This is a way to measure impulse, which is why applying an impulse to an object is framerate independent so that the velocity change is always the same.

    Whether you are applying the force in one tick or over a period of time, this means that:

    If you are applying a force over time, do not change the magnitude of the force.

    If you are applying the force in one tick to cause a desired change in velocity, do not use a force - apply an impulse instead.

  • I tried the volley master link while running at 174hz and it seems to be playing fine for me.

Post reply
  • 12 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)