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.

Beginners > Another Beginner Needs Help (GBA)

#176951 - Ledgend. - Sun Nov 06, 2011 2:43 pm

Hello all, this is Bothi. I am looking to make a Side Scrolling Hack-n-Slash game for the Gameboy Advance, sort of like a smaller MapleStory. I am not new to game creation as a whole, but I am to the GBA scene. I currently only have the GBA Dev Kit, and was wonder what else I should get. Any help is greatly appreciated.
_________________
I came, I saw, I won. I died. Now I'm Back.

#176954 - Dwedit - Sun Nov 06, 2011 7:51 pm

Welcome!

There's a nice document out there called "Tonc", which discusses many aspects of the GBA hardware. It has good information, and lots of pictures.

Some pointers:

The bitmap modes on the GBA are mostly worthless, since drawing to them is very slow. They are only used for tutorial programs.
You'll be using the tilemap modes mainly. There's also "mode 7" affine transformation tilemap modes if you want to use them, you can still get two normal layers along with the transformable layer.

Think of a GBA Tilemap as a small window to your main map. You need to write columns of tiles onto the map as it scrolls horizontally, and rows of tiles onto the map as it scrolls vertically.

Do not force yourself into a 1:1 relation between your game objects and GBA sprites. You can build a game object out of many sprites if you want to. You can even have pieces of them rotate and scale.

Sprites are not very limited on the GBA. You can put a lot of big sprites on the screen without problems. In ideal circumstances, you can have up to 1210 pixels worth of sprites per scanline, but 1000 pixels is a much safer and more realistic number, and is still enough to cover the screen 4 times over. Normal sprites eat up pixel time equal to their width. Scaled/rotated sprites eat up twice their width plus 10. Accessing video memory during render-time also slightly reduces the available pixel time for sprites, so that's why I'm suggesting 1000 pixels rather than 1210.

Number of total sprites still needs to be up to 128. But they can be big sprites too.

GBA has different kinds of memory with different speeds. The cartridge slot is the slowest, and internal RAM is the fastest. Code executing from internal ram is 3 or 6 times faster than code executing from the cartridge.

Some types of RAM on the GBA should only be written in units of 16-bits or higher. For example, video RAM, OAM (sprite table) RAM, and Palette Ram. If you write a single byte there, it will set both halves of the 16-bit value to the same byte, leading to screwy graphics. Reading single bytes is fine though. 32-bit reads and writes are also fine.
Also, the ARM processor requires things to be aligned in memory. 32-bit ints must be at 32-bit boundaries, unlike the x86. But you need to go out of your way to get unaligned variables, only using a "packed" struct, or changing a pointer type will do it.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

#176955 - Ledgend. - Sun Nov 06, 2011 10:11 pm

Thanks.
_________________
I came, I saw, I won. I died. Now I'm Back.