I apologize I have no code snippets here, it's actually a question about code.
Reading the specs for pico8, there's a 32kb limit. Is this for JUST code? I know that obviously the cart cover shouldn't be counted against any actual program/graphic/sound data, it's just for decoration and distribution, but I am working on a program at the moment, I only have 800 tokens, have used about 1/4 of the sprite sheet, no audio/sound data, and about 64 lines of text in the code...
But I'm reading 15kb already and that seems a little excessive and it's got me spooked in terms of how much further I can take this even though I'm barely using any of the resources.
Is the 32kb for JUST code? Is it 16kb for 'built in data' i.e. graphic memory and 16kb for code?
I'm curious what the actual structure is because I feel like as little data as I have thus far (no cart image taken for this program thus far) is far below 15kb.
Thanks for any help on clarification.
Sorry let me give some info...
I'm working on custom map data which uses 2 bit tiles (i.e. 4 shades of gray) along with a transparency flag and I also intend to create a custom music editor/player...
However, what is actually in the 32kb I need to worry about? Like...as an example...if I convert all the sprite data into strings and write them out at run time...what is counted as 32kb?
I guess that's the question I have. Because at the moment, it's arbitrary.. I saved the same file as a png and it was 7kb.
I only ask because I know the project I have is going to need that Pico Stretch Stylee...and so before going on, I kinda need to know what the 32kb means in totality. And the specs don't really state it.
The 32k is the memory size. Here's how that 32k is laid out:
You can type 65535 characters or 8192 tokens of code. PICO-8 then takes all your code, your sprites, your map data, your sound data, and your music data and compresses the whole thing together into something that can be embedded into a PNG (max of 15360 bytes). That's if you're saving to a PNG cart. If you're just saving to a .p8 version of your cart, you don't have to worry about the compressed size and can just keep going until you hit the other limits.
Hope that makes sense?
The 32k total for the .p8.png storage format is a 17,151 byte fixed format region of graphics and sound data, and up to 15,360 bytes of compressed Lua code. (256 bytes are reserved for format delimiters and, I'm guessing, future use.)
The uncompressed code limit is a bit of a historical relic, as it predates the compressed limit. The token limit, while a bit confusing, best corresponds to the amount of "meaning" in your code, and tends to correlate well with the other limits for typical code. The code is stored compressed in the final published .p8.png file, and so only the compressed code contributes to the 32k total.
Beware that the three code limits (65535 chars, 15360 compressed chars, 8192 tokens) all apply simultaneously, so whichever one you hit first is where you have to stop writing code. We get good use out of encoding data in code strings sometimes, but that tends to work against the compressed char limit even if it's efficient for tokens and uncompressed chars.
MBoffin's GIF is excellent but note that it represents the memory layout of the machine, not the layout of the storage format. The machine memory has the same 17,151 byte region for graphics and sound, and uses the rest of its addressable memory for the screen buffer, general purpose memory, and memory-mapped I/O, keeping the actual code accessible only to the Lua interpreter and out of addressable memory. I assume it's the storage format you're asking about, but maybe I'm mistaken?
so if i, say, save sound data as text string....the sound memory is still used even if i populated it at runtime with custom strings?
Thats basically my question...if data is immutable, then what data is it so i can think of ways to abuse it.
dddaaannn's last paragraph mostly says what I'm about to, but I wonder if another rephrasing of it might help any?
Cart ROM up to 0x4300 which is decimal 17152 is for
0x1000 gfx2/map2 (shared) 0x2000 map 0x3000 gfx_props 0x3100 song 0x3200 sfx
These add nothing to what the info command or the in-editor display report to you.
This plus the compressed code size of 15260 comes to 32512, or 0x7F00, just under the 32k limit.
If you convert your sprite data into strings, it and the conversion routines will come out of your tokens and chars.
"Colour format (gfx/screen) is 2 pixels per byte: low bits encode the left pixel of each pair."
"Map format is one byte per cel, where each byte normally encodes a sprite index."
You might be trying to save space by using only 2 bits for your sprite pixels, but it's still being saved as 4 bits per pixel.
With some cleverness you could squeeze 2 tiles into one sprite? (But you'd still need code to separate them, taking up tokens.)
Anyway, because the layout is set for the non-code items, you don't get any extra tokens for not using the GFX, map, SFX, and patterns - their space is still reserved - unless you can find a way to put your code or other types of data into them.
The above is my understanding, based on the pico-8.txt manual (which is where the quotes and quoted bit of the memory map are from). I've been here just about a month, so my understanding is tentative, but hopefully accurate.
(I typed the above before your most recent post. Yes the size reserved for it seems immutable.)
i think i understand that at run time, the sprite sheet and map data and sound data is limited to a fixed set...it's more or less...i guess if i'm clever I can squeeze tokens and that's where I can think most about compressing data?
Cause i realize cart memory and RAM are different...one is static, the other is swapped when needed...
So I guess I"m just not understanding what is what...cart size is ram? Token size is the most important? ???
I'm mostly asking cause i'm trying to figure out where to shove 'space saving tricks' in. If I can't do it in code/strings, i'm gonna put it in the map or sprite sheets...etc. It helps with planning the game scenarios to know this in advance.
I guess more specifically...
This is in the manual and I don't understand it.
Cart ROM (32k): same layout as base ram until 0x4300
So Cart ROM isn't...what? I don't get it.
Re "Token size is most important?"
The most important is whichever limit you are closest to - with the proviso for the p8.png as already mentioned by MBoffin.
(If you're using long variable names or object oriented programming practices, you're likely to hit the character limit sooner than the token limit, at a guess. If that's the case, at the moment the character limit will be the most important to you.)
Re: Cart ROM (32k): same layout as base ram until 0x4300
Both have 32K, but a different 32K. Your ROM is your cartridge - your code, GFX, map, SFX, and patterns. All put together as a distributable (fantasy) cartridge.
Pico-8 is a fantasy console. The console RAM is what you can work with while your program runs. It works by (as far as I understand it) copying from 0 to 0x4300 from your cart ROM into its RAM, then has usable/addressable RAM above that for the purposes MBoffin has shown with the very cool graphic.
Part of what this means is that at runtime, when you edit anything below 0x4300, you're actually editing the copy in the base RAM, and not editing your cart ROM.
I hope this makes it clearer about what's going on with the ROM and the RAM.
(I'm hoping that if I make an error in what I type, someone who has been here longer will kindly correct me.)
@dw817 It's just a set of images I made for part of a workshop I ran about PICO-8. You can see the individual images here in this presentation:
The GIF above was just those images stitched together into a loop.
[Please log in to post a comment]