XK9274 / pico-8-wrapper-miyoo

A wrapper to run Pico-8 Native on the Miyoo Mini/Miyoo Mini plus.
101 stars 7 forks source link

Frame skips as soon as stats(1) goes above ~0.3 #6

Open hmans opened 7 months ago

hmans commented 7 months ago

I love that this exists -- thanks for putting in the work!

I do have a question about performance though. Some more demanding games tend to drop to 15 FPS (or even below that.) I've written a small test game that graphs the current usage of stat(1), and I'm noticing that PICO-8 using this wrapper will drop from 30 to 15 FPS as soon as stat(1) goes above around 0.3-ish (where 1 would be the complete CPU time allotted to a single frame, ie. 1/30s.)

This is by no means the end of the world, but I'm wondering if this is because of the Miyoo Mini+'s hardware, or because of the wrapper? I unfortunately don't have any other handheld devices to compare this to (yet, a Powkiddy RGB30 is on its way here.)

GIF of the game included, so you know what kind of stuff we're talking about. The bar at the bottom is graphing the current stat(1):

revade-8_45

(Note: the GIF was recorded on my desktop computer, it's not showing the frame skips. The scene shown would run at 15 FPS on the Miyoo Mini+.)

Edit: I know about the virtual overclocking shortcut, but I'm seeing these issues even with that set to maximum.

XK9274 commented 7 months ago

Thanks!

Yeah, I'm gonna look into this. It's visible (although slightly better now since adding some arm instructions) in games such as buns: bunny survivor when there's a lot happening on the screen, it can tank performance. I.e when a ring of bats spawns.

There's currently frame waiting adjustments, I've changed a few things so we don't always wait for the blit to finish (which is a blocking call). We only wait when there's input which in some games can be a lot so there's room for improvement there. Originally it was on permanently and this was giving a little performance increase at the cost of tearing/artifacts, having it only skip when there's input is a good compromise I think but could be revisited.

Currently there's no frame skipping but it's something I've looked at implementing though it wasn't a great visual experience.

I'm not a Pico Dev but have looked up the stat() function and it seems interesting, I'll see if there's any ways to interact with this from SDL but it could be difficult, though that said; the Pico bins aren't stripped..

I'll look into frameskip again, would be great to keep in touch for the testing 👍

hmans commented 7 months ago

For context, stat(1) basically returns the time since the last frame was rendered, normalized to the target framerate (ie. a value of 1 would match exactly 1/30s or 1/60s, depending on what the game is targeting.)

Happy to test new builds, but it's possible I will be returning the Miyoo Mini+ soon since I'm most likely replacing it with a different handheld.

XK9274 commented 7 months ago

Sure no worries. I suspect this is a CPU thing - have previously done some checks on the time it takes to run the rendering/video functions and it wasn't that varied tbh but could still be something in SDL causing it.

Out of interest, do you have a cart of the game in the gif you originally posted? it'll be useful for my testing if you could share a copy please?

hmans commented 7 months ago

One publicly available cart you can test this with very well is "Whiplash Taxi Co". It's pretty interesting in how it will run perfectly fine for maybe 10 seconds, and then suddenly drop down severely in FPS. Maybe this is the SoC being throttled to mitigate heat buildup?

I'd be happy to send you a copy of my WIP cart, but would prefer to do it privately instead of posting here. Do you have an email I can send it to?

XK9274 commented 7 months ago

Hey, yeah happy for it to go through DM, i'll reach out to you on discord.

XK9274 commented 5 months ago

So just an update on this - been testing quite a few things - made tons of changes.. Worked with Schmurtz on some other problems pico was having in the Onion build and while we've fixed the framerate issue, the slowdowns/chugging still happens occasionally. I'll probably have to rebase SDL2 with Stewards new branches as mine are way out of date now.. That could fix it (He's made many improvements since release of this)

There's some changes in the main branch here for framerate, but the rest i'll do when i have time... not really a small task