okay, i've got saving/loading working in Jimi Can Not Read now!

for starters, i've got to keep track of the current map x and map y, as well as player's x and y coordinates. these are compressed as four 8-bit unsigned integers into one 32-bit integer for saving in TIC-80's persistent memory. these values never go above 240 in TIC-80, so 8 bits is enough.

but there's some more game state to keep track of. the unlocked letters are packed as true/false values into one unsigned 32-bit integer. i also made a sorted list of all doors that require a certain letter, and packed their open/closed values as true/falses in another 32-bit integer.

and what about the textboxes which have letters taken out of them? well, i had a problem with overthinking this, because there's the issue that letters can be removed from any position in the textbox message string. i first thought i'd have to do some complex caching to keep track of each individual letter that's been collected.

but this turned out to just require a simple loop over removed letter indexes.

local remj=j
for l=1,31 do
    if tb.rem[l] and l<=remj then remj=remj+1 end
end
tb.rem[remj]=true

the indexes can be again compressed as true/false values into a 32-bit unsigned integer.

yeah it's hard to explain, so i'll use an example.

let's say the message we're printing into a textbox is 'JIMI COULD NOT READ'.

and let's say the player has access to letters E and A.

they hit the textbox, and the E gets taken away. there is no previous remj, so it's saved at index 17 (note that the index starts at 1 because Lua).

but on the next frame, they hit the textbox again, and the A gets taken away from the new string that's missing an E. now its index is also 17, which won't do!

here's where the loop comes into play: we're looping over 31 previous index values, and we notice that there's already an index 17 (from the E). so, remj gets incremented by 1, so that the A's index becomes 18 - as it should be when looking at the original message. and the A's index is saved as 18 so we can do this process again if needed.

all this code does is resolve which index of the original, full message each letter corresponds to, even when dealing with a truncated message.

with this info stored into the bits of a 32-bit integer, we can rebuild the truncated string when loading the game. (the game actually saves 31 index bits and uses the last bit to mark whether a textbox is active or not.)

---

like i said, i was originally overthinking this - the loop i wrote is a pretty elegant solution.