To load this cart, in Pico-8 immediate mode type:
LOAD #VVM-6 |
UPDATE: 09-27-19
- Sped up load/save to external file process considerably by using internal temporary storage.
-
Converted loose initialize to function.
- Added "Skeleton" file to make it easier for others to use. Includes the only 3-functions you need to make it work, but for loading and saving. Found HERE:
-- skeleton file
function _init()
initvar()
end
function _update()
var.test="ready"
var2file("*")
stop()
end
function _draw()
end
function initvar()
function var2file(filename)
function file2var(filename)
|
To load this cart, in Pico-8 immediate mode type:
LOAD #VVM_SKEL-0 |
UPDATE: 09-26-19
Added ability to recall all software changes to sprites,mapper,sounds, and music even if you change them via POKE() in your code. Before after you loaded or saved your VARS it would only reset to what you have default in your cart. Code is a little slower because of this but works fine. New temporary file "_" is created because of this - but data is not affected.
. . .
Back when PICO-8 first came out, it was announced that you could load and save externally 64-numbers per cart. And life was good.
Then someone realized that this is actually 256-bytes and wrote routines to directly access that memory. And life was better.
Another person took that and said that 256-bytes could be broken down to 2048-switches. 8 bits per byte. And that was an interesting find to say the least.
Now me ? I've always been interested in compression - ever since I created S2 those 20+ years ago and wrote in it, that's right, the same name but a different method, a Virtual Variable Minder to keep track of all of my player and companion attributes and inventory.
I've also been experimenting with memory storage and recall in Pico for years now. At one point I wrote code that let you save up to 4096-bytes of memory at the cost of half your sprite space. It was good but the disadvantage was that you could only have one-save file per cart. I know this could be improved upon if I worked at it.
So now that ZEP has finally fixed the memory problem I was experiencing in an earlier version of PICO, I am successful - and do have a good grasp of how to work with up to 12288 bytes of memory that be both loaded and saved to an external file and touches no sprites, no mapper, no sound, and no music memory. And you can have as many as you want. You will find how in the routines I wrote here.
Now it is only recently I have discovered the use and power of "Variable dot." That is, any variable followed by the period key. The real advantage is that you can set any variable with it and later recall all the variables that match the prefix with my DLLs (and that's what I'm calling these routines).
In this, I have written 2 useful functions. One of which will save all your vars to any filename you want. Works everywhere:
- immediate mode
- EXE export
- run in Splore
- run in Lexaloffle's BBS
- offline HTML export
It truly does work everywhere. And you can still have any number of files no matter the port.
No need for messy arrays, pokes, or anything like that. I have done all this work for you. Here are some examples of variables that can be loaded and saved easily in one pass.
var.name="george"
var.newname=""
var.hits=100
var.maxhits=250
var.expr=0
var.encounterrate=2.25
var.map={}
for i=0,15 do
var.map[i]=i*3
end
var.equip={}
var.equip[2]="bronze sword"
var.equip[41]="silver armor"
var.equip[836]="wooden shield"
var.equip[1531]="copper helmet"
var.equip[25493]="leather boots"
var.flag={}
var.flag["key"]="gold"
var.flag["wand"]="ruby"
var.flag["apple15"]="delicious"
|
As you can see you can have quite non-standard variables as well. To save these call the function, VAR2FILE(filename). If you just want to view all the variables for debugging, choose the filename of "*" instead.
To load back your variables (and it doesn't need to be the same cart), call the function FILE2VAR(filename) where the filename is the same as the one you chose above.
And YES this does mean that you can indeed save multiple files since the filename can be anything at all and well exceed 65536 bytes of storage or even more.
There is one catch, I am using the "{" and "}" keys as markers for variable data storage and recall. Do not use these two-characters in any capacity for strings or string arrays. You do that and my program will work just fine.
I am also adopting a new stance. Years ago back in BlitzMAX DLLs were bandied about quite a bit. These were very popular often over standard released sourcecode in that you could "fire and forget" without ever having to worry about the actual source-code itself.
Therefore I am hanging up the cape of the dw817 laboratory. Instead it will be the dw817 Magic Shop. Good powerful routines but each in one magical line of code instead of 20-30 with massive remarks like I did earlier.
So too have I done that with these functions. They are each only one-line long and written about as small coding as is possible for me. You copy those two-lines plus the one line to initialize your "VAR." and you're DONE. No need for anything else - should work in any program and in any capacity.
Thanks especially to those who helped me understand dot variables and how to view them all via PAIRS(). I could not have done this without you !
Included now is a full cart demonstrating its ability to both load, view, and save. Notice when the variables are viewed for debugging that I have made use of { } in data separation.
IF YOU USE PLEASE LET ME KNOW !
[Please log in to post a comment]
