5 ms·

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 rea

by coldpie 10y ago

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. [1] http://brightnightgames.com/games.php?game=dyox http://brightnightgames.com/games.php?game=dyox [2] http://brightnightgames.com/games.php?game=abahd http://brightnightgames.com/games.php?game=abahd

khalladay 10y ago
Hey, author of blog post here :) 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.
- JonathonW 10y ago
  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.
  - coldpie 10y ago
    Or you can go crazy and do something totally off-the-wall like the unreleased Banjo Pilot voxel racing game :) https://www.youtube.com/watch?v=3zVy-4CEFQU https://www.youtube.com/watch?v=3zVy-4CEFQU https://tcrf.net/Proto:Banjo-Pilot/Voxel_Engine_Build https://tcrf.net/Proto:Banjo-Pilot/Voxel_Engine_Build
  - skrebbel 10y ago
    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! [0] capture of our best GBA work "Unibrau" https://www.youtube.com/watch?v=v2FjuF7l1Mk https://www.youtube.com/watch?v=v2FjuF7l1Mk
    - sasas 10y ago
      Amazing work! Was the audio synthesis also done in the GBA in the above demo?
      - skrebbel 10y ago
        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 :) (we were on a bit of a deadline) [0] https://github.com/rocket/rocket https://github.com/rocket/rocket
- tombert 10y ago
  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.
- coldpie 10y ago
  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.
glhaynes 10y ago
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?
- boomlinde 10y ago
  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.
- russellsprouts 10y ago
  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 http://forums.nesdev.com/viewtopic.php?f=22&t=14884
- striking 10y ago
  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-that-pushed-the-limits-graphics-soun 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.

by coldpie 10y ago

khalladay 10y ago

Hey, author of blog post here :) 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.

JonathonW 10y ago
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.
- coldpie 10y ago
  Or you can go crazy and do something totally off-the-wall like the unreleased Banjo Pilot voxel racing game :) https://www.youtube.com/watch?v=3zVy-4CEFQU https://www.youtube.com/watch?v=3zVy-4CEFQU https://tcrf.net/Proto:Banjo-Pilot/Voxel_Engine_Build https://tcrf.net/Proto:Banjo-Pilot/Voxel_Engine_Build
- skrebbel 10y ago
  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! [0] capture of our best GBA work "Unibrau" https://www.youtube.com/watch?v=v2FjuF7l1Mk https://www.youtube.com/watch?v=v2FjuF7l1Mk
  - sasas 10y ago
    Amazing work! Was the audio synthesis also done in the GBA in the above demo?
    - skrebbel 10y ago
      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 :) (we were on a bit of a deadline) [0] https://github.com/rocket/rocket https://github.com/rocket/rocket
tombert 10y ago
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.
coldpie 10y ago
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.

glhaynes 10y ago

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?

boomlinde 10y ago
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.
russellsprouts 10y ago
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 http://forums.nesdev.com/viewtopic.php?f=22&t=14884
striking 10y ago
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-that-pushed-the-limits-graphics-soun 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.