
Gameboy Advance development by example: Drawing and Moving Rectangles - johnfn
http://kylehalladay.com/blog/tutorial/2017/03/28/GBA-By-Example-1.html
======
coldpie
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)

~~~
glhaynes
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?

~~~
russellsprouts
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)

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

~~~
alphonsegaston
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?

~~~
kruhft
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 :)

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

~~~
alphonsegaston
I'll check it out. Thanks for the tip!

------
symmetricsaurus
Nice post about getting started with GBA dev.

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.

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

~~~
milcron
You're describing the PocketChip exactly:
[https://getchip.com/pages/pocketchip](https://getchip.com/pages/pocketchip)

    
    
        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.

~~~
sspiff
PICO-8 is not by the people behind PocketCHIP, it's just bundled with it.

PICO-8 is available for desktop platforms as well, it is not open-source, and
there's a 3D version as well, called the Voxatron.

Both are really cool projects, but not open-source software.

~~~
fao_
> and there's a 3D version as well, called the Voxatron.

Voxatron is a game (even though you can make expansions on the engine), and
predates PICO-8

~~~
mmjaa
.. ah yeah, about that:

[http://www.lexaloffle.com/bbs/?tid=28325](http://www.lexaloffle.com/bbs/?tid=28325)

You can run PICO8 carts in Voxatron now. :)

------
gallerdude
Woah, first ever video game system I could make games for. I'm not sure if
that adds to or removes from the magic...

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

------
Insanity
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 :-)

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

------
tomsmeding
To the author: there's a standard header file <stdint.h> that might come in
use for your various typedefs.

