Forums » Impact Engine » Impact now uses requestAnimationFrame where available

I just pushed a new version to the Git repo that uses window.requestAnimationFrame() instead of window.setInterval() in Firefox 4 and Chrome 11 for the main game loop.

This should fix screen tearing issues and also prevents the game from running when it&039;s not on the active tab. This also means that the #fps parameter for ig.main() is now completely ignored and will probably be removed in future versions. Impact will now always run at 60fps when possible.

As this still a bit experimental right now, I'd love to hear your feedback! Does it work for you? And do you see any issues with not being able to specify a frame rate other than 60?

Update: Narf, after some more digging it turns out that for Firefox 4 using requestAnimationFrame() always results in a lower frame rate than setTimeout(). See this bug.

I disabled it for Firefox. So Chrome 11 is now the only browser that&039;s not using the old #setTimeout() way.

Would this impact (lolz) making mobile games as you wouldn't be able to use the ig.main() tag to slow down frame rate for more efficient use on mobile?

or would there be another way to detect it like if (ig.ua.mobile){ig.main()} ?

As it is now, you won't be able to specify a framerate. The whole idea is to give the device/browser the authority of deciding how often to draw. Ideally the framerate should match the display's refresh rate - for most devices this is 60hz.

Is there really a case when you want to specify a lower framerate? I.e. do you set your games to run at 30hz to save energy on mobile devices?

That said, I think requestAnimationFrame() is not quite ready for prime time yet. I'll probably revert this change for the 1.17 release again :/

I've found that using 30hz instead of 60hz let my games run faster on mobile, but I guess it could just all be in my head.

Bleh, I just reset the git repo to the version without requestAnimationFrame. I encountered some additional problems with my changes (my own fault, not that of requestAnimationFrame).

For now, Impact will be using the "old" setInterval() method.

Is there any chance of seeing a sample of how you implemented requestAnimationFrame? I am working on doing some testing with Impact on Windows 8 as a native metro HTML app and was told that by using msRequestAnimationFrame I would see some performance improvements. I figured before I started hacking around in the core of Impact I would check with you first on how you did it and what went wrong so I don't fall into the same pitfalls.

Also, I have hooked up MS touch events and other MS specific stuff. It got me to thinking how to best patch the core engine to support Win 8? I'll start a new thread for that.