This is a good start, but I really hope this guy figures out the hardware sprite system soon or he's going to be in for a world of performance hurt. There's really not very often a reason to draw directly to the framebuffer.
I ran into that same problem with a few games I wrote for the PSP[1,2] in high school. I did all the rendering by drawing color values directly to the framebuffer. Quickly all of your CPU time per frame is taken up by drawing pixels and you have no time for game logic. This doomed my projects to small scale, and I didn't have the interest in learning actual PSP hardware programming and rewriting the rendering to use it.
I know about the sprite system in abstract, but I haven't tinkered with it yet (nor do I know enough to start tinkering with it yet). I'm still trying to decide whether I want to go down that route or build a ray casting engine / do some 3D stuff, since most of my other work is 3D related.
Regardless, this post was meant more to cater to the "I know nothing and want to feel like I'm making progress in 15 minutes" crowd.
You'll run into performance limitations very quickly doing 3D on the GBA; the few true 3D games on the GBA had to make some huge sacrifices to run at all (the hardware just isn't fast enough).
Mario Kart-style faux 3D's much more doable on the platform; those games use sprites (for characters and objects that aren't flush with the ground) combined with a tilemapped background that's scaled and rotated per-scanline to look 3D.
Alternatively, if you're more interested in 3D, you might switch over to the Nintendo DS-- it's essentially the same hardware and programming model as the GBA, but with hardware accelerated 3D.
It's not so bad - you can do plenty of 3D on a GBA if you try. It just costs a lot of effort.
I'm one of the coders of a number of 3D GBA demos [0] (and there's much better works on Pouet.net still). My teammate Jacob coded the 3D renderer and a lot of sweat went into it, but the result is pretty decent IMO.
Unlike some other GBA demos out there, this one doesn't contain any precalculation to speak of, which means that all of this could've be interactive as well and run at similar framerates. That said, most scenes are pretty damn lowpoly so the game design space is limited. But hey, limits are fun!
Haha I wish. No it's an ADPCM encoded wave file. The demo is like 16MB and at least 10 of that is the audio :D ADPCM is nice because it's small-ish yet very cheap to decode. The sample frequency of the file is an exact multiple of the GBA's frames per second, which meant that the entire "decode the next chunk of audio" routine could happen on the frame interrupt. This avoided audible clicks or bad synchronization, and left nearly all CPU time for the visuals. Not our idea btw, we stole the player from Janne / Matt Current.
The track was purpose-composed for this demo though, and we did have quite some fun times synchronizing the visuals to the track. We used a tool called GNU Rocket[0] to change parameters over time (eg camera position, angles, anything we'd want to animate) but it's a desktop program. So we patched Visual Boy Advance to write all parameters to some piece of uninitialized RAM on every frame, and then inside the demo we just dereferenced a hardcoded pointer to that place. No access violations in GBA land so this worked :-)
Then, when we compiled the demo for release, we simply recorded a stream of parameters, again 60x per second, as a binary blob. No compression no structure no nothing. Just on the nth frame we'd look up camerapositions[n] and that was it :)
If you figure that out, I would love a followup post talking about it. I was always really impressed with that Asterix and Obelix 3D platformer for the system, and I'd really like to see how they pulled that off.
It shouldn't take more than an afternoon or two to have a functional program using the sprite system. I'd suggest it just so you have an understanding of how it works.
On a side note: from what little I've read, it seems like on some older systems like the NES/SNES, there isn't ever any direct manipulation of a framebuffer by the CPU — everything that appears on the screen is the result of the graphics chip drawing either a background or a sprite. Anybody know if that's correct?
I've done a bunch of NES development. You are correct that the framebuffer is not modified directly.
For the background, there are two layers -- the 2 pattern tables are 256 8x8 tile images each using 2 bpp color.
The name tables are what is actually displayed. Each tile in the background is an index into one of the pattern tables. (Determined by a global selection bit).
However, in some cartridges, the pattern tables are mapped to RAM. This lets the game simulate drawing into the framebuffer directly. Some games use this for drawing variable width fonts, for example. Battletoads does some cool parallax effects. It turns out that the pattern tables have just enough bits to fill the whole screen with a monochrome image, so you could treat it as a framebuffer (it requires timing changes to midframe, though). I created a demo for that http://forums.nesdev.com/viewtopic.php?f=22&t=14884
I wrote an NES emulator. There's a background color, a scrollable background tile-map[0], and 64 hardware sprites, which can each be drawn either on top of or below the background.
The hardware itself doesn't even contain a framebuffer; calculating palette effects and compositing the background and sprite layers into a final image is done by the hardware in realtime, 1 pixel at a time, and fed to the video output pin.
However, many game cartridges actually had RAM to store their graphic tiles in, rather than a set group of tiles in ROM. Graphics would be stored within the program code and transferred byte-by-byte into the PPU's (Picture Processing Unit, aka the GPU's) memory space. Legend of Zelda worked this way, along with a lot of other well-known games. Look at Elite for an example of the NES emulating a framebuffer using that method to render 3D polygons: https://www.youtube.com/watch?v=zoBIOi00sEI
[0] The background has 4 screens worth of area in a 2x2 screen grid, and increments addresses during rendering to simulate a toroidal memory space, allowing for smooth scrolling. This is a (perhaps overly) simplified explanation; things are slightly more complicated.
The S/NES allowed for some software drawing tricks (for which this article is a decent starting point http://www.racketboy.com/retro/super-nintendo-snes-games-tha...). But you're right, typically the CPU and whatever rendered stuff onto the screen worked cooperatively to render things.
On the NES, the PPU would render a bunch of scanlines, and then during the vertical blanking interval, would trigger an interrupt on the CPU telling it to make whatever changes it needs to the graphical memory through a particular port. However, the CPU is still running while the PPU is rendering things, so it's possible to modify the graphics memory during rendering to pull some interesting tricks.
On the SNES, you could do the same (but now faster, with more memory, with Mode 7, with variable size sprites iirc) but on top of that, you could use external coprocessors as part of the cartridge to extend the existing hardware, like the Super FX or Cx4 to name a couple. With these, you could draw actual realtime 3D graphics to the screen.
So in a sense, on the SNES, you could provide a chip that would have direct access to the renderer. It was just never directly controlled from code on the main processor.
No, the GBA has some (a?) mode where a memory mapped frame buffer is mapped rather directly to the screen, while also offering tile/sprite based modes.
I ran into that same problem with a few games I wrote for the PSP[1,2] in high school. I did all the rendering by drawing color values directly to the framebuffer. Quickly all of your CPU time per frame is taken up by drawing pixels and you have no time for game logic. This doomed my projects to small scale, and I didn't have the interest in learning actual PSP hardware programming and rewriting the rendering to use it.
[1] http://brightnightgames.com/games.php?game=dyox [2] http://brightnightgames.com/games.php?game=abahd