Ok, so calc84maniac suggested something interesting on IRC just now that involves the usage of pictures to store data instead of using lists, matrices and variables. Someone talked about this before somewhere for use on older calcs, because if for example all data are multiples of 8 that can range within 8 values, then each data would take 1 byte of RAM instead of the 9 bytes each list elements take, something that could have been handy for games that has an extremely large amount of enemy data, for example, as long as the entire pic is used in order to not waste space. Of course, by using such method of data storage, you sacrified parts of the graph screen, so it was more useful for ASCII games in most cases. Also such technique might be very slow if the data has to be accessed in that form very often so it would be best to uncompress it only when needed.

Now on the TI-84 Plus C Silver Edition we face the issue of having around 2500 bytes fewer RAM, limiting space even more for unarchived data loading. However::

1) What if 84+CSE pictures could be recalled directly from the archive like images?
2) What if the Pxl-Test() command still existed?

Basically, you could stream data directly from archive!

Not only that, but if Pxl-Test was upgraded to make the difference between each color, then you could store even more data in 1 pic!

So far we still don't know if the 2 criterias above will be met, but if they do, what do you think about his idea? And do you have any example of code using such technique on the TI-84 Plus? I had some ideas although I'm going to bed soon, but basically it would still be possible to have dozens and dozens of different values using only 8 pixels, and if the resulting numbers are too low, then all you have to do after uncompressing the data is multiplying them.



And of course if you need accurate values access, you could use 27 pixels for values from 0 to 999, where the first 9 pixels are for 0-9 (0 being no pixel turned ON), the next 9 are for 00-90 and the last 9 for 000-900

What do you think?

Yeah, same since it was brought up far after I stopped BASIC. However I wish I knew it back then since my RPG map data didn't fill pics completely. I could have added even more monsters maybe.

Also I edited my post with a pic showing an example of enemy data compression, but that wouldn't be handy for save data so for numbers from 0 to 999, I posted another suggestion.

Yeah it depends of the calculator. On the 84+ series it's very common for games to not use the graph screen at all, so you can store data on the graph screen (and pictures) as you wish. If you absolutely need to use the graph screen for the game, then something you can do is store your data in a part of a picture and other stuff in the other part. If there isn't much data in the pic, just erase it with Line() or something.

And of course, there are other creative ways to sneak data into games, even using it for graphics! For example, let's say that your RPG has a dozen of enemies with 5 stats, where HP takes 8 pixels, Exp 4, Gold 4, ATK 4, DEF 4, the possible attacks 5 and the sprite ID 3. This means 32 pixels per enemy. If, for example, that RPG has 13 enemies/bosses total, then just make a nice title screen with a border and store the data INSIDE the border. Since in such case the data only fills 1/4 of the border (the top-left part of the screen), then just mirror the data on the right part then the 2nd half!



Then your data takes zero space (only the routines to uncompress it do), since it's just part of your 779 bytes title screen. (or 767 if you don't use the last row)

Indeed. Also for the example above one thing that might be best for some data is to make it so it is guaranteed to start at 1, else it remains at 0 anyway due to 0 being multiplied by anything giving 0 . That way you save 1 pixel.

Another wacky data storage idea if you really don't mind strange enemy data is if your tilemaps are stored inside pics and you have a map like a forest with strange paths and no rectangular areas, then you can just use those pixels to store enemy data. (But then you better have your maps so that there are no risk of seeing a LV1 enemy with 40000 HP, 2 attack, giving 9000 gold and 1 experience point, followed by a LV 30 one with 2 HP, 10 attack and giving 1 gold ).

In any case, this technique would be very handy if you're creative. But if you don't have much data to store, then it might be a waste of space if you can't manage to keep the decompressing routines code+compressed data itself smaller than how the data would be if uncompressed.

Instead of using 27 pixels for a number like 999, you can use only 10 by storing it as binary. Then again, if it is 16-bit color and pxl-Test( can return the precise value, then you will only need one pixel.

I have made BASIC programs that convert pictures to lists or lists to pictures, too I remember I used a picture to store all of the game data for an RPG once and the save screen was kind  of cool because the user could watch their data being modified ^_^

Then that is still 4 bits :] and that means 12-bit numbers can fit in 3 pixels so 0~4095

It would be so awesome if pxl-test() returned the pixel color

I think that the new color tokens just return a number so that would be the same then as
If <greennum>=pxl-Test(Y,X