#170677 - gusano - Sun Oct 11, 2009 5:03 pm
I'm trying to code a platformer by doing 2D graphics via the 3D hardware (using glOrtho and drawing quads). My main character has several sprite sheets for his different animations (idle, run, climb, jump, ranged attack, melee attack, getting hit, death, etc) As far as I know, I can have at most four 256x256 textures in VRAM at one time, because only VRAM banks A-D can be used for textures and if I'm not mistaken, each bank can hold a single 256x256 texture (or two 128x128 textures.. and so on). Assuming each of my sprite sheets is 256x256 pixels... I can only have 4 animations loaded at one time. BTW, each sprite sheet has 16 frames in it laid out in 4x4 tiles of 64x64 pixels each. Out of the following approaches, which would you recommend most?
1. Resize my sprite sheets to 128x128 to be able to have 8 textures loaded at a time, sacrificing visual quality. (I'd like my character to occupy close to 1/4 the screen size of 256x192)
2. Keep only the textures being used right now in VRAM, and when I need a different one (like switching from melee atack mode to ranged attack mode), load the texture on the fly, swapping an existing one with the new one. Is this a slow process on the DS? I'm using loadPCX() from <nds/arm9/image.h>.
3. Look for a hack that allows me to load more textures into VRAM (possibly into the other banks... although they have less memory)
4. Scrap the 2d via 3d idea and try to do it using hardware sprites (how would this work for animated sprites? I'd still have the same VRAM limit wouldn't I?)
5. Take out a few things from my game design (choose a single attack instead of ranged + melee) to reduce the amount of animations.
6. A different solution I haven't thought of
Thanks for reading this kinda long post... and thanks in advance for any info you can give me!
*EDIT:
For #2 I could keep all the PCX's in regular RAM and only the four I need in VRAM. That way, the only thing I would need to do on the fly is glTexImage2D (copy the image data from RAM to VRAM). That may make a considerable speed difference.
I could also cut out every other frame from my animations. They won't be as smooth, but some of them may not look so bad. When I said 16 frames above I was exaggerating... the animations are between 8 - 12 frames. But I tried skipping frames on a "run" animation and it didn't look so bad.
Since the animations don't really use 16 frames, I could also combine some animations' sheets with other animations' sheets to avoid leaving any empty spaces in the 256x256 images.
1. Resize my sprite sheets to 128x128 to be able to have 8 textures loaded at a time, sacrificing visual quality. (I'd like my character to occupy close to 1/4 the screen size of 256x192)
2. Keep only the textures being used right now in VRAM, and when I need a different one (like switching from melee atack mode to ranged attack mode), load the texture on the fly, swapping an existing one with the new one. Is this a slow process on the DS? I'm using loadPCX() from <nds/arm9/image.h>.
3. Look for a hack that allows me to load more textures into VRAM (possibly into the other banks... although they have less memory)
4. Scrap the 2d via 3d idea and try to do it using hardware sprites (how would this work for animated sprites? I'd still have the same VRAM limit wouldn't I?)
5. Take out a few things from my game design (choose a single attack instead of ranged + melee) to reduce the amount of animations.
6. A different solution I haven't thought of
Thanks for reading this kinda long post... and thanks in advance for any info you can give me!
*EDIT:
For #2 I could keep all the PCX's in regular RAM and only the four I need in VRAM. That way, the only thing I would need to do on the fly is glTexImage2D (copy the image data from RAM to VRAM). That may make a considerable speed difference.
I could also cut out every other frame from my animations. They won't be as smooth, but some of them may not look so bad. When I said 16 frames above I was exaggerating... the animations are between 8 - 12 frames. But I tried skipping frames on a "run" animation and it didn't look so bad.
Since the animations don't really use 16 frames, I could also combine some animations' sheets with other animations' sheets to avoid leaving any empty spaces in the 256x256 images.