#175765 - JanoSicek - Thu Feb 03, 2011 3:50 pm
tl;dr = 24MB of sprites in filesystem, how to animate them in real time?
I am thinking about a 2D game with a lot of sprite animations. For simplicity sake let's make all sprites 32x32 in 256 colors. Each frame is 1024 bytes uncompressed. I am not worried about 128 sprite limit, maximum concurrent sprites on screen will definitely be smaller.
However for animation I am assuming 5 different facings (N,NE,E,SE,S+others done with flipping) for each of the 6 animations (stand-still, walk, attack, get-hit, die, change-to-battle-stance). If we use ~8 frames for each animation, this ends up with 5*6*8 = 240 frames = uncompressed 240 kB per character.
Let's assume some standard D&D game, which would need characters Human,Elf,Halfling,Dwarf each with different armors&weapons. Baldur's gate uses composite sprites, where they joing character+helmet+weapon+shield from 4 different sprites into one. For simplicity let's assume all characters are already pre-rendered with all their weapons&armors. We will end up with 100 characters, each having 240kB, total is 24MB of animations.
At any moment there will be only a small number of frames visible, however it is not really feasible to stream the data from filesystem to VRAM, right? The benchmarks show it takes 6-10ms to copy 16kB. Should I build a cache in RAM (for example 1MB) and use it as an intermediate cache between filesystem and VRAM?
So that 24MB of characters on filesystem will be cached in 1MB of RAM, on their way to the 128kB VRAM dedicated to sprites.
Would this work? During every frame, look what frames are missing in RAM cache and download them from filesystem. If there is still time, maybe try to prefetch subsequent animation frames to RAM. If there are too many frames missing, we will end up with a frame skip. For 30FPS game we should be able to copy up to 88kB between two frames, and that should be more than enough for 10-20 characters I expect to see onscreen.
How much would compression help? I understand there are 3 algorithms in BIOS (huffman, LZ77 and RL). They would save speed for copying from filesystem, but would slow down copying from cache to VRAM. I tried googling for speed benchmark, but I haven't found anything relevant for GBA/NDS. 1kB sprites should compress very nicely, as 50% of the sprite is transparent color usually.
I am thinking about a 2D game with a lot of sprite animations. For simplicity sake let's make all sprites 32x32 in 256 colors. Each frame is 1024 bytes uncompressed. I am not worried about 128 sprite limit, maximum concurrent sprites on screen will definitely be smaller.
However for animation I am assuming 5 different facings (N,NE,E,SE,S+others done with flipping) for each of the 6 animations (stand-still, walk, attack, get-hit, die, change-to-battle-stance). If we use ~8 frames for each animation, this ends up with 5*6*8 = 240 frames = uncompressed 240 kB per character.
Let's assume some standard D&D game, which would need characters Human,Elf,Halfling,Dwarf each with different armors&weapons. Baldur's gate uses composite sprites, where they joing character+helmet+weapon+shield from 4 different sprites into one. For simplicity let's assume all characters are already pre-rendered with all their weapons&armors. We will end up with 100 characters, each having 240kB, total is 24MB of animations.
At any moment there will be only a small number of frames visible, however it is not really feasible to stream the data from filesystem to VRAM, right? The benchmarks show it takes 6-10ms to copy 16kB. Should I build a cache in RAM (for example 1MB) and use it as an intermediate cache between filesystem and VRAM?
So that 24MB of characters on filesystem will be cached in 1MB of RAM, on their way to the 128kB VRAM dedicated to sprites.
Would this work? During every frame, look what frames are missing in RAM cache and download them from filesystem. If there is still time, maybe try to prefetch subsequent animation frames to RAM. If there are too many frames missing, we will end up with a frame skip. For 30FPS game we should be able to copy up to 88kB between two frames, and that should be more than enough for 10-20 characters I expect to see onscreen.
How much would compression help? I understand there are 3 algorithms in BIOS (huffman, LZ77 and RL). They would save speed for copying from filesystem, but would slow down copying from cache to VRAM. I tried googling for speed benchmark, but I haven't found anything relevant for GBA/NDS. 1kB sprites should compress very nicely, as 50% of the sprite is transparent color usually.