gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Overall sprite size limit

#20287 - CyberSlag5k - Thu May 06, 2004 4:27 pm

I am about to start porting my game brick assault to the gba. In preparing this I have come across a problem. The game is like a multiplayer version of breakout. There are two paddles at opposite sides of the screen that must protect the bricks behind them from a bouncing ball.

To give you an idea, here's the game itself:
http://homepages.udayton.edu/~pateramj/BrickAssault.html

Now the size and number of bricks is flexible, I don't mind adjusting them, however I am not really seeing a way of placing a reasonable number of bricks on the screen without exceeding sprite memory.

The amount of sprites you can have is dependent on the size of the sprites, correct? So lets say I have 3 rows of bricks per side. In order to fit well into the 240x160 viewing screen, I could do 30 8x8 pixel blocks. However, that comes out to 600 pixels...too many for the OAM to keep track of. So lets increase the size of the blocks to 30x8 pixels. Now I only need 8 blocks across, but the sprites are considerably bigger and won't (I think) fit into sprite memory). So it's a trade off between sprite number (overloading the OAM) or sprite size (overloading sprite memory). Either way I can't seem to get it to fit.

Now I could just make the blocks a background layer and change the data each time one is hit or I could place the blocks upon the sides of the board instead of the top and bottom, but I'd like to work out a solution here if possible (it'll look better and I'd still like to know how to do it for future situations).

Is it possible for me to do some sort of tiling effect with the sprites? All the blocks will look the same, so can I just have like half a block loaded into sprite memory and then each block will be twice the size of this, just draw two of the block tiles for every one block? This saves on the OAM and (if it's even concievably possible) saves space in sprite memory. Or am I just getting a little crazy here?
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...

#20289 - CyberSlag5k - Thu May 06, 2004 5:07 pm

The tile thing wouldn't work, would it? The OAM reserves space in sprite memory based on the sprite's size, doesn'it it...
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...

#20290 - niltsair - Thu May 06, 2004 5:08 pm

There's 2 things with Sprite.

Sprite Object : Keep track of a sprite entry ( Size, Position, Palette, Tiles used, ...)
Sprite Tiles : Tiles of the sprites.

You can use 30 Sprite entries. Each of them will either point to the Tiles for a Filled block or an empty block. That's it.
_________________
-Inside every large program is a small program struggling to get out. (Hoare's Law of Large Programs)
-The man who can smile when things go wrong has thought of someone he can blame it on. (Nixon's Theorem)

#20291 - CyberSlag5k - Thu May 06, 2004 5:23 pm

Quote:
You can use 30 Sprite entries


Well, I'll be wanting 30*3*2 (180) blocks so that's too big, but I can play with that.

Quote:
Each of them will either point to the Tiles for a Filled block or an empty block. That's it.


So, if I'm following, as each block uses the same tile, I can have up to 128 regardless of their size?
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...

#20292 - CyberSlag5k - Thu May 06, 2004 5:25 pm

Ahh, looking back at a previous question I asked, sajiimori said:

Quote:
Sprite cell RAM only has space for 16 16-color 64x64 images, or 8 256-color 64x64 images.


The key word there being images. So the size of the sprites don't matter, only the size/number of their images.

Awsome. Thanks niltsair.
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...

#20293 - niltsair - Thu May 06, 2004 5:39 pm

You can make every sprite use the same tiles. The only difference with BG is that they allow you to have a map, while with sprites, you can only point to the first tiles, then I'll pick the tiles following it to form the sprite you see displayed.
_________________
-Inside every large program is a small program struggling to get out. (Hoare's Law of Large Programs)
-The man who can smile when things go wrong has thought of someone he can blame it on. (Nixon's Theorem)

#20294 - Miked0801 - Thu May 06, 2004 6:40 pm

Ok, here's how I would do it.

Use mode 0.

Create a single brick tile of the size you want and place its graphic in VRAM. Paint that graphics on the screen over and over for every brick you want to display.

The paddles and ball are pre-loaded sprites as they don't animate. Place their graphics in sprite ram and create a sprite for them.

As the bricks lay out on a nice grid, the math for brick collisions is trivial - just make sure each brick is a power of 2 in X/Y size (like 16 x 8). To see if the ball has collided with a brick, take the balls X/Y position and divide (shift) by the power of 2 size (for my example, shift right 4 on X and 3 on Y). Use these 2 values to point into a 2Dim array that represents the tiles current state. If the ball is in an occupied tile, collide - that is mark that entry as empty, play a SFX, and reflect the ball depending on how the ball hits the tile (another trivial task.)

If the ball hits the paddle (box collide), reflect it using the same code that handles the tiles.

If ball hits Y pos 0 or Y pos 160, game over.

With a basic actor/sprite engine in place, this game could be coded in a day or two for single player. Multiplayer will take a lot longer :)

#20295 - Akolade - Thu May 06, 2004 6:41 pm

you can have 128 sprites onscreen at once. there is lots of memory for the sprite tiles (32k).
there are 128 OAM entries though, so that is your limit (unless you got crazy and did stuff during horizontal blank).

but I would just use a BG layer and change the BG map each time a block disappeared. it seems like it would be the easiest way.
just make your ball and paddles sprites.

#20298 - CyberSlag5k - Thu May 06, 2004 7:05 pm

Heh, thanks miked, but I've already written the game in java. Now I'm just porting it to the gba to make sure I've got all the pieces straight.

I think I see what needs to be done with the sprite tiles now, thanks guys.
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...

#20382 - dXtr - Sun May 09, 2004 9:21 pm

I was just on my way to write a similar question here so I guess I could write it here :)
What I wan't to know is could I use 128 sprites with the size of 64x64 (or whatever is the largest posible sprite size) with out overwritting some other memory. Cuz if I could that would help me alot in a project I'm doing :)

#20383 - poslundc - Sun May 09, 2004 9:32 pm

You can have up to 128 sprites on the screen, but the tiles for those sprites must exist within sprite VRAM, which you only have 32K of.

A unique 64x64 sprite takes 2K of VRAM (16-colour mode; 4K if 256-colour). So you can only fit 16 unique 64x64 sprites into memory (8 if 256-colour).

Now if those sprites are at all repetetive you can reuse the tiles in multiple OAM entries, but failing that you're pretty much stuck.

That said, you can easily change what's in sprite VRAM from one frame to the next, so you could have 16 64x64 sprites showing in one screen, room, level, etc. of the game, a different 16 in another, etc.

Dan.

#20384 - dXtr - Sun May 09, 2004 9:47 pm

I was afraid I would get that answear cuz I calculated some on that and I got it to not be possible to... but I hopped I had understand it all wrong :)