I'm having a lot of issues getting my game to run smoothly at 60fps.
90% of the time it works fine at a smooth 60fps, but occasionally it'll will switch back and forth between 30fps and 60fps in quick succession. This would normally be okay, since from what I understand the update loop is supposed to run twice for every 30fps draw frame, if it's been throttled down. But this doesn't seem to work as intended, because what would normally be smooth movement will speed up and slow down during frequent 60 -> 30 -> 60 switches, so the updates and draw calls are definitely not called in a consistent manner. This problem seems to be even worse in the html export. Stat(1) is never above 0.35 in 60fps mode, so I'm not sure why Pico-8 is shifting down to 30 in the first place. This is on a very recent Mac laptop.
Has anyone else experienced this behavior? Any suggestions? I really want to use the 60fps mode, but smooth performance is a priority.
Thanks in advance! Love the Pico-8 platform so far, but this has been frustrating me.
Yeah. I don't think @zep or maybe SDL is handling vsync correctly. Probably there are issues with assuming the video refresh is exactly 60Hz and trying to do math according to that, instead of just taking as implicit that each time you get a vsync, that much time has passed. There can be problems with audio sync or pitch when you do that, though.
To be fair, it's a tricky thing to get right. Most of the time, it's done incorrectly, especially when the display runs at TV's 59.94Hz instead of true 60Hz. Computer monitors are pretty inconsistent about running true 60 vs. TV's pseudo-60. You really have to be flexible when deciding whether or not you're hitting the frame "on time" in code. It's easy to accumulate either a real or perceived cumulative error and handle it the wrong way.
Hmm, that definitely sounds like it could be the issue.
I'd love to have the option to turn off the fps locking if possible, and just deal with the occasionally slowdown. I think for some games that's preferable to locking the framerate, especially if the framerate switching is finicky.
I've been trying to write around this in code but haven't had much success.
I was wondering if some kind of hack unlocked framerate could be possible.
you could obviously do something like
while true do custom_update() custom_draw() end
But then using flip() to draw the graphics buffer to the screen would lock the FPS at 30.
Would it be possible to pset or poke or memcpy or whatever to write graphics the screen outside of using any of the functions that limit the fps?
Then what about delta time? There's a stat([number]) that gets the current second but AFAIK not milliseconds. So I guess you could count how many times update is called before the seconds counter is updated then divide them to get an FPS and approximate delta time but that's not really much good for slowing down or speeding up drawing to have a consistant framrate...?
I dunno, not put any time into it just daydreaming.
I've had a problem that seems like this, when running a Pi (1B) and a (15kHz) CRT via HDMI > VGA (RGB).
I thought it might be due to the display mode not being exactly 60Hz...or possibly just that the Pi 1 is struggling (although stat doesn't indicate that is the case).
I was planning on getting a Pi 3 to try out with the same monitor to see if that helps...
Log in to post a comment