Jump to content
  • Advertisement
Sign in to follow this  

Syncing issues: frame rates, floats

This topic is 4815 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I suppose this is technically a networking issue, but I also plan to do it using a replay system that wouldn't involve any network code at all. I have a good skeleton code set out and it's time to begin filling it out. The choice I make now is going to hugely impact how I go about designing things from here on out. My game depends religiously on keeping its users in sync. If one of them decides to try some shady activity it will notice the desync and disconnect, but little issues within the game itself could end up causing it unintentionally. I will start with the typical game loop. It goes through, calculates the time between this frame and the last, does some frame based movement, does the next frame, etc. That will (for the most part) reproduce the same actions every time it's run. The problem comes when collisions and frame rates are added to the mix. Say two balls are heading right towards each other. Computer A is cruising along at 73 frames per second. Computer B is running like a snail at 18 frames per second. Computer A will sense the collision, do some physics off of it, and move on. Computer B will do the same thing - but - because of the frame rate difference it will find the two balls overlapping a different amount and handle the collision differently. Two collisions would be relatively easy to fix. I could just backtrack along the vectors, find the exactly collision point and go from there. However, things aren't so simple once three, four, five, or even more objects are involved in the mix. With five I would need to find the first collision that happened. This would then change where the other three are. I would then check for more collisions, backtrack to fix, repeat a few times, and finally would have the system. That seems incredibly clunky to me. I toyed around with the idea of doing this sort of game "physics" locked at 15 frames per second. That would "solve" the problem, but I've never been a fan of a locked frame rate. The alternative would be doing an entirely vector based collision system. Unfortunately I wouldn't know where to even begin with that once several objects become involved at once. -------------------------------------------------------------------------------- The other problem I anticipate is with floating point numbers. I read a post many months ago talking about a problem with a pool game. Different processors were rounding floats differently, causing normally insignificant differences to compound, eventually throwing the game off completely. There are two ways around this. One would be to round every float off to .001 or so so that these minor errors would disappear. However, there's still the possibility that the number could end up right on the border of the round threshold and the numbers could turn out differently. A bug that obscure would be impossible to track down when it did happen. The other option would be to restrict everything to integer math. While it would always give the same results, it would be a pain to go about doing some things with it. -------------------------------------------------------------------------------- If anyone has ever done something like this before I would love to hear how you solved these problems. I've been through many code rewrites to get to the beautiful structure I have now. I'm hoping the solutions will fit into it, but I can make a little room if necessary.

Share this post


Link to post
Share on other sites
Advertisement
You must separate the display update from the game logic update. Each side displays the game as fast as it can, but both sides update the state of the game at a fixed rate which is kept in sync.

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
You must separate the display update from the game logic update. Each side displays the game as fast as it can, but both sides update the state of the game at a fixed rate which is kept in sync.

That was the method I described with fixed frame rate, and it's something I already do. It's just I really don't like the idea of estimations like that. I suppose it's the simplest and fastest way though.

(Side issue: This would be a good application of multiple threads, but it would make it a little more complex. None of the data would get corrupted if it was rendered in between updates, but things might appear distorted. The other option would be checking the time between renderings and updating if the time elapsed since the last game update is more than the interval. This would remove the threading but might cause a stuttering effect when rendering.)

Even with that out of the way, I'm still going to have problems with the floating point numbers.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!