WombatTurkey Posted June 23, 2016 Share Posted June 23, 2016 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 More sharing options...
mattstyles Posted June 23, 2016 Share Posted June 23, 2016 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. drhayes and WombatTurkey 2 Link to comment Share on other sites More sharing options...
WombatTurkey Posted June 23, 2016 Author Share Posted June 23, 2016 Hmm. Thanks Matt, I might be doing this wrong then? 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: Now with clientside lag: 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 More sharing options...
Recommended Posts