Log In  
:: Unfold ::

I figured out that you can use strings to set up a lot of content cheaply, and I understand that others are using procedural generation to get the same effect. All well and good, but that only works for static content. If you want a longer game where you can make changes that persist across sessions then the 256 byte limit on permenant storage is crippling. The game I want to make is basically impossible unless I use two or three extra carts JUST for their quarter-of-a-kilobyte save space. That seems a bit silly, especially since I'll be punished for it by not being able to use the BBS.

Could we get a little more room, please? Keep in mind that even carts for the original Gameboy could potentially have up to 8K of save space. I don't think that allowing 1K would violate the spirit of the PICO-8, and it would open up a lot of possibilities.

P#43990 2017-09-07 16:59 ( Edited 2017-09-16 01:09)

:: Unfold ::

Greetings all,

New PICO-8 customer here. I've been going over the manual and I'm a bit confused about something. In the Memory section it says "Colour format (gfx/screen) is 2 pixels per byte," which implies 8-bit. But in the Lua Syntax Primer section it says "Numbers in PICO-8 are all 16:16 fixed point," implying 32 bits. In that case you should be able to store 8 pixels-worth of color data per byte.

So what gives, exactly? Can I POKE 32-bit values into sprite/map slots for extra data storage?

P#43918 2017-09-04 14:35 ( Edited 2017-09-10 16:03)

Follow Lexaloffle:          
Generated 2023-09-27 04:33:30 | 0.063s | Q:6