Hi, I'm planning out my next game, and I was thinking about sharing the code between carts:
For example, there is cart a:
function a() cls() end |
And b:
-- load doesn't work so, it loads a cart a() -- somehow |
Any way to do that? Reload shouldn't help with code... Zep, maybe you could include this in 0.1.11?
Thanks!
1000 is not a power of two, either 1024 or more, but I think, 8k is a good amount. I just need more for storing data like mobs and etc.
Ok, I feel kinda stupid now...
For some reason, I thought that the User Data was "Read Only" portion (e.g. the actual cart code).
I didn't realise it's another area we can push & pull data to. D'Oh!
#EveryDayIsASchoolDay
@LiquidDream: You were half right thinking that; it only exists as RAM and can't be written to a cart's ROM the way you can do with gfx/map/sfx data.
But during runtime you can use it to store decompressed data, a (partial) screenbuffer, fonts -- all kinds of neat stuff :p
And if you want to use multicart features, you can grab data to pop in there directly from another cart's gfx area or whatever.
It's unlikely that PICO-8 will ever be able to load more than 8k tokens of code at once (for the usual reasons -- keeping size restrictions meaningful etc.), but it sounds like in this case converting the data to binary and cstore()ing / reload()ing it might indeed be sufficient.
e.g.
-- store data (probably from a separate dev cart) for i=1,100 do poke(0x42ff+i, mydat[i]) end cstore(0,0x4300,100,"mydat.p8") -- load data (from the main cart) reload(0x4300,0,100,"mydat.p8") mydat={} for i=1,100 do mydat[i]=peek(0x42ff+i) end |
This example only works for numbers 0..255, of course -- if you need to store strings and other types of data it might not be the best approach.
[Please log in to post a comment]