sweetsbeats
commented
6 years ago To add context to my diversion from "indeterminism" for everyone else less familiar with game programming;
Games that run on fixed frame rates have a very nice property of simulating it's physics very consistently. A move of 5 pixels will always be a move of 5 pixels, and will happen the same every Nth frame.
What nopey has implemented is called a "variable timestep", and while does solve our issue in this case, also comes with a lot of implications that I was hoping to avoid having you all think about. To summarize for everyone though, variable timesteps measure the time since the last frame, as a delta time, and usually apply this to physics calculations. It allows for uncapped frame-rates, however it creates uncertainty in your physics depending on the size of the time step (delta time).
While in pong it probably won't matter, I'd like to explore other avenues with everyone that are more simple to implement and easier to understand.
The game currently randomly stutters, because of the fixed step set by SFML's
setIntervalI have made two branches that fix this:
adaptive_fps
Uncapping the framerate and adjusting the framestep (Minimal, very invasive change, that breaks determinism in the physics)
multithreading
Splitting the rendering and gameplay into seperate threads (Advanced, Currently incompatible with SFX, maintains determinism)
@sweetsbeats has already expressed displeasure with
adaptive_fps's indeterminism, and I think thatmultithreadingmay be a bit over-engineered.