How To
Persistent RAM
UxoZii 2020-06-13 20:57
I'm trying to save a 150x150 array that represents a map, but 4kb of memory is not enough (1 byte being 1 element from the array, 22,5k total). I tried some techniques to compress the numbers down but i only got to a minimum of around 18kb, and it would only grow if the player builds on the map.
Can I use a virtual disk to store the map? The FILE, SAVE, ... commands are a bit confusing to me, I want to make sure that it's possible before trying to fully understand these commands.
S3B4 2020-06-13 23:03
How many possible states will each element of the map have? if its less than 255 you could try holding more elements per byte. For example if you decide each cell will only have 16 states (half a byte) you could reduce the amount of space needed to 11.25k. Still too much but that alongside a compression algorithm could help.
UxoZii 2020-06-14 01:14
I thought about this but i want to keep It as a byte for every element, it keeps stuff simple and doesn't help much anyway. My last hope is for FILE to work as i imagine it does, but i cant figure it out for some reason
S3B4 2020-06-14 01:49
For the FILE alternative you would have to first get the program to write the data of the map to a memory address like the working ram, then use the SAVE command to save it to a ROM with the size being the size of the map itself. But even working ram has less than 22kb
was8bit 2020-06-14 05:39 (Edited)
FILE SAVE is designed for tool use only... like CHAR DESIGNER needs to be loaded as a TOOL, then you use it within a program to edit the char file in that program...
When you run a TOOL program as if it was a game (and not from the tool menu) it creares and uses a game file called DISK.... theoretically you use this to actively save and retrieve to data file in this DISK file, although this feature is supposed to act as a fail safe to prevent NX from crashing....
People playing your game would have to be aware it used DISK to store the games map data, and this makes it a hazzard in that ANY tool could potentially edit or delete that data file...
It does open up the possibility of sharing a game status with other playes, as on someone could get a game started pretty good, copy paste the game into a seperate game and share that for others... others though would have to know that they have to copy paste that data file into their DISK game so your game would load and play that...
It would be an advanced feature, not for newbie players.....
I have added a test of my theory...
was8bit 2020-06-14 05:50 (Edited)
One thought about map data compression.... one trick could be to create zones... a zone is area of upgrading, and when upgraded that zone is then set to a higher or different status..
Example, lets say zones are 5x5... they all start out as empty with a basic status of the empty land's potential ...
Then say zones can be upgraded to a factory, and neighborhood of homes, (like in sim city) and each completed zone functions as a single entity that connects and interacts with other zones...
You can limit how many zones can be upgraded at a time, and or, also possible that partial incomplete upgrades get lost at game save/end... so you only need to save zone states, and possibly one zone's details of its partial upgrade...
was8bit 2020-06-14 05:54
Oh, and i have already tested the idea, and a TOOL, ran as a TOOL, cannot access the parent game's PERSIST memory... if it COULD, you could temp save upgraded game data in PERSIST, then use a specially made tool that read the game's PERISIST and added it to a master FILE in the game code...
Timo 2020-06-14 07:27
Maybe you could just save the RANDOMIZE number in persistent memory, then the world generator would have always the same result.
And then you only save the changes the player makes. Maybe keep the original map in one array and a copy of it in another array where you make the changes. And when you save it, you somehow only store the differences.
This is just an idea, maybe it’s too complicated, I never tried it.
Or maybe just make the map smaller?
UxoZii 2020-06-14 12:12
Hmm... well that sucks that I can't really use a virtual disk.
I guess the only possible thing to do would be timo's technique, saving the differences between the original and modified map, the player could technically make up to 1,3k+ changes to the map.
Or unfortunately, simply reduce the map size, which i really didn't want to do. Damn i miss DIM PERSIST
S3B4 2020-06-14 12:21
The simplest way of compression i can think is that theres 2 bytes, the second one is cell of the map, the first one is how many times that repeats. E.g a map that goes something like:
1 1 1 1
1 2 2 3
3 3 3 3
6 6 8 8
would be changed to:
5 1 2 2
5 3 2 6
2 8
the problem is that if a number doesn't repeat at all it would add an unnecessary byte, it only helps compress when a cell repeats more than twice.
nathanielbabiak 2020-07-29 21:34 (Edited)
Check out the "General Purpose" heading here:
https://en.wikipedia.org/wiki/Lossless_compression/
and then try to implement something from here:
https://www.rosettacode.org/wiki/Category:Compression