Optimizing tilemapping / sd card access for large games
Posted: Sun Mar 20, 2016 11:09 pm
So, I thought, why not optimize tilemapping for large games?
By that I mean that quite a few people are complaining about the gamebuino not having enough ram, which i can totally understand, 2KB is very limited. Nevertheless I thought of trying myself on a simple tilemapper + moving engine which loads it's tilemap data off of the SD card, only to see actually how limited we are.
At the end of the game I ended up with 12,832 bytes of PROGMEM (41%) and only 874 bytes of ram for the global variables!
While I can clearly see the PROGMEM being an issue rather quickly, I am quite surprised (in a positive way) with how few RAM I managed to pass.
Now you are probably saying "wait a second sorunome, a screenbuffer is 512 bytes and sd card accessing needs a buffer of 512 due to the sector size....that alone already adds up to 1024 bytes"
Well, you are totally correct, but it turns out you don't really need that big of a buffer for the sd accessing, you might as well only store like the first 10 bytes of the sector and just ignore everything else, so on I went modifying tinyFAT for a read-only mode which allows you to specify buffers!
However, soon I ran into an issue: since I didn't want to look too deep into how FAT is working and copypasted a lot from tinyFAT the initializing and file searching would be quite hard with a buffer less than 512 bytes........my sollution was that for initializing the filesystem and searching for files I use the screenbuffer! Yes, this will corrupt the screen buffer every time you search for files, but I designed my custom file library in a way so that you can keep a file easily open throughout the whole game, the class only has one 2-byte variable so I guess that's about the size of ram needed to keep a file open, so the thought is to just open all the files in the beginning.
My demo with 874 bytes of ram include the following bigger chunks I can pinpoint easily:
512 (screen buffer)
96 (tilemap buffer)
24 (sprites)
--> 632 bytes --> 242 bytes used by misc. other stuff, such as camera position, open files, player positions etc. The gamebuino library itself also has quite some things.
For the sprites, I thought of maybe writing an engine which will dynamically flash the sprites to PROGMEM from the sdcard, so that a screen can maybe only consist of like 20 different sprites.
Anyhow, I will upload code once I got my sd library to not derp around if your program is larger than 512 bytes (one cluster), currently it assumes that data is in sequence while it may be fragmented. Or maybe I should leave it that way as game files aren't edited on the card thus fragmenting is way more unlikely to happen, what do you guys think?
Also, if people are willing to help (story + map + sprites + programming) I'd be willing to push this forward to an actual game! ^.^
By that I mean that quite a few people are complaining about the gamebuino not having enough ram, which i can totally understand, 2KB is very limited. Nevertheless I thought of trying myself on a simple tilemapper + moving engine which loads it's tilemap data off of the SD card, only to see actually how limited we are.
At the end of the game I ended up with 12,832 bytes of PROGMEM (41%) and only 874 bytes of ram for the global variables!
While I can clearly see the PROGMEM being an issue rather quickly, I am quite surprised (in a positive way) with how few RAM I managed to pass.
Now you are probably saying "wait a second sorunome, a screenbuffer is 512 bytes and sd card accessing needs a buffer of 512 due to the sector size....that alone already adds up to 1024 bytes"
Well, you are totally correct, but it turns out you don't really need that big of a buffer for the sd accessing, you might as well only store like the first 10 bytes of the sector and just ignore everything else, so on I went modifying tinyFAT for a read-only mode which allows you to specify buffers!
However, soon I ran into an issue: since I didn't want to look too deep into how FAT is working and copypasted a lot from tinyFAT the initializing and file searching would be quite hard with a buffer less than 512 bytes........my sollution was that for initializing the filesystem and searching for files I use the screenbuffer! Yes, this will corrupt the screen buffer every time you search for files, but I designed my custom file library in a way so that you can keep a file easily open throughout the whole game, the class only has one 2-byte variable so I guess that's about the size of ram needed to keep a file open, so the thought is to just open all the files in the beginning.
My demo with 874 bytes of ram include the following bigger chunks I can pinpoint easily:
512 (screen buffer)
96 (tilemap buffer)
24 (sprites)
--> 632 bytes --> 242 bytes used by misc. other stuff, such as camera position, open files, player positions etc. The gamebuino library itself also has quite some things.
For the sprites, I thought of maybe writing an engine which will dynamically flash the sprites to PROGMEM from the sdcard, so that a screen can maybe only consist of like 20 different sprites.
Anyhow, I will upload code once I got my sd library to not derp around if your program is larger than 512 bytes (one cluster), currently it assumes that data is in sequence while it may be fragmented. Or maybe I should leave it that way as game files aren't edited on the card thus fragmenting is way more unlikely to happen, what do you guys think?
Also, if people are willing to help (story + map + sprites + programming) I'd be willing to push this forward to an actual game! ^.^