Can someone modify this please (without making a function) so it does not flicker ?
I'm aware of functions _UPDATE and _DRAW and am trying to avoid them.
I know this can be done as I modified the HELLO program so it did not have any functions and ran just as smoothly as the original with no flicker.
... or am I hitting the top-end of what this language's speed is - trying to update every pixel per frame and it just can't keep up ?
Update: Thank you Gamax92 ! Showed me the memory location to POKE pixels and I am now getting the speed I want for screen manipulation.
-- very fast random pixels -- memory site provided by -- gamax repeat for addr=0x6000,0x7fff do poke(addr,rnd(256)) end until forever
Surefire way to check that is to use stat(1). (but yes, pico-8 can't handle filling the entire screen pixel by pixel fast enough for 30fps)
You can reduce the problem by removing cls, (and come up with an alternative to clear areas that need it) but basically you'll have to limit the amount you draw in some way. This was true of old consoles as well, which is why old games that do a lot of intensive rendering sometimes have larger-than-normal borders or fancy (or not) static artwork.
Additionally, the tighter your inner loop, the better performance you'll get, so for example, you can try removing the second loop (and doing it all in one), or using a less expensive way to pick colours (e.g. a pre-generated lookup table), or generally just reducing the amount of work you're doing for each pixel.
You could also try spreading the full 128x128 render over several frames - some folks on here have used that technique to great effect already for both clearing and rendering, however it depends on the look you're going for.
Alternatively there are a few different rendering modes you can try out that halve or quarter the area you can draw to, and scale up afterwards so you still get a 'fullscreen' display.
Essentially you're firmly in tradeoff territory here - think about what you want to do in your game and choose an option based on that, or come up with another way if none of them work for you (in my opinion that's where the fun is, but I'm odd like that). Good luck!
It's so silly really. I have BlitzMAX here that can ace my full 1280x720 screen with random dots perfectly.
I understand that PICO-8 has a small screen, small color base, and small coding base for nostalgia, but do they have to cripple the actual operating speed too ?
PICA could run flat out and use FLIP() to slow down and give perfect 30FPS synchronization every time no matter if every single pixel was updated.
Thanks for the info though, Catatafish.
Fortunately my current project does not require this type of screen manipulation -- but it would've been nice to have.
-- smaller and neater way to put random pixels on the screen repeat pset(rnd(128),rnd(128),rnd(16)) until forever
What is STAT(1) ? It's listed as updated in the help but not explained.
Welcome to 80's computing ;)
edit: from the manual:
x:1 returns cpu useage for last frame (1.0 means 100% at 30fps)
Check the value at the end of your loop to see how much cpu time you've used. For 60 & 30 fps, if you're above 1.0 (100%) pico-8 can't render that frame at full speed. For 60fps, instruction cost is doubled, so if you are below 0.5 cpu at 30 you could probably do 60.
Ah, but someone pointed out that 60 won't run Online, so - no. I just need to make smarter code. In any case, I'll be rendering tiles, not pixels except for maybe small special FX and stuff.
Once again, thanks. The more I mess with this language though the more it seems the limitations are not by choice but the best that could be done to make a game run with pixels at regular speed in LUA and JAVA.
pico-8 is a fantasy console carefully designed around a carefully designed fantasy cpu, which has carefully designed fantasy limitations.
you're not the first one to be stumped by this, so may I suggest you take a look at picolove, which might better suit your needs:
essentially pico-8 with 'No arbitrary cpu or memory or code size limitations'
while true do cls(0) for addr=0x6000,0x7fff do poke(addr,rnd(256)) end flip() end
Writing to screen memory (located at 0x6000 -> 0x7FFF) directly will be faster, each byte is two pixels.
and flr() is unnecessary since poke will do a floor of it's inputs itself.
whatever fits you, dw817! by reading your comments here and there I was under the impression you were feeling a little cramped with pico-8. by all means, take time to embrace it! :)
also I'm not involved in any way with picolove, those 2 links are all I can point you to.
It's up, UltraB. You can find it HERE:
Reminds me of some early work I did to convert 8-bit data to 7-bits and then you could save it as DATA statements in your code.
As the 4th table of custom characters for PICO is likely not used by beginners, it's a great place to stuff the image and does not require massive DATA statements in the code either.
[Please log in to post a comment]