Just finished a image compressor that makes strings around 2/3 the size of PX9. Sacrificing performance and tokens. But despite the overall text being about 10,000 chars less, it still takes up the exact same compression percentage
That's most likely because your algorithm is doing a lot of the same work as pico-8's built-in compression that is used on the cart itself. If that's the case, then your algorithm is probably still better for data that's going to be stored in ROM memory, such as for a separate data cart loaded into upper memory, but not for data stored in the code.
The a normal problem with compression: When you compress a compress data, it is possible, that it gets bigger. The lua-Sourcecode is already compressed. So when you want to store compress data, you should do it in the rom part (with cstore).
For example, when you store your picture and the sprite data and store it in the Sprite-part: You can copy the compressed data to the high-memory (0x8000 and above) and decompress the sprite to the sprite-memory-location.
Are there any examples of this. Cause I keep hearing about high memory but have no clue how it works. Whats the point of copying the data to high memory when I could just copy it to a table after the cart boots
this tool can help: https://carlc27843.itch.io/pico-8-source-compression-visualizer
There's a couple ways upper memory is useful. I've experimented with two and gotten good results. The first is the one I was referring to, and that yes, would involve using cstore(), and it takes advantage of the fact that upper memory isn't reset when switching cartridges. I've released a couple games that start with a check stat() for the parameter list (which is an empty string if you start a game normally), and use that to quickly switch to a different cartridge holding only data. The pure data cartridge then copies the contents of memory addresses from 0x0000 to 0x4000 and pastes them to addreses 0x8000 to 0xC000 or so (using memcpy()). The data cartridge then loads the original cartridge but with the parameter list containing some text indicating that data has been loaded. The effect is to get 16 kB more data into a game that can then run as if single-carted. If done twice, that can be increased to 32 kB.
The other usage of upper memory that I've found useful is similar, in that you need the data come from somewhere, but is more about run-time usage. Trying to draw data from a table can extremely slow, because transferring data between the pico-8 code and the engine memory takes time. However, transferring memory to and from different parts of the engine's memory takes much less time. To take advantage of this, I've found that copying multiple versions of the spritepage into upper memory and transferring different pages into the memory the spritepage normally takes up with memcpy() during the draw step is fast enough to do without slow-down, as long as you don't do any unnecessary transfers. That allows 4 times the sprite memory.
[Please log in to post a comment]
