Log In  

I'm surprised there doesn't seem to be a way to permanently write bytes to the memory and save it with the cart, so you can make your own efficient level storage format. That memory only becomes available to write to at run time - then any changes you make are reset.

My idea would be to have a level data format for a game that only shows one screen at a time (no scrolling) and has a stream of data that is - sprite cluster index (eg. 1 could be a group of trees, 2 could be a house) and an X Y position on screen.

I could kind of store the "level data" in the code by actually specifying screen positions but this is incredibly wasteful - each character is worth one byte, and I'd need several bytes just to set one position. Eg. "X = 54" is 6 bytes and I could store that in 1.

Am I incorrect - is there some way to store a sequence of bytes on the cartridge? (Besides the tiny "Persistent cart data")

P#19333 2016-03-21 06:31 ( Edited 2016-03-27 02:54)

Maybe someone has a better suggestion... but I know there is a convoluted way to accomplish this sort of thing. It involves writing data to the spritesheet or map data memory while your cart is running, then using cstore() to commit what's currently in memory back into the cart. That stuff is then saved with the cart like usual. You have to write your own functions to write and read this data as integers, if that's what you wanted to store. I have an example of this but I'm not sure how helpful it is, because the code isn't very pretty.

When you run this, what you're watching is my keypresses being replayed. (It was just a silly message to a friend.)

Cart #19334 | 2016-03-21 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#19335 2016-03-21 06:43 ( Edited 2016-03-21 10:43)

This is something, which scratches the limits of Pico-8 and its concept. To do such more complex stuff, it becomes handy to write a cartridge generator to write the custom data into the memory, including the lua codes (which gives you a more user friendly editor by the way). If you need the sprite and map memory and extra level memory, best practice can be to use two cartridges from the beginning, I made some very good experiences with this.
I ranted on the lack of custom memory already, although there was no reaction from the developers on this. The best workaround is really to use two cartridges, which gives you, depending on your technique, at least 16kb of memory. Maybe one can even store data in the code segment of the second cart, which opens even more space, as this can be up to 64kb which need to be compressed below 16kb, but I haven't tried that in practice yet.
Several pico-8 users, including me, are using python to do the generator scripting.

P#19340 2016-03-21 07:06 ( Edited 2016-03-21 11:06)

Thanks guys! I'm not sure but I think solar's method is what I'm after since it's the most simplest - I think. (SunSailor let me know if you disagree).

solar that looks like you just write data to the level area of RAM, and then use cstore() to put it directly into the cart, this gives you data that you couldn't have placed using the level editor (not easily anyway!) I can write a function that serialises my data.

The only reason I'm not sure about SunSailor's method is because it involves running another language and I have no idea about running Python.

P#19427 2016-03-26 21:01 ( Edited 2016-03-27 01:20)

Although I see the concept in both your posts - you use 2 carts - one as a level editor, and it writes the actual game cart.

P#19428 2016-03-26 21:18 ( Edited 2016-03-27 01:18)

I did a write up on how this might work, would anyone like to comment and see if I'm on the right track?


P#19430 2016-03-26 22:54 ( Edited 2016-03-27 02:54)

[Please log in to post a comment]