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.
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.