I am new to Pico-8 so apologies if I'm missing something...
I'm writing a game using the _UPDATE() and _DRAW() functions which scrolls vertically a pixel at a time. It scrolls smoothly most of the time but every now and then it seems to 'stutter' briefly. Note that the sound/music isn't affected.
I have tried it on 3 systems and the problem is apparent on all of them, to some degree. From best to worst:
Mac i5
Raspberry Pi (1) B
PocketChip
I have used STAT(1) to find out CPU usage, and it never goes above 0.38 (on the Mac and Pi at least, I think slightly higher on PocketChip), so I would not expect frames to be dropped. I've put the STAT(1) at the very end of the _DRAW() function - is that the right thing to do?
I've noticed slowdown (particularly on PocketChip) on other carts too, but couldn't say what the CPU usage is.
Similar thread: https://www.lexaloffle.com/bbs/?tid=4089
Any advice appreciated!
PocketCHIP I have heard does not run as fast as PC. You might try this test.
for i=0,127 do cls() print(stat(1),0,0,8) rect(i,8,i+8,16,7) flip() end |
I am getting a stable, "0.0586."
If yours keeps changing numbers, there is a chance you are having a problem with the execution and need to configure higher priority to PICO.
The intermittent stutters could be during lua's garbage collection pass. The stat(0) memory display could show that on 0.1.7; I don't think 0.1.9's memory number includes dirty but uncollected memory.
I was curious, so I threw together a test. This cart abuses the GC by thrashing memory; once the dots hit the bottom of the screen and it starts deleting objects, the frame rate suffers badly. Reusing the objects (hit 'z') runs pretty well. Not sure if this is the situation you're in, though.
There's a tipping point on my system (I haven't tested on the pocket chip) between 1200 and 1300 objects where the unreused mode starts killing the framerate. Reusing objects stays stable up to more than 2000 of these small objects.
Wow, Happy Birthday ! That looks a lot like confetti. :) Lovely, but yes - I think you're pushing the system pretty hard with this complex display.
Many thanks for the replies!
dw817: I do get a solid 0.0586 with your test program on my laptop...but did notice that if I keep running the program, although the stat figure is solid, occasionally the movement of the box 'jerks'. I can only really put this down perhaps to a background service or something kicking in and slightly affecting Pico-8's performance.
fweez: I don't think I am getting into the territory of your demo, but the slowdown is similar (although nowhere near as pronounced). I learnt a thing or two from your code so thanks for that! I didn't realise until you mentioned it that the PC version of Pico-8 is 0.1.7...so perhaps this fix from 0.1.9 may explain the problem:
'Fixed: Sometimes frame skipping starts before CPU useage has reached 100%'
On the Pi, I have just setup a low resolution mode so I can run Pico-8 on an arcade or other 15khz RGB monitor. The mode I found to be best for my monitor is 320x264, which allows the Pico-8 display to be doubled, but with left/right borders so that the aspect ratio is kept about right. Running in this mode seems to remove most if not all of the stuttering problems that were previously apparent. I wonder if this is a little easier on the Pi than the mode I was previously using (640x480)?
It is surprising to get any hiccups at all with the small code I wrote, Minsoft. I know when I use Blitzmax's own FLIP() routine, it is flawless and shows zero hesitation at all times.
I'm wondering if this the case because PICO runs in LUA, which is an interpretive language and not compiled.
Pico-8 is made with libsdl, (c or c++) and was converted to javascript for the web version. (I assume with emscripten)
Pico-8 programs are written in LUA which is read and runs inside of a "virtual console", which I believe doesn't go so far as to emulate registers, but does have a memory space and a coded limit to its processing and draw speed.
The processing and draw speeds are based on a 30 (or 60) fps update, but that's inside the "virtual console". I can load up a pico game on my aging android phone, and even though a game might only use up 0.24 of stat(1), it could be chugging along at 4 fps in the browser on my phone.
All that to say there's definitely overhead in the implementation of the browser version of pico-8. And you'd pretty much have to rewrite the whole thing in flash to get a .swf out of it.
edit:removed flash bashing
The PICO Online version is written in JAVA then. I'm wondering how much faster it might be were it true FLASH or ... what is the format for the fastest executed programs Online now if not Flash ?
If you rewrote pico-8 in actionscript and loaded a .p8.png it would probably be about the same speed.
If you rewrote a pico-8 game by hand in actionscript it would be faster, but then you're just making flash games.
Actionscript. No, I programmed in Flash and it was a real pain to get it to work right. Looking up Actionscript.
Hmm ... If money wasn't a problem, Tyroney, what commercial program do you think would be good to create SWF from Actionscript ?
[Please log in to post a comment]
