by Sorunome » Tue Mar 29, 2016 11:31 am
So, for dynamic sprite loading....I think it would be a good idea as that allows us to use a great number of different sprites!
I kind of like the idea of how you have animated sprites at the end resulting in non-animated ones using fewer data. Am I seing it correctly that the animated sprites are two-frames?
Anyhow, here is what I propose: a 256-byte buffer for the currently displayed sprites for the tilemap (that is excluding player, enemies and stuff). 256 as in 32*8, maybe we could shrink it if it is too large, anyhow, here's what I'm thinking:
While loading the tilemap from the SD card fetch the sprite data from the card, too, only the one needed for this tilemap.
For great diversity I'd say we go beyond 256 different sprites, those fill up quickly and mainly only take space on the SD card anyways, which is next to unlimited for us. So two-byte identifiers for the sprite, that's 65536 different sprites which is more than enough!
Anyhow, here is what I picture the process like currently:
Load the entire 12*8*2 tilemap into RAM (192 bytes) (probably the screen buffer as that isn't used during screen transitions). Fill out (0xFFFF's) another 64 byte buffer, i'll call that used ID's for now.
Now loop through the temp-tilemap buffer, two bytes at a time as a sprite ID is two bytes in this proposed thing. For each encountered ID i'd check if it exists in the used-id-buffer, if it is, take the two-byte offset thingy and put it into the real tilemap buffer as that is the new sprite ID then, if it isn't do one of the following things:
Non-animated tile: loop through the used-id-buffer from the front, until the first blank space, write it's ID in and copy the sprite data into the 256-byte sprite buffer from the appropriate slot
Animated tile: loop through the used-id-buffer from the back, take up two slots (as animated tiles are two-frames, the second one could be marked with 0xFFFE) and write both of it's sprites to the 256-byte sprite buffer. Next adjust a one-byte variable for the marker where the animated tiles start.
If a tile is passable could be stored in a seperate 32-byte buffer, also allowing for an easy implemention of that 4x4 pixel grid for passable stuff, and animated tiles being walkable!
After this process the used-id-buffer and temp-tilemap buffer aren't needed anymore, thus me thinking of putting that into the screen buffer.
This way we could have up to 32 non-animated sprites or 16 animated sprites, depending on the need (and ofc anything in between, as long as the 32*8 bytes allow it). Or do you think that is overkill-too-much? Any other suggestions/ideas/maybe you don't like this?
EDIT: Oh, also, I reverted in that commit to my camera movement thing because I couldn't figure out your logic to keep the camera in bounds, feel free to apply your logics, though, as they looked more optimized, heehee
EDIT2: On an unrelated note, I updated GB_Fat to save two dynamically allocated bytes when performing a read.