In theory, it is better.
Implementation details are a mess, though.
Yeah, it didn't work and then I changed a few things around and it seemed to be working ok at that point. Of course, that's just doing the game loop and before I've actually changed my game logic to work with the new fixed timestep. Even still it seems to be keeping pretty correct time.
Most importantly, I managed to just set frameTime directly to a seconds value, which made things much handier than trying to convert back from seconds to QPC ticks...
Also, why the floating point? You complain about the accuracy thinking long will not work for you with 32-bit precision, so you move to a 64-bit type ... then you discard it and go with a double that has even less bits of precision. Just stick with integers (either 32-bit or 64-bit), it will make your life easier.
Also, where do the magic numbers come from? Do the 0.25 and the 4 have any significance?
Well I based it directly off of the example you linked earlier:
gafferongames.com/game-physics/fix-your-timestep/
There he uses a double for the frameTime, which he has in seconds.
Also 0.25 comes from the example. As for the 4, it was there to (hopefully) make for a simpler calculation than multiplying by 0.25, by just dividing by 4 (and therefore avoiding floating points).
Figured I'd try to get it working with my code but as close to the example as possible before looking at if some different values would be more appropriate.
It now looks like:
while( Engine::instance()->isRunning() )
{
//Get ticks
LONGLONG newTime = getQPC();
//Get time between updates in seconds
double frameTime = double( newTime - currentTime )/ double ( getQPFreq() );
//If more than 0.25 seconds between updates
if( frameTime > 0.25 )
{
//Cap to 0.25 seconds
frameTime = 0.25;
}
//Set currentTime for next frame
currentTime = newTime;
//Add frameTime seconds to accumulator
accumulator += frameTime;
//While
while ( accumulator >= dt )
{
Engine::instance()->handleEvents();
Engine::instance()->update( dt );
accumulator -= dt;
}
//Calculate alpha interpolation value
const double alpha = accumulator / dt; //
//Render
Engine::instance()->render( alpha );
}
frameTime calculation looks a bit messy, but it seems to be giving reasonable values. I suppose I'll look into changing it to a LONGLONG that holds nanoseconds, and then changing accumulator and dt similarly...
Is it very much a bad idea to leave it as is?
One more thing though: in the example he has the following before the rendering function:
State state = currentState * alpha +
previousState * ( 1.0 - alpha );
Clearly state is going to go out of scope after the rendering is done, so I assume even though he doesn't pass state into the render function, that we're supposed to assume that render is using the value of state as the basis for rendering?
Must be, it's just at first I thought it looked like he might have been doing things a little differently to what I was used to in that regard (it made me think he was actually storing the in-between value for purposes other than pure rendering), but I think it's the same now. i.e. He keeps track of the current and previous states, and then just draws between them based on the alpha value and nothing else happens.