Jump to content

How to get the velocity of an object based upon local FPS?


WombatTurkey
 Share

Recommended Posts

For example if you have something like this for player movement (WASD): Strife to the left

var pMoveSpeed = 700;

PlayerSprite.body.velocity.x = - pMoveSpeed;

 

If you have around 20 FPS (game.time.fps) the character is obviously not going to move that fast. How can I tell how fast a character is moving based upon a 60 FPS threshold? If that makes sense..? 

If you do:

setInterval( x=>{
console.log(PlayerSprite.body.velocity)
}, 100)

Even if you have 20 FPS, it will still show -700.  I'm horrible at Math, but just curious if this is possible

 

Link to comment
Share on other sites

I'm not sure I'm following at all.

What does subtracting one value from another have to do with FPS? From the examples, the answer will always be the same.

If you decouple your logic update from your refresh rate then things get simpler, as I think you know, and if you go further and fix your logic update timestep then things get even easier, plus they become predictable and deterministic.

It almost sounds like you want your simulation to know about how many pixels an entity is moving per frame? Which doesn't really make sense, the simulation doesn't care how many pixels an entity is moving, its only interesting in the simulation not the render.

How much an entity moves per 'tick' should not really be dependent on FPS (it can be, but then its a game loop from a NES), it should either be dependent on a timestep or on the actual time i.e. if it takes an entity 1 minute to move 1 mile in your simulation then thats how long it takes, it'll just be rendered many more times within that minute at higher fps.

Link to comment
Share on other sites

Hmm. Thanks Matt,  I might be doing this wrong then? :P

I am sending a signal off to the server to strife the character left. Once the player releases, another signal is sent notifying they stopped. I send the X, Y positions each time so at the end of the interpolation, the character slowly moves to their intended X, Y position. This allows me to make use of arcade physics within Phaser for multiplayer and works so good. Makes movement so fluid. Works okay if a player has latency lag (as it kind of just interpolates them back slowly) but this is only if it's a US -> Europe connection, US to US even with 100 + ms latency you can barely notice the interpolating.

Problem is now it's not about latency lag, it's client-side lag. While sending the strife signal along with the X,Y values to interpolate (at the end), the player who has in-game graphics lag doesn't move the same as someone who's client is running 60fps, so when the strife LEFT signal is sent, they are moving based on 700 velocity, but get interpolated back because they are not really moving that fast. I just lost myself writing this, but here is an example:

Good:

11c2db14296286b161477818e07e9e5e.gif

 

Now with clientside lag:

24cb5db7489c96e18b1dad38d17f8465.gif

 

Notice the 20 FPS on the top left

Now, if somehow I can get the client to send how fast the character is moving while having GPU lag then the  pMoveSpeed will match that player, thus, when sending that strife signal it will move based upon their FPS (and won't jump back because the velocity matches their FPS) 

I tried this algorithm while sending the players FPS over the pipe:

pMoveSpeed = (700 / 60) * PlayerFPS

Which kinda works, but it's still 100 velocity off, so the characters still jump a bit.   

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...