Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
64 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

Contents
 Introduction
 An overview of
 the system

 What we will need

 Printable version
 Discuss this article

The Series
 Volume I
 Volume II
 Volume III

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.



Next : What we will need