Hello everyone,
I have decided to start a MonoGame/2D development blog, where I will share my tips and experiences.
There is a great article out there about fixed timesteps for video games, so I’ve decided to make a bit more beginner friendly explanation/introduction to the topic.
Visit my blog if you’re interested:
Very nice. I followed the steps to make a new project. There are some small issues that might hold up new devs. I put them in the comments on the tutorial page.
Thank you very much, and also for the comment, I’ll fix the article right away!
Thank you, i’ll give it a good read !
I found the post very informative!
I don’t want to teach anything, but i feel like the article would be more complete and noob friendly with a short note on how to activate fixedtimestep in the official Monogame way:
Inside game Initialize() method:
IsFixedTimeStep = true;
int targetFPS = 30;
TargetElapsedTime = TimeSpan.FromMilliseconds(1000.0f / targetFPS);
To avoid VSync messing up with higher fps you might also need
_graphics.SynchronizeWithVerticalRetrace = false; //Vsync
Thank you for your input!
I know that you can fix timesteps in MonoGame, but the problem wit that is that is also limiting the rendering, not just the Update() calls. I really would not like to restrict the player to play the game with only 30 FPS just have a 30 FPS physics update in my game. Even a non-gamer can clearly tell the difference between 30 and 60 FPS rendering and a seasoned gamer can spot even finer differences. In fact, I would not like to limit them in any way, if they paid for a rig that can produce hundreds of frames / second, let them enjoy it 
Also, even if you restrict your game to 60 FPS using the MonoGame method, you might still want to have less physics update to save on the battery on mobile, for example.
With “my” method, the drawing is unaffected, for example on my PC, my small platformer game demo runs with around 2000 FPS, while the physics update is only 30 FPS, the rest is displayed with interpolation. Not that it matters so much, because I have a 144 Hz Monitor, so it won’t display more than 144 frames / second, but for stress testing, it’s really nice to see how the game runs, it really gives you an idea of how the code performs.
My personal recommendation is not to limit the FPS in MonoGame, or just include an frame limit option in your game settings, and the users can decide for themselves, so they can still enjoy smooth gameplay, and fix the timestep for the physics updates.
A really good informative article. I look forward to reading the next one regarding collisions etc
Thank you very much!
I’ve finished the second part of the series regarding movements, third one also coming soon!
Another great write up mate. Im enjoying this series
Thank you again, I’m finished with the collisions article, I hope you’ll like it!