More of a question for the devs who are familiar with the way tilemaps are stored (cough cough @richard couch cough)
In a stream i don’t know when, you mentioned that images take up alot of space, same for tilemaps, where for every tile you need to know exactly which tile it is and if it is a wall (correct me if i’m wrong).
My idea was storing tilemaps as strings of text that the game can then turn INTO tilemaps, hopefully reducing space. (See my tilemap-to-text attempt here: Tilemap to text)
My question is: would storing strings of text like this take up more bytes than having all the actual tilemaps in the project?
Images take up a lot of space, yes. They’re already stored in an idealized form when saved in a project, so saving images yet again in a different format likely will not help.
Tilemaps, themselves, do not take up much space. It’s the images for the tiles that do. So, ditto above.
Best advice: Use the asset manager for all of your assets (images, music, tilemaps, etc.).
This is a great idea! So great, in fact, that it’s actually how they work already! If you open up JavaScript, you can see in the tilemap files that strings of text are already how they are stored:
that’s not entirely true, actually. we do store them that way in jres project files but they are converted to binary when the project is compiled.
the reason we store them in base64 is because it’s a nifty way to store binary data in text files that’s guaranteed to not use any character that are out of range for UTF-8, which is the encoding used for said text files.
to expand on what alex said, tilemaps are stored in three parts:
the tileset, which is just an array of images
the tile location data indices. this is a Buffer that contains one byte for each location in the tilemap, the value of which is an index into the array of tileset images
the wall data, which for historical reasons is stored as an image with the same dimensions as the tilemap
so if you wanted to calculate the size of a tilemap, it would be like this:
(size of all tile images) + (tilemap width * tilemap height) * 1.5
the 1.5 in that equation comes from the fact that each location takes up 1 byte in the indices array and half a byte in the wall image (arcade images are 4 bits per pixel, which means each byte contains two pixels).
you may have recognized that there is in fact an improvement that could be made here: walls don’t need to be stored as 4 bits per pixel, we actually only need 1 bit per pixel since they are simply on/off. why are they stored that way? well, we originally wanted to use those other 3 bits for additional data but never ended up doing so.
anyways, none of this actually matters very much because on average tilemaps are smaller than images. think about it, how often do you make a 160x120 tilemap? but you make 160x120 images whenever you make a background image. that’s why whenever someone is having size problems with their projects the issue is always too many large images. i actually can’t recall ever having tilemaps be the culprit.
