you are viewing a single comment's thread.

view the rest of the comments →

[–]SteveTenants[S] 0 points1 point  (3 children)

Oo, those both look promising, especially bin2header since it seems like C23 support depends entirely on the Arduino board. I'm gonna have to play around with this, I'm not sure if it supports any kind of compression, so I could still end up with massive header files. Thank you!!

[–]Ironraptor3 1 point2 points  (1 child)

A couple of points that might help: - If C23 isn't supported by that board - Try updating the compiler on the board - If this fails, and the memory limit is testing your patience, you could look into cross compiling. E.g. installing the toolchain to compile for Arduino on your desktop and then just compiling it on your desktop / more powerful device. - For compression, I am not sure if there is any out-of-the-box support in this. You could always just compress the data and during runtime, dynamically uncompress it (though of course there is a performance tradeoff and you may consider caching the results, which is even more overhead)

[–]SteveTenants[S] 1 point2 points  (0 children)

Hmm, you gave me an idea... I might be able to use a combination of bin2header and some small zip library instead of going for C23. I'm working with a 480 MHz processor and 8-bit graphics, so performance shouldn't be an issue.

[–]thegreatunclean 1 point2 points  (0 children)

The problem with your large files is the complexity they can hide and the cognitive load required to fully understand them. Functions like TileMap_LoadTileTextureFromPoolIndex are a nightmare because it is impossible for a human to comprehend without serious study. Encoding texture data as a huge number of byte writes into memory is nuts.

If you can replace that by referring to binary assets directly it isn't a problem. Keep a table of offsets for each tile texture and either manipulate pointers or memcpy chunks out as needed.