As an ex Gamebody (pre Advanced) developer that got a great job doing professional development after playing around with developing on an open source emulator, I have to say that I got into doing it because it was just great fun.
These machines are small enough to fit in your head when you're developing, and you really learn to get 'down to the metal' when your builtin libraries are memory addresses and ranges. The development is fast and fun.
I totally recommend checking it out and making a couple of games on something like the Gameboy or Gameboy advance. An excellent learning experience.
I was tinkering with Gameboy Dev using a C library(even bought one of those flashable cartridges), but found the resources/documentation to be kind of all over the place. Do you know of any better resources for learning Gameboy dev?
The Pan Docs, at http://problemkaputt.de/pandocs.htm , have pretty much all the bare metal information you could want. After you define macros for everything, it shouldn't be much lower level than most libraries.
I actually have a bit of half-finished GB code that does sprites and backgrounds, without using libraries. If anyone cares for it, I can put it up on Github later.
In the interest of actually getting this out tonight, I have a full 7z archive of my development environment up at https://juliangoldsmith.com/rgbds.7z .
I'll most likely clean up the sources and put them up on Github later.
Unfortunately I am not aware of the modern documentation resources and a quick search shows they're just as scattered as when I was looking them up, possibly more now.
The hard part back then was finding examples generally, but that's also the fun part in that you read all the specs for the machine you can find and let your imagination run wild. Assembly is kind of like that and the machines are small enough that, with enough background knowledge, they can be made to do some pretty interesting things.
Like learning anything, just read the every doc you can find and write code is the best advice to get started :)
A good place to start would be poking around github for "CS 2110 gatech gameboy". CS2110 is the intro-to-low-level course at Georgia Tech, and about the middle third of the course could be described as "getting comfortable with C syntax in the completely foreign environment of a gameboy advance by writing games". As a result, there are some provided libraries that are very extensive. For everything else, there's tonc.
Most of the time the course doesn't cover the more advanced features (mode 0? or was it 4, or 6 that did sprites and textures) but it was a fun introduction to something, and I got to write flappy bird in C when flappy bird was still culturally relevant.
Doing z80 assembler for gameboy color was the most fun I ever had programming. I learned an incredible amount. I think that's why I never had imposter syndrome so many complain of. After that, there's not a lot of mystery; its bits all the way down!
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.
It is worth noting that to do anything serious on the GBA you need to use the tile+sprite modes for graphics. That is really the way to get decent performance.
The way it done in the article is still a good way to start out but you would probably transistion quickly to some other video mode.
Having a flashcart and running your homemade program on a real GBA is a really nice experience. I totally recommend it.
I really wish there was a modern, standardized handheld with an open-source OS and SDK for learning, tinkering, home-brew apps and indie games. The Switch form-factor with detachable controllers, but focusing on 2D graphics, would be perfect.
The harsh limitations of pico-8 are carefully chosen to be fun to work with,
encourage small but expressive designs give pico-8 cartridges their own
particular look and feel.
It's entirely open-software and open-hardware, and it's focused on 2D indie gaming. It even has breakout pins.
It's a cool little device, and I love Pico8, but I find the keyboard they chose doesn't make for a great controller. If they make a version two I hope they find a way to integrate something better.
Its very much a more usable device with keys now .. I honestly think that NextThing should get behind this community effort and just start making PocketCHIP's with cases based on these designs. Its a very different instrument ...
This brings back memories, my GP2X-F200 died after an adapter mishap but I remember the SNES emulation was pretty great!
For years I followed the Open Pandora without knowing what Pandora (music) was. I remember being a little annoyed I couldn't just search "Pandora" without getting a bunch of results for "some music thing". I still don't really get what happened with the Pandora, the release history was long and complicated iirc
The Pandora was indeed an incredible device, soaked in drama and intrigue. (Disclaimer: I have two.)
The manufacturing delays, the issues with the case .. the volcano! (Seriously, the project was delayed by the Iceland volcano in 2010 ..) The issues with the original team splitting up, and so on .. well, it still bloody shipped! And its an excellent device!
And the best part is that all those lessons were learned, and applied, to the new Pyra - which is the spiritual successor to the Pandora in many ways. I was lucky enough to have a Pyra prototype to play with a few months back, and its going to be a very special device for a lot of folks - open, accessible, hackable. A truly delightful Linux workstation! :)
How much was the Pandora when you got it new? I'm seeing the Pyra start from ~$600 USD to $750USD including tax. I think the form factor is really cool but I could buy a much more powerful laptop or even a Surface Pro 4 for nearly the same price. I fully understand how pricy custom hardware can get but that price is just totally unattractive compared to the competition.
GPD Win Game Console is the World's First 5.5 Inch Handheld PC / Gaming Console Based on Windows 10 System. Equipped with a 5.5 inch capacitive touch display that supports 1280 x 720 pixels. Powered by Intel Atom X7 Z8700 64 bits Quad Core 1.6GHz(up to 2.4GHz) processor, and 16 units Intel HD Graphics. Besides, it has larger storage (4GB RAM and 64GB ROM) for your using, all features provide you wonderful gaming and using experience.
Well, others have been mentioning similar projects so let me plug in my own : Bitbox, Open hardware/software DIY 32bit console (you can buy it pre-made), 1MFlash/192k RAM/VGA/USB host/microSD , bare metal (no OS), 2d programming (some say racing the beam).
Existing games, libraries, using gcc.
I doubt it satisfies your definition of "modern", but the GCW Zero[0] from some year ago was a Linux-based handheld with a MIPS CPU. You could make games in C + SDL or Python + PyGame. Too bad they seem to have stopped development, but I still have mine and mainly use it to emulate 8- and 16-bit era consoles.
WiiU devkit was very easy to get as well, all you had to do was to have a registered company(5 minutes of work in the UK) and a safe place to store the devkit(basically an approved lock on the door).
Really? You expect someone to invest thousands of hours of personal development time to give YOU a free platform to tinker on? And in 90's form factor of 2D?
Open source has its place, but you're asking for someone to selflessly give their entire life so you can "play" in a sandbox - and in 2D instead of 3D, as if that's viable anymore. Give me a break. If it's so easy, do it yourself.
Hey bud, I dunno who pissed in your cornflakes, but there are plenty of these kinds of projects out there already .. and they're not all so dire as you proclaim. This is something that has been happening, incidentally, for over 20 years and multiple independent variations, so .. its neither 'a waste of time' nor is it fantasy in any way. These machines are out there, and they work very well.
The Open Pandora is a great little games machine, has decent 3D capabilities, and its successor - the Dragonbox Pyra - is going to be even more superb. Calm down a little, and take a look:
It's not that. Read my parent comment. They lament the fact that someone hasn't freely handed out an open source handheld gaming device... for 2D games. Not only would 2D gaming be outdated and a waste of a modern gaming device, but they wish some company or individual would hand them a hardware device and software platform, all for "tinkering".
They're asking for a million dollars or more to be invested by someone else, simply to be able to fool around with it. The very concept screams not understanding how much time and money it takes to produce such hardware and matching software. We're not talking about $5,000 and one month of development time from some indie developer; we're talking about more than $1 million and 2-3 years of development time from a serious shop... all for free and as open source? Not going to happen.
>all for free and as open source? Not going to happen.
Has happened: GP32, GP2X, GPH WIZ, CAANNOO, Open Pandora .. Pyra .. PocketCHIP.
There is a lot for you to catch up on. These are open machines, made by people who are quite content with contributing a great deal to the Open Source ethos you seem to think has no place in this market ..
What's wrong with 2D? What's wrong with an open OS?
> They're asking for a million dollars or more to be invested by someone else, simply to be able to fool around with it.
And they're presumably willing to pay some amount of money for the opportunity to do so. The groups that have successfully designed, built, and sold open gaming handhelds in the past (and present, actually) seem like good proof that a product like that is something that a lot of people want and are willing to pay for.
> all for free and as open source? Not going to happen.
"Free" as in "gratis"? Maybe for the software, especially if it's built as a hardware-specific SDK, on top of already-available open libraries, like SDL. I'd expect to pay for the hardware, and pay more than something that's subsidized by the subsequent game purchases (like Sony or Nintendo hardware).
well, I did (see my other bitbox project comment).
I can accept a million dollars but I did it for free (in fact for a cost. Of course you can say it's bad, or not a really "modern" in the sense of "powerful" but in the sense of "available with somewhat current plugs" and I was happy to see the GP comment, as in : there are other interested people, fine !
As I'm not the only one, I don't understand your angry comment.
The Gameboy advance homebrew tutorials where my first introduction to C (before then I was using turbo Pascal.) Homebrew is great and devkitpro is really easy to mess with.
Thanks for this post, it really is quite interesting! Tonight I'll try to set up the gba simulator and try to make something small in it as well. It looks quite fun :-)
not being able to get GBA to do 3d is probably a good thing, you can achieve a much better effect using billboarding and creating something like space harrier or outrun.
I'd create something using raycasting and prerendered billboards if 3d was a mush.
These machines are small enough to fit in your head when you're developing, and you really learn to get 'down to the metal' when your builtin libraries are memory addresses and ranges. The development is fast and fun.
I totally recommend checking it out and making a couple of games on something like the Gameboy or Gameboy advance. An excellent learning experience.