How do I make my player movement framerate independent

Not favoritedFavorited Favorited 0 favourites
  • 7 posts
From the Asset Store
Basic Rounded Vector Geometry Player Design with Glow for 3 player games
  • I'm using the 8direction behavior on my player object. However, when testing with full framerate mode, or on screen with higher refresh rates, my player goes faster.

    Not as fast as he should considering the jump in framerate, but slightly faster.

    I know I should use *dt somewhere in my formula, like multiplying it by *dt, or 60*dt, but it always produces weird results.

    What I'm doing wrong here?

  • I don't think you need deltatime here. This function sets the movement speed directly. Deltatime is used for changes over time e.g. an acceleration over 1 second. There might be an other event that does something that causes the problem with the framerate dependence.

  • They do. 8 direction is framerate independent as a behavior by itself, but if they set/adjust the vector manually every frame, then it becomes framerate dependent. Multiply the magnitude (sin(movementangle)) by dt*60, or replace 60 by whatever framerate you're testing on that feels like the correct acceleration to you, and it should become framerate independant.

    Edit: Oops! Guess not, sorry!

  • if they set/adjust the vector manually every frame

    Well but the vector is set to a fixed value so deltatime shouldn't matter, right? Deltatime is for acceleration.

    e.g.: Set vectorX to vectorX+acceleration*dt

    But OP does: Set vectorX to value*maxSpeed

    The only factor that changes really might be the movement angle, but assuming the player just holds right on the stick, the result should always be the same value regardless of framerate. e.g. (cos(0) = 1) * (maxSpeed = 300) = 300

    And any change in angle would just register instantly on that tick, not as an acceleration.

  • Setting the behavior vector X/Y directly doesn't need to use delta-time, because those are already speeds in pixels per second.

    Modifying the speeds over time is technically not framerate dependent but only in a pretty subtle way - the shown calculation should be good enough and I don't think it should result in a significant difference depending on the framerate. Perhaps the problem is something else not shown. It's much easier to help if you share a project.

  • So, here's a simple example with only two objects :

    LINK

    When using Vsync, the formula I use produces inconsistent results when using a different refresh rate (The player would move faster at 144HZ than at 60HZ).

    And the difference is quite noticeable on my computer, with almost 2 more seconds to cover the same distance.

    I didn't find a way to fix it, so I just used the "Simulate Pressing" option of the 8direction behavior instead and now the player moves consistently regardless of Hz or fps.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I’m guessing the speed difference is from the deceleration always being applied in the behavior after you set the velocity.

    So at 60fps the speed after deceleration is applied would be:

    300-5000/60 = 216.66

    And at 144fps:

    300-5000/144 = 265.28

    And at unlimited it could in theory approach much closer to 300.

    Which seems to match with what you’re seeing where 144fps makes it go faster.

    You could try setting the deceleration to 0 when you’re pressing buttons, and set it back to 5000 otherwise. Or maybe you could utilize the simulate control action, since I’m pretty sure deceleration isn’t applied when you tell the behavior a control is pressed.

    I guess we could suggest to have deceleration disabled any frame we set the velocity from the behavior itself, but I don’t think that’s a good idea and would result in many more issues so I’d do one of the other two ideas.

Jump to:
Active Users
There are 0 visitors browsing this topic (0 users and 0 guests)