A fully working and useful example of this method can be found HERE:
https://www.lexaloffle.com/bbs/?tid=31950
What follows is an exploration into CSTORE and, as of this thread, does not reveal any code that can be implemented for immediate and accurate use.
(09-27-18) TODAY I'll be working on proving it works with more than one cart.
Right. Well after fighting with CSTORE() and RELOAD() for exporting to BIN (Windows EXE), I have some very good news indeed.
It can be done, and this includes saving 8192-bytes of Online data.
When you are ready to create your EXE or export to HTML, use NO NAME at all when you make use of CSTORE and RELOAD, thus:
cstore(0,24576,8192)
and
reload(24576,0,8192)
If you'll look inside:
C:\Users\(yourname)\AppData\Roaming\pico-8\cstore\ |
You will see that a p8 file is auto-created with a rather busy name:
__df2cd15a5797c1a64936771c773d1edcee93b76b.p8 |
This then is the CSTORE data that you've saved, and it can be reloaded again, just make certain NOT to use a name even though by default that is what you would do with CSTORE and RELOAD.
Reload the webpage to test it.
Checked and works correctly in Firefox, Opera, and Google Chrome.
Hope This Helps !
... Alright, good news and bad news.
If you use CSTORE() or RELOAD() without a filename and you choose area 0-8192 (which is the tile area), you have no immediate way of recovering the sprites and they are overwritten with that data you put into it.
Meaning if you run this particular program in immediate mode, it overwrites the sprites from memory 0-8191.
I'm going to see if it's possible to temporarily save the sprite data to an array and then make use of CSTORE / RELOAD.
Okay here is what I have found.
While you can indeed use CSTORE and RELOAD without a name to load and save 8192-bytes of space, if you use memory location zero, this means you are directly modifying the very sprites you are saving with the cart.
Which means either in immediate mode or compiled, if you do use CSTORE for memory zero it will indeed overwrite this area - and it cannot be recovered except by a previous source code saved.
Apparently when ZEP put the compiler together, he felt it would be easier to save off the actual sprite table to an external file, and that is the file you are modifying when you do not give it a name.
Now this is good and bad news.
PRO
You can indeed load and save 8192-bytes of data for executable and export to HTML/JS.
CON
You cannot use any sprites except those you manually draw via POKE and PSET - unless there is some clever way of loading external data without transferring it to memory location zero first.
Doubly confirmed if you give a filename to CSTORE or RELOAD, as an EXE or export to HTML, it does not work at all. You cannot load or save any files with CSTORE or RELOAD.
I will experiment a bit more but I believe these are the limitations.
To answer an earlier question, different thread. Yes, it is saving a unique file ID each time so there can be no data overwriting of different carts or data collisions.
I am seeing now when you run the EXE it priority loads the sprite/memory set from \user\appdata\ first, if it exists.
If not, from the actual cart.
So when you do use CSTORE to memory location zero, you PERMANENTLY lose your sprite data even in rebooting.
And that sprite data will remain lost until you compile a new EXE, which in turn gives it a new file ID.
You can choose any other memory location besides sprite and it will corrupt that area permanently as well, sfx, music, sprite flags, mapper, etc.
Puzzling why this would be the case for data permanency. Still experimenting ...
. . .
PRINTH() does not save any files additionally when cart is compiled.
Using CSTORE/RELOAD method of no filename also works with SPLORE.
. . .
Right. Well, there's no way around it. Now if ZEP wants to open up a new memory area that is saved with CSTORE(), that would be fine. Failing this, although you can actually save 8192-bytes and as a cart that is exported .BIN/.HTML/.JS/Splore and Online post, whatever memory location you choose in CSTORE() to store your data will irrevocably be overwritten until recompiled.
So ... the immediate solution is to write your own graphics/sprite handler in your source code cart. You do that, you won't need to worry about the sprite space (0-8191) and 8192-bytes will be immediately available for you to load/save between formats and browsers.
I'm making this a support ticket so ZEP can see it and maybe he can have some kind of solution like allowing filenames for CSTORE when compiled to an external package.
[Please log in to post a comment]
