Part 1: Configuring, Programming, and Compiling

Part 2: Placing Tiles and Moving Sprites

Part 3: Using GBTD and GBMB

Part 4: Colliding Sprites and Project Management

Part 5: ROM Banking

Updating Example Files

Before doing collision code, we should update our background tiles to something more useful than simply the alphabet. In the above file, I have used some tiles I developed for another project and included the original numbers and letters from the earlier parts of this series. Using these — and with a first, 0, blank tile — we can start to make areas that resemble other Game Boy games.

tiles.c

dungeon.c

main.c

Collision

GBDK comes with no built-in physics or collision functionality. If we want collision code, we have to add it in as an additional function. For this example, we will use simple rectangle-to-rectangle checking. If one rectangle (from a starting position x, y and extending outward some amount) is overlapping with another rectangle (from another point some x and y amounts out), then the two are colliding.

We also need something to collide with, so another sprite is introduced and its position saved.

With our new colliding code, sprite0, when it overlaps with sprite1, switches its tile.

Project Management

As becomes obvious from Part 3, the need for a smooth “Save, Export, Re-Compile” workflow is very important when using GBTD and GBMB with other tools. I highly suggest getting into the habit of saving constantly and making sure, with the maps and tiles, all files are as up-to-date as possible before compiling again as well.

However, as the compiling to test code can take time, I suggest the following:

Make your code as module as possible

Without objects and using only functions can make testing and debugging much more time-consuming, but separating the code into logical “chunks” can save considerable time when trying to move from one section to another. Planning ahead and having in mind, for example, a change from a menu to a level, can help separate functions into sections that can be tested as a group.

When possible, re-use variables

While not as important in smaller projects, having simple variables around like “i” and “j” can be very helpful for looping without need to create a new variable. Simply re-use the existing ones to run the loop and then re-use them again in another loop, later. This can save space in both the RAM and the ROM as a result.

Arrays are your best friend

While arrays are already the go-to for data structures in C, and because ROM space is an issue, having an allocated set of positions to store things like a player’s coordinates can save space and makes more logical sense to group them at the same time. This can also be written about “enemies” (or whatever, other obstacles might be on the screen). Adjusting multiple array locations and then using them to display things like meta-sprites are a required technique.

Use the 20 sprite limit wisely

GBDK can only update 20 sprites at a time. Depending on the project, this could be safely ignored or become a vital part of moving tiles around. Keeping an external map either as part of the comments or in anther file can help save your sanity when swapping tiles around and then moving sprites after.