i wont go to far in this section as some of the links above are much better at explaining.
right the gba will surprise you in power terms when you get to grips with it and start writing smoth code
.The main cpu is an arm7 33mhz and the gpu has hardware tilemapping rotation and scalling hardware sprite
blitting and hardware alpha plus frame buffer modes.
MODE 0-2:
has diffrent background layers which are tilemapped and has access to the sprite oem memory.
MODE 3:
is a 16bit color frame buffer mode which is full screen but has no back buffer because of the extra video memory required
required . it also has access to the oem sprite memory.
MODE 4:
is the same as mode 3 but is 8bit color and as such has enough memory to use a backbuffer.
MODE 5:
is the same as mode 3 but uses a smaller area off screen so has a backbuffer.
SOME NOTES:
the gba has no fpu so when doing floating point effects use 32bit fixed point the speed difrence is quite staggering.
also the gba has a 32 bit cpu so please try to stick to 32 bit integers as 64 bit takes twice
as long to process.
the defenitions for variables are as follows.
u8 u16 u32 u64.
s8 s16 s32 s64.
where the u is simply unsigned int or + the size allocated.
where the s is simply signed int or -+ the size allocated.
the text modes or tilemap modes are a little strange to get the hang of but are powerfull.
there 8bit but allow diffrent layers to be applyed with diffrent priorites and alpha values.
and as such there great for say paralax scrolling with diffrents layers moving at diffrent speeds with text on top of it all.
the concept behind tile modes are that you assemble all your tiles up in vram then leave them lying static the minute you pop a tile into vram it becomes visable on screen theres no double buffering needed and when you want too move them you leave it too the hardware you simple do something like this BG0_X += 10; this is what the gba was made for these modes are excellent for games because the basically leave the cpu alone to get on with ai and stuff.
mode 4 on the gba is a bit strange as it writes two pixels for every one you want to write which can give very weird pixel maps so what you have to do is say you wanted to plot a pixel at 100,100 you would have to divide the x and y coords like so buffer[(100/2)*screen_x+(100/2)=col; but you can sometimes land on an odd pixel which still writes two pixels heres the best way around this
quote jim:
Ok, the issue is, you want to write 32bit words for speed, so that means taking 2 16bit pixels and writing them at once.
But the problem is if either of the beginning and end pixels are not 32bit aligned (they are only 16bit aligned) then you must not try to write a 32bit word at that address or it'll crash.
So the solution is to check for those start and end conditions being odd pixels. The easiest way to check if the start is an odd pixel is to check the destination address. You can cast the address to a 32bit integer and check the lowest 2 bits to see if they are 00 (by ANDing it with 3 - binary 11). If they are 0, then the address is a multiple of 4. If they are 10 it's a multiple of 2 and if they're 11 or 01 then something is very wrong (the address is only aligned to 1byte and writing a 16bit value there would crash).
So you might have something like
void write_line(unsigned short *dst16, unsigned short numpixels, unsigned short colour)
{
unsigned int address;
unsigned int *dst32;
unsigned int colour2;
address = (unsigned int)dst16;
//check if 1st pixel is aligned, if not, write 1 pixel
if (address & 3)
{
*dst16++ = colour;
numpixels--;
}
//create a 32bit address
dst32 = (unsigned int *)dst16;
colour2 = (colour << 16) | colour;
//write 2 pixels at a time until there is only 0 or 1 left
while (numpixels>1)
{
*dst32++ = colour2;
numpixels -= 2;
}
//if there's still 1 pixel left, write it
if (numpixels)
{
dst16 = (unsigned short *)dst32;
*dst16 = colour;
}
}
Something like that.
one last thing the gba has dma controllers which can be fired up and addressed to move large chunks of data without troubling the cpu which is very fast use it with caution though as dmaing one pixel at a time is slower than normal pixel pushing as the dma controller has to be fired up and wait till its idle before moving on to the next pixel.
it has four controllers 0,1,2,3. 0 is the fastest but cannot access the 0x800000 game rom space so basically its good for oporations inside the machines 256k of ram, 1,2 are for the sound fifo`s and 3 can access anything but is the slowest.
