Game cycle, FPS and optomisation

Recommended Posts

I think I posted this into the wrong section before. Hope I am correct now. and yes a noob.



Been reading about basic game function, engine, cycles, FPS and refresh rate and now wondering how Phaser manages all of these, if at all.

Game design is usually enabled so that the game cycle and FPS do not interfere with other too much so code works the same (aka similar playability but with varying graphical experiences) for different systems of ranging capacity. But I have not read anything about this optimisation for Phaser games. Is this because the frame rate is controlled by refresh rate of the web browser used by the player and therefore out of design control?

I have been reading Phaser game code on different sites and nowhere have I seen this optimisation implemented. While surfing I actually came across a site with a series of playable examples and associated coding (minor snippets really and minimal graphics) which seemed to stall and were jerky during play. This was in stark contrast to all my other experiences with Phaser code examples. I was using a Samsung Tab A at the time. So the question above came to mind much later as the dust was settling after a session of hunting out information.

So how does Phaser deal with the above and optimisation for a multitude of systems of varying capacity?

Does it 'sleep' in between cycles when CPU calculations are not required to conserve battery power?



Share this post

Link to post
Share on other sites
  • Phaser makes exactly one render for every animation frame it receives from the browser. Usually that's 60 renders/s. You can skip renders by turning on lockRender.
  • When forceSingleUpdate is on, Phaser makes exactly one logic update per animation frame. 
  • When forceSingleUpdate is off, Phaser tries to make the number of logic updates required to match desiredFps.
  • You can monitor suggestedFps and adjust desiredFps if you like.

Share this post

Link to post
Share on other sites
On 11/09/2017 at 2:08 PM, Julz57 said:

Does it 'sleep' in between cycles when CPU calculations are not required to conserve battery power?

This is a really interesting question, but its not to do with Phaser, but to do with how the browser works, which is potentially different for each browser. To answer requires pretty intimate knowledge of how the browser works (which I don't know and isn't common knowledge, maybe it should be?).

Node, as an example of implementing a JS engine (the same one in Chrome usually), and I've read this (I think), here https://nikhilm.github.io/uvbook/introduction.html (somewhere there anyway), creates an event loop that keeps spinning and handles all the events (as it can) when they come in, for specifics, this includes handling an async action like initiating a file read, popping that action initiation on to a stack and handling the response (whenever it arrives sometime in the future) and linking the action of the stack with its resolution, all so that the event loop can handle other actions that occur between initialisation and resolution. I've kind of always assumed that the browser works in a similar way to try and conserve system resources, as a JS developer working in this 'browser' vacuum, should you be concerned with this? Well, perhaps, but, there's nothing you can do about it if you don't like the answers you find.

It's certainly true that a well-written browser application will consume more resources (such as CPU cycles) than a well-written 'native' application, but its not really a fair comparison. As a JS developer you're working at a higher abstraction and you dont/cant get involved with all the low-level interactions.

When working with your average JS application (particularly targeting browsers, as most do) you're severely hamstrung with regards to implementing some of the more complex application loops common to gaming. You're almost completely restricted by requestAnimationFramerate and you can't fight it.

JS is single-threaded (threads are hard, there's lots of advantages to this), stuff like web workers could try to work in other threads and free up your UI thread (which would be your main thread in JS) as other platforms might do, so, you could try to offload your AI logic (for example) to a web worker so your main thread can push rendering at refresh rate (i.e. 60fps), but, I don't know any examples of this (some might exist as some browser games are pretty involved nowadays) and its certainly a very difficult thing to do.

Share this post

Link to post
Share on other sites

Thanks @samme and @mattstyles

Yes that makes sense now. I cannot see the point of increasing the refresh rate which is currently 60fps as per @samme . As a retired optometrist the eye cannot resolve anything more than about 25-30 fps in the central field as the information blurs into a smooth perception. Having 60 fps is therefore adequate for VR applications using the internet. Going any faster will not improve the smoothness. This may still become an issue if we go to super field screens with ultra ultra ultra high resolution where even 60fps (30fps in VR mode) may show up as jagged movement. This is more likely to occur in the peripheral field which is where the neural pathways and receptors are geared primarily to identifying change or movement. The critical fusion frequency there is much higher than the  central visual field where our screens are currently located. It may be in your lifetime but doubt it in mine. lol from an old bastard who has the pleasure of being retired and currently slack as.

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.