on 13-07-2012 02:35 AM
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!
Solved! Go to Solution.
on 13-07-2012 09:01 AM
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?
on 13-07-2012 12:20 PM
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.
on 13-07-2012 05:05 PM
15-07-2012 05:58 AM - edited 15-07-2012 06:17 AM
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?
on 15-07-2012 11:09 AM
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.
on 15-07-2012 02:51 PM
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.
on 17-07-2012 03:59 AM
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:
Still, I think a good SDK wouldn't combine these two functions but this seems like a workable alternative to me.
Website ©2013 Sony Computer Entertainment Europe
All content, game titles, trade names and/or trade dress, trademarks, artwork and associated imagery are trademarks and/or copyright material of their respective owners. All rights reserved. [more info]