#13059 - doudou - Thu Dec 04, 2003 6:57 pm
Hi,
I'm working on a "Diablo" like game. I'm using 32x32 sprites frame for my hero and since i'm having a lot of frame, i think i overloaded the sprite memory.
I read that the size of the sprite memory is 512 sprites (8x8)...since i'm using 32x32 sprites which means 16 8x8 squares, 512 8x8 squares is very too small for me.
I thought about "software sprites" but i was hoping there would be a better way.
#13061 - NoMis - Thu Dec 04, 2003 7:02 pm
it depends on the color mode. in 16-Color you can put 1024 8x8 sprites on the screen. 256 colorsprites takes twice the memory so you only have 512 8x8 pixel slots.
i suggest that you load the the frames of your character dynamicaly after every frame so you only need one 32x32 sprite every frame for you character.
NoMis
#13072 - Miked0801 - Thu Dec 04, 2003 8:15 pm
For a good example of a Diablo-like game, go check out Lord of the Rings: The Two Towers or Return of the King (just released).
They use a huge amount of sprites (Disp Mode 0) and dynamically load them on the fly as they come on screen. Good games.
Of course I am biased as I worked on them... ;)
#13445 - doudou - Sat Dec 13, 2003 4:47 pm
Thanx for the help. I still want to know what is the advantage of using hardware sprite loaded dynamicaly instead of "software" sprites ?
#13446 - poslundc - Sat Dec 13, 2003 5:12 pm
Well, they're a heck of a lot faster, for one.
The GBA gives you hardware-driven sprites for a reason. Sure, you could manually mask, clip and draw your sprites in Modes 3-5 if you wanted to (or even Modes 0-2, although it is much trickier to do so), but why would you want to? The only reason I can think of is if you are doing a special-case system in Modes 3-5, such as a 3D engine, or for things which sprites might be a questionable use for in the first place, such as particle effects.
Alternatively, you can just use the GBA's built-in sprite hardware and swap the sprites you need in and out of VRAM as you see fit. DMA makes this extremely simple to do, and also faster than any sprite renderer you could code by hand.
Dan.
#13462 - doudou - Sat Dec 13, 2003 10:18 pm
poslundc : i was not comparing directly hardware sprites to software sprites... i know hardware is much faster, but if you have to reload the sprite in the sprite OAM each frame change like NoMis said, i don't see the gain. It's just loading a 32x32 sprite in sprite memory instead of loading it in video memory (software sprite).
#13463 - Miked0801 - Sat Dec 13, 2003 10:26 pm
You only have to reload OAM memory when sprites change - though in truth, it's easier to load them every tic as they change so often.
Where you get the big advantage is what you need to load every tic. If you move a hardware sprite to somewhere on the screen, you only need to reload its (and only its) 2 byte OAM structure. A software sprite would require an entire screen repaint (or dirty box style cleaning of old sprite followed by copying of new.)
If that sprite needs to display new VRAM and it isn't preloaded, then you also have to load the graphics and it then becomes a slower process - though still much faster than software as BG updating is handled by hardware with sprites. You also get X/Y flipping and transparency effects which are nice :)
Mike
#13478 - doudou - Sun Dec 14, 2003 8:45 pm
Thanks Mike, i think you said all i had to know to make my choice.