General

[raysan5]

Probably this point has been discused somewhere or have been mentioned in some document...  but I couldn't  find this information.

It's about framerate on emulator and PSVita. Does the framework limit the FPS to 60? Is it possible to get more than 60 frames per second?

If system is limited on some way to those 60 frames, is it possible to reduce that limit not using a Stopwatch and Thread.Sleep? I mean, is there some parameter somewhere to adjust that limit?

Thanks for your answers!

[Infinite_Daremo]

I was wondering if the same thing. My game updates at the same speed regardless of wether i time clamp the update loop at 60fps. Just curious, why would you want to update faster than that?

[MartinCaine · Accepted solution]

Yes, it's normal, especially on mobile platforms to work towards a fixed 60 or 30 frames per second. If you want your game logic to update more often than this you'd be best offloading your update method on to it's own thread and let the render thread continue on the main thread but this introduces complexities too.

[jamesnorman91 · Accepted solution]

Hi raysan5,

As others have explained, the frame rate is limited to around 60 FPS as you can expect the SwapBuffers() call to take around 16ms to complete. Other delays are likely to come from other areas of your application, which you could speed up by multi-threading, however you should note that draw calls should be done from the same thread.

Thanks,
James

[raysan5]

Many thanks for your answer.

[YstadYakuza]

@jamesnorman91

I'm trying to do a lot of optimization on my code and not calling Render() & SwapBuffers() if nothing onscreen is changed. But not calling it forgoes this new Fps limiter. To me a more intelligent solution would be to have a separate LimitFps() command that we could call each loop iteration. Tying a delay directly to SwapBuffers seems like a poor choice for an SDK.

It's frustrating that this change wasn't discussed in the version notes. Is there anywhere in the docs that discusses the finer points of this? Does the delay take into account the actual time that has elapsed since the last SwapBuffers call?

[MartinCaine]

I would assume that the framework simply waits for the VSYNC signal before swapping the buffers. That's how many systems work and prevents on-screen tearing while maintaining a steady framerate. I don't think SwapBuffers actually has an inbuilt delay as that would be stupid but potentially if your game Update() is only taking 1ms then SwapBuffers could be sitting there for 15ms waiting for the VSYNC signal.

Just as if your Update() is taking 17ms, you'll only see 30FPS as the first VSYNC signal will be missed and the next one will be caught by your SwapBuffers() call.

[YstadYakuza]

It was properly handling VSYNC before the delay was added so I think in PSM those are separate internally (triple buffering?).

I think it would better not to work on your assumptions and instead get this process explained in the documentation. A few weeks ago, jamesnorman was offering code to limit framerates in another thread so Sony might very well be using a delay.

[YstadYakuza]

Here is a suggestion for altering SwapBuffers that I don't think is great but is more flexible than what we have now.

Perhaps SwapBuffers could take an optional enumerator to control this new delay feature:

• SwapBuffers(); //works as it currently does in 0.99
• SwapBuffers(SwapStyle.NoDelay); //works as it does in 0.98
• SwapButters(SwapStyle.NoDraw); //would run the delay but not actually do the swap

Still, I think a good SDK wouldn't combine these two functions but this seems like a workable alternative to me.