GBA Development From the Ground Up

Volume 1

by Brian Sowers

 

What is this?

 

This tutorial is, hopefully, going to teach people how to independently develop games for the Gameboy Advance with relative ease.  The system is actually a pretty nice system to develop for, and acquiring the necessary tools won't cost you a billion dollars as opposed to most console systems.

 

Who is this tutorial intended for?

 

Unfortunately, I lack the experience and skill to teach you C from the ground up, and therefore you will have to know the language beforehand.  You shouldn't need much more knowledge, and you don't even need a GBA (I didn't have a GBA for my first few weeks of development).

 

How am I going to teach you?

 

Through a series of articles, I'm going to try to give you the necessary information you need to develop a decent GBA program, and hopefully a game.  Each article will cover anywhere from one to one billion topics associated with GBA programming, and sometimes I might toss in general coding techniques to help you out.  I'll give you examples, information, and other miscellaneous stuff you need to know.  Occassionally, I might even code you a demo to help (wouldn't that be neat?).

 

What will this article cover?

 

In this first article, I'm simply going to give you an overview of the GBA system and its capabilities.  Unfortunately, we won't be coding yet - be patient, I'll get around to it (with luck).

 

I've had enough of giving you an overview of the purpose of this article.  Let's begin.

 

An overview of the system

 

Let's begin with a simple overview of how the wonderful system works.

The GBA is a 32bit system that uses the ARM7TDMI processor and runs on the RISC architecture.  The system runs at 16.78mhz and has some powerful 2d acceleration that will save you the trouble of painstakingly making all your own graphics routines super-powerful (for those of you who have coded DOS, you know what I'm talking about).  The system wasn't especially made for anything 3d, but that hasn't stopped people from making 3d demos and raycaster engines (see Doom or Wolfenstein).

The GBA has 96kb of video memory, 32kb of fast internal RAM, and 256kb of external RAM.

The screen is 240*160 pixels, and it supports either 8bit or 16bit color.  With the powerful acceleration, alpha blending, rotation, scaling, and creating a mosaic effect are all relatively easy.

 

Screen Modes

 

The GBA operates in one of 6 different screen modes that are very different from each other.  Naturally, many suit many different needs.

 

The first 3 modes are tile modes.  Basically, this means that the game world is represented by blocks pieced together to make a larger image.  For an example, see the earlier Nintendo RPGs (although, in actuality, practically all of the Nintendo games were made in this fashion).

How the GBA does this is by storing a series of numbers in the GBA's video memory.  These numbers represent a specific 8 * 8 pixel tile that is to be placed on that position on the map.  The map is generally larger than the screen, and can be scrolled in every direction to reveal different portions of the screen.

Maps can either be stored as generic text info, or they can have rotation/scaling data.  They can also have anywhere from 1 to 4 layers depending on which mode you are in.  A layer implies that one map is drawn above another, like a foreground / background type deal.

Maps can also be of varying sizes, depending on whether they support rotation/scaling or not.

Furthermore, every layer of a map can be alpha blended, zoomed, or have a mosiac applied to it.

I'm going to go into MUCH more detail when we get to the article on tile maps, so try not to feel too in-the-dark.

 

The next 3 modes are standard bitmap modes.  In these modes, each pixel in the screen is represented by one number containing the red, green, and blue values of the pixel or an index into a palette.  These are really the simplest modes to deal with, but they are somewhat lacking in speed, as you must manually draw the entire screen yourself.

 

Here's a more specific description of every screen mode:

 

Mode 0

 

Mode 0 supports all 4 map layers, but it does not support rotation and scaling.

 

Mode 1

 

Mode 1 supports layers 0,1, and 2, and layer 2 can rotate/scale.

 

Mode 2

 

Mode 2 supports layers 2 and 3, and both can rotate/scale.

 

Mode 3

 

Mode 3 is simply a linear buffer of 16bit numbers, each representing a color.  It takes up so much memory, however, that it does not support hardware double buffering (although you could potentially do this yourself with a large array).  Double buffering, for those who do not know, is when you draw the game screen offscreen and then blast it to the actual viewing screen.  If you do not double buffer, there is the possibility that the player will see the game being slowly drawn.  This is a common problem in Mode 3 - it is hard to draw the screen fast enough so that the user can not notice the image being drawn.

 

Mode 4

 

Mode 4 is also a linear buffer, but it is paletized, meaning you create 256 colors at the beginning and each number in the buffer indexes into this series of colors.  This means that it only takes 8bits to represent a number in Mode 4, and thus you can do double buffering.  Unfortunately, you can only write to the GBA 16 bits at a time.  This means that writing to Mode 4 requires the masking of the two colors adjacent to each other, and because of this hinderance Mode 4 is slower than it should be.

 

Mode 5

 

Mode 5 is double buffered and supports 16bit color.  The trade-off is that the screen size is limited to 160*128.

 

Sprites

 

The GBA supports hardware rendered sprites that have their own palette.  Sprites can either share one 256 color palette or use 16 color palettes.  This palette is completely seperate from the screen palette, meaning that you can have up to 512 colors on the screen at one time.  Pretty, ain't it?

Sprites can be of varying size, ranging from 8*8 to 64*64.  There is enough room to define 128 seperate hardware rendered sprites at one time - think about it and you'll realize you'll never need that many on screen at one time.  In tile modes, you have 32kb of memory to store the sprite image data, and in the other modes you have 16kb.

 

Sound

 

Unfortunately, I know little about sound, but hopefully this will change by the end of these articles.  From what I am to understand, there are 4 standard music channels, and 2 other channels that can be used for mixing sound effects. Any more information on this would be greatly appreciated.

 

What we will need

 

I'm going to be introducing most of the tools we will need as we go along, but there are a few things you should have to start out (or are at least nifty).

 

Tools

 

You are going to want a bitmap editor (ie: Paint Shop Pro or Photoshop) and a text editor (Notepad).  Although the GBA will not directly read bitmaps in the standard Windows format, later I will introduce conversion tools.  The Notepad is for writing your code.  Actually, I use MSVC++ to write my code and then I just use the 3rd party compiler for compilation, but this is your choice.

 

Compiler

 

I strongly advise you get DevKitAdvance for compilation, as it is the easiest to use.  You can find it at www.io.com/~fenix/devkitadv.

 

Hardware

 

Obviously, you want a GBA.  You can live without this, but it's just not as fun not seeing your work on hardware.

If you want to see your program on hardware, you're also going to want a flash cart and a linker.  You can buy them both at www.lik-sang.com by purchasing the "Flash Advance 64M ready to go Set."

 

Next Article

 

Next article, I'm going to go into getting you familiar with the frikkin' compilation that plagued me for so long.  I'm also going to delve into the bitmap screen modes (3,4,5) as they are the easiest to start with.

 

Acknowledgements

 

I would like to thank dovoto, as his tutorials have been my biggest source of information on GBA development since I started.  Check out his site at www.thepernproject.com.  I'd also like to thank the guys in #gamedev and #gbadev on EFNet in IRC for all their help, and all the help they'll be giving me as I write these articles.

 

If you have any questions or comments, you can always e-mail me at genesisgenocide@yahoo.com or nairb@usa.com.