thats probibly architecture, not graphics engine. even in modern games and hardware still use 16 bit textures. did you honestly think that dxt* textures were 24/32 bit? its 32 bit cause its running a 32-bit arm processor. reguardless of the cpu with a machine with limited resources, 16 mhz arm7, 128k vram and 256k wram. not a whole lot to work with, so youre not going to waste it on 24 bit gfx. on top of that i very much doubt the screen is 24 bit either, 12 or 16 bit is more probable. at 16 bit and a screen resolution of 240*160, you are using up 115200 bytes of ram which fits nicely into the vram, but doesnt allow space for a dual buffer. this is still workable however.
that said:
The technical specifications of the original Game Boy Advance are, as provided by Nintendo:[5]
Length: approximately 14.45 cm (5.69 in)
Width: approximately 2.45 cm (0.96 in)
Height: approximately 8.2 cm (3.2 in)
Mass: approximately 140 g (4.9 oz)
Screen: 2.9 inches reflective thin-film transistor (TFT) color LCD
Power: 2 AA batteries
Battery life: approximately 15 hours on average while playing Game Boy Advance games (also dependent on the Game Pak being played and the volume setting)[6]
CPU: 16.8 MHz 32-bit ARM7TDMI with embedded memory
Memory: 32 kilobyte + 96 kilobyte VRAM (internal to the CPU), 256 kilobyte WRAM (outside the CPU).
Resolution: 240 × 160 pixels (3:2 aspect ratio)
Color support: 15-bit RGB (16-bit color space using 5 bits depth per channel), capable of displaying 512 simultaneous colors in "character mode" and 32,768 (215) simultaneous colors in "bitmap mode"
Sound: Dual 8-bit DAC for stereo sound (called Direct Sound), plus all legacy channels from Gameboy. The new DACs can be used to play back streams of wave data, or can be used to output multiple wave samples processed/mixed in software by the CPU.
this would indicate 15 bit color, where one bit is probibly reserved for sprite alpha. "character mode" is actually a way to compress backgrounds (very similar to how dxt* works), using tiny cells called characters where each one has a small pallet (usually 4 or 8 colors), which in turn are just references to entries in what seems like a 9 bit color table. so that the individual pixels only take up a couple of bits. this was the norm of how things worked in the 8 and 16 bit eras. bitmap mode is sprites, and so you need a transparency bit, so that bitmaps can be blitted correctly. when you deal with these tight architectures it comes down to the bits.
so even if the game system says 32 bits on it, it probibly just has a 32 bit cpu or gpu. do we forget the lessons learned durring the bit wars so easily? bits dont matter. case in point you can take an arduino and a
gameduino and have amazing graphics while still staying in the 8 bit realm (seriously watch the graphics demos there, they are pretty awesome for 8 bit). its not the number of bits, its what you do with them that matters (and also the speed of your cpu clock and number of processors/cores/gpus you have).
