Forums » Impact Engine » Game speed doubled with latest relase

I just upgraded to the latest impact release and as my game needs a deterministic game loop, I reapplied the patches to the timer module

ig.Timer.step = function() {
    ig.Timer.time += 0.033; // = 30fps
};

ig.Timer.inject({
    tick: function() {
        return 0.033;
    }
});

In main.js I have

ig.main(
	'#canvas', 
	MyGame, 
	30, 
	900, 
	600, 
	1 );
});

but the game is now running twice as fast as it was.

Has something changed - like the default timescale, or have I missed something else?

Been digging into this a bit further.

I migrated from 1.19 to 1.21 and I'm suspecting that the new requestAnimationFrame code may be the cause.

Is is still possible to have a deterministic game loop with a fixed display rate of say 30fps?

Why the need for deterministic timing? Why is adaptable not working for you? What problem are you trying to solve?

Even if you don&039;t upgrade Impact you're not always going to get exactly 30 fps out of #setInterval and setTimeout. Browsers can and will lie to you about the timing of those calls; if you say "call my callback in 4ms" the browser does not actually have to do that. They both also have a minimum granularity (you can&039;t schedule a callback with any kind of precision under about 10ms). Usually, you end up requesting the callback and then using #Date.now().getTime to figure out how much actual time has passed since the last frame.

requestAnimationFrame lets the browsers schedule animation frames more intelligently. This could be faster than 30 fps or slower. It also lets browsers "shut off" the loop if the user isn't looking at the tab or if the window is minimized. Generally, you want this behavior.

So, yeah... why the need for 30 fps precisely?

30 fps, 60 fps it doesn't really matter.

I need to be able to replay the same result across platforms and browsers so that no matter how many times I replay a certain match with the same parameters, I will get the same result.

Without it, if somebody's browser slows down for whatever reason and a collision gets missed because of the increased delta then whatever happens in the game after that will be different.

For my purposes it doesn't matter if there is the occasional slow down for a few frames, as long as the position updates are the same on every run through. 30 fps seems a good value as most platforms can handle it. At 50-60 fps the slow downs will happen more often on older browsers/devices.

Dominic supplied a patch in another forum post here to do this. It worked great.

http://impactjs.com/forums/help/deterministic-game-loop

but in 1.21 it will no longer work

There is an interesting discussion on the topic here, including a section on setting the frame rate.

http://creativejs.com/resources/requestanimationframe/

Think I may have been over thinking this.

The requestAnimaionFrame will be called approx 60 frames per second if the browser isn't busy etc. but my step and tick function overrides are set to 0.033 I.e 30 fps and everything seems twice as fast

By changing them to 0.016 (60 fps), I get back to where I was speed wise, and the game should still be deterministic.

Now I need to figure if there are enough slowdowns at 60 fps to make it annoying.

Ah, okay. Yup: you totally need deterministic timing.

Setting aside arguments about how you might get better results doing this on a server somewhere (cheating, etc... you&039;ve probably already thought about all that), then yeah, you're totally right: making #tick return a constant should get it done. Good idea! I'll have to remember that.

Don't forget to come back to the board with a prototype so we can check out your game. I'm curious, now. ( =

Thanks for confirming.

I do actually run all the games server side (well cloud). I have a bunch of Phantom JS instances running in iron.io cloud service worker tasks. These actually run the games and then update the server with the results. When the user watches the game, they will see the same game that is run on the Phantom JS instance, but without updating the server.

Got a bit more work to do yet but will post something here when it is at least stable.

Okay, that is totally BADASS. Would love to read a writeup of the decisions that got you there and the tech involved (even if it's all shell scripts and cron jobs and you think it's stupid, it's pretty cool).

My first question would be: modifying Impact to run server-side wasn't an option? At what point do the infrastructure costs per user outstrip the code debt of modifying Impact?