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.
Ok, thanks, zep. Then I should think @enargy's solution with interpreting functions. (I was planning to store enemies AI in the second cart)
[Please log in to post a comment]



