   Question about main loop & fps
  Hi guys, I just read this article and was wondering if I could get some opinions:http://dewitters.koonsolo.com/gameloop.htmlIt goes through a few different approaches to the main loop: using fixed FPS, updating/rendering as fast as possible, using fixed updating and rendering as fast as possible,and fixed updating, rendering as fast as possible, and using interpolation.I was wondering what you use?What do commercial games use? (Or do they do something more complicated?)The article seems to recommend the last approach.But it says you need an interpolation function in your renderer.That sounds like a bad idea since your renderer should be independent of the game state / logic. I suppose you can move the interpolation function there.Another thing that bugs me is: if you have a way to interpolate, is it really that much faster than just updating the game logic?   
Quote:Original post by meteorstorm42I was wondering what you use?I use fixed-rate logic, variable-rate rendering and interpolation for the following reasons.Firstly, to achieve consistent results in almost any simulation, you need a fixed time step. This does not just apply to complex physics simulations. Try writing Super Mario Bros using variable time steps and have the character jump to exactly the same height every time.Secondly, you have no control whatsoever over the framerate on a PC. Even if you sync to the vertical refresh and set the refresh rate to a specific value (which may not work region to region), the user may have chosen to override vsync with their graphics card or their computer may not be fast enough to keep up.Fixed-logic, variable-framerate addresses all these issues and interpolation keeps things looking nice and smooth.Quote:Original post by meteorstorm42What do commercial games use? (Or do they do something more complicated?)If you have the luxury of working on a console where you know the exact hardware your game will run on, there is no reason you can't use a fixed frame rate (linked, again, to vsync) to time your logic. PC's, no way.Quote:Original post by meteorstorm42But it says you need an interpolation function in your renderer.That sounds like a bad idea since your renderer should be independent of the game state / logic. I suppose you can move the interpolation function there.It is not a question of where your interpolation function is. I have a couple of  Interpolate() methods, one for vectors and one for floats that are just free functions that sit in a maths.h unit.The key thing is that for anything you need to interpolate, you need to store both the last and current states, be that animation, movement, screen fades etc.Personally I tend to have a moving actor store its current position before it updates each frame, then when it renders itself it interpolates between the two based on the accumulator to decide exactly where to draw itself.If you insist on your renderer being responsible for drawing your actors (an approach I find restrictive), you still need to query an actor to find out its position so you can just do the interpolation there and then. But there are myriad ways to address these issues, all with different pros and cons.This is the definitive article on the topic of fixed-rate physics, frame-rate independant rendering and interpolation in my opinion, although it is more complex than strictly necessary to just smooth out motion in games.I have found though that since using interpolation can lead to world co-ordinates being very long and complex floating point numbers, when writing 2D games using 3D hardware it is hard to get textures to map to sprites correctly (Direct3D at least, can't speak for OpenGL). Multisampling can take a great deal of the pain away from this and the flexibility the approach gives you is well worth the additional effort and the odd visual glitch in my view.Quote:Original post by meteorstorm42Another thing that bugs me is: if you have a way to interpolate, is it really that much faster than just updating the game logic?Apples and orangutans. The methods described above have little or nothing to do with the speed of execution and more to do with stability and consistency.---------------------------------------Not to pimp my own work or anything ([smile]) but everything ">here is interpolated and frame-rate independant while running at a totally fixed logic rate. It looks a lot smoother in reality than in a YouTube video as well.   ;Awesome! Thanks for such a detailed reply :)Quote:Original post by AardvajkI have found though that since using interpolation can lead to world co-ordinates being very long and complex floating point numbers, when writing 2D games using 3D hardware it is hard to get textures to map to sprites correctly (Direct3D at least, can't speak for OpenGL). Multisampling can take a great deal of the pain away from this and the flexibility the approach gives you is well worth the additional effort and the odd visual glitch in my view.I'm trying to understand this part a bit better. So the problem you ran into was because of the inaccuracy in the interpolation due to floating point numbers? It made what happen exactly? The texture maps didn't line up with the objects correctly? Or was it something else? (I want to understand this so I can see why the multisampling helped.)I watched the youtube video of your game. That's pretty amazing :)How long have you been programming games?;  Yeah i agree that in modern gaming a fixed time step and variable frame rate is great, but problems can be encountered due to changes in speeds of objects.e.g. if left click move += 1; This move value will increase faster on other computers and slower on some. This means that logic has to be carefully timed.If you are new to this i suggest you set a low frame cap, say 40 fps. i.e. at the end of the game loop wait until the whole loop takes 1/40 secs then allow the loop to continue.This means graphics and logic occurs at the same time making debugging easier and coding more straight forward. This is fine for small beginner projects where the graphics aren't very intensive, but after you have got the gist of getting the program to work how you want to you then introduce timing into it.You could even get quite clever and use one thread for rendering and one for the game logic, the game logic being tied down to a time or related to a deltatime value (the time between the start and end of each loop).   ;Quote:Original post by PureBlackSine.g. if left click move += 1; This move value will increase faster on other computers and slower on some. This means that logic has to be carefully timed.You can avoid this by having an accumulator, eg void Frame(float dt) {    static float accumulator;    accumulator += dt;    while (accumulator > SOME_FIXED_TIMESTEP) {   accumulator -= SOME_FIXED_TIMESTEP;   //update at SOME_FIXED_TIMESTEP    }};Quote:Original post by meteorstorm42I'm trying to understand this part a bit better. So the problem you ran into was because of the inaccuracy in the interpolation due to floating point numbers? It made what happen exactly? The texture maps didn't line up with the objects correctly? Or was it something else? (I want to understand this so I can see why the multisampling helped.)This article on MSDN explains about how care needs to be taken when mapping texels to pixels when linear filtering is used.Maybe I'm missing something, but I've found that when I am using interpolation, you either have to use the raw world co-ords that get generated by the interpolation, in which case you get pixel artefacts, or clamp the generated co-ords, in which case objects can shake about as floating point inaccuracy causes the values to jump up and below the threshold.I abandoned clamping since it was a far worse effect, but I have found that multisampling seems to remove a lot of the artefacts described in the MSDN article above. To be honest, this was more based on trial and error than any deep understanding of exactly what happens. [smile]Quote:Original post by meteorstorm42I watched the youtube video of your game. That's pretty amazing :)How long have you been programming games?Enough years that the game is far from amazing really [grin]. Joking aside, about 20 in total and about 10 on PCs with C++.   ;Wow, I had no idea it got that complicated.I've yet to delve into anything but the most basic D3D stuff though.I've got a lot to learn...From the youtube video, I thought the game looked like something you might see on an iPhone, very polished.It looks like you're still working on adding stuff too :);  In my game engine I use  fixed updating, rendering as fast as possible, and using interpolation.In my haptic engine I have things setup a little differently. I render @ 60fps and make the haptic loop run at a fixed 1000fps.;ThanksThere seems to be a consensus for fixed logic + variable rendering + interpolation.Implementing the interpolation may take some figuring out though...   ;Quote:Original post by mmakrzem...I render @ 60fps...How do you ensure that on another computer?   