yet another tech blog

making a gba game part 2: getting the things onto the screen

June 03, 2020 — nytpu

The most up-to-date code is available in the repo: https://tildegit.org/nytpu/game

finishing up first-stage character design

I left off my last post with unfinished sprites and tilemaps. They're still unfinished now, but I still needed to finish up the basics and get the player character sprite designed before I could continue work on other aspects. I got the basic ground and one obstacle for the hub designed, and all I needed was the player character before I could get started coding. The problem is, I had plenty of ideas for other NPCs in the game, but literally no idea what the player character should look like. However, through sheer luck, I was randomly doodling in Aseprite (my preferred sprite editor, although there's no tilemap editor yet) and drew a strange little outline, and it looked pretty good. "Maybe this will be another NPC" I thought. But, after cleaning it up and turning the random colors I picked into a palette, it looked really good (at least to other pixel art things I've done before). I christened him Schnoz for his huge schnoz, and decided that since it's the only character I've actually designed so far, that he was going to be the main character. Adding a second frame for a simple animation (see! I'm not so inexperienced that I don't know about the wonders of XOR for animations). I decided that he looked like a dolphin and added a blowhole and changed his colors to be more blue-grey to match a dolphin's. I tried to add a tail, but I just couldn't get it to look good, and it looks good enough without it anyway. Just ignore the fact that since he's a dolphin his schnoz isn't actually a nose at all.

Original Schnoz
Schnoz the Dolphin

getting it to something the gba understands

This section title may be a little on the nose, but it's exactly what I needed to do next. I have all these beautiful okay sprites and tilemaps, but how do I get a modern image format into the GBA? Well, there's a tool called grit—written by cearn, who also wrote tonclib—that converts images to either .c and .h files or into another of a range of binary formats depending on how you want to work with the data in the GBA. I already knew that I wanted to use the Game Boy File System because working with a bunch of .c files that contain your data is a pain especially if the data is compressed and you have to use the GBA BIOS to decompress it, so I simply fired up grit and had it convert the images into plain LZ77-compressed binary files that I then shoved into a GBFS tarball and added it to the ROM. With that good, I managed to get it to read and decompress the files from GBFS with relative ease, and now I was finally able to pull out my tonc knowledge that I spent all that time learning last blog post. Loading the tilemap data, tile data, and character tiles into the right spots, then flipping the right switches, and adding basic input methods to scroll the background, and voilà, things were displayed and I could look around the map by moving the screen, and the first actual version, v0.1.0, was released.

See v0.1.0 in action:

creating some semblance of an actual game

With stuff actually working, I hurriedly got Schnoz displayed and moving around with the arrow keys. However, then came a part which was more difficult than I thought. I wanted the background to scroll when Schnoz reached the outer ¼ of the screen, but for the background to stop scrolling when it reached the edges of the map. I still haven't figured out how to do it without using these if statements. I still think that I might wrap it in it's own function somehow, but I deliberately didn't break out anything yet. However, with Schnoz now being able to levitate around the screen and ghost through objects, v0.2.0 was completed. The next order of business is to add gravity (easy) then add collisions with the terrain (difficult), so we'll see how that goes.

See v0.2.0 in action:

tags: gbagame

making a gba game part 1: learning, planning and designing sprites

May 27, 2020 — nytpu

The most up-to-date code is available in the repo: https://tildegit.org/nytpu/game

introduction and choosing a console

Around November 2019, I decided that I wanted to make a game on a retro console! Something that I've wanted to do for a while, but have never actually done. I have experience programming older systems, and my first instinct was to write it in TMS9900 Assembly on my TI-99/4A, and I've written basic to moderately advanced programs on it, but looking at the palette, limited number of sprites—16 TOTAL, not just on one scanline!—and the annoying 256 bytes of directly addressable ram while hiding 16KiB of memory behind the VDP makes it really bad for games unless you're a genius programmer and hardware hacker with lots of time.

With the TI-99/4A out, the obvious next logical system to choose is the Game Boy (I only chose it because it was the only other retro system with a flash cart I had lying around other than a TI CC-40, which, while being a very interesting system, and shows TI's transition from home computing to calculators, is not good for games). However, I didn't know a lick of Game Boy assembly, and, upon researching, there seems to be no accurate reference other than the GB Pan Docs and not one accurate finished tutorial, nor any books other than Nintendo's development manual. I realized that trying to learn GB assembly using pure reference manuals while jumping right into making an ambitious game, while doable, was probably not a good idea.

I really wanted to write it in assembly, because I'm a crazy person, but the only other system I had lying around was a GBA, but I didn't have a flash cart for it. I picked up a relatively cheap EZ Flash Omega and I was good on that front. Now, armed with a flash cart, I decided that I would lose my dream of writing a game in assembly and would just write in C for the GBA, because, while I didn't know GBA programming, I know embedded programming and C, so it wouldn't take much to learn about the GBA, plus there's an excellent tutorial that I could run through before actually getting started on the game. And, I could always write the functions that needed to be optimized the most in assembly still anyway.

planning and learning about the gba

With my console picked out, it was now time to formalize my ideas and plans for my game (still untitled because I'm bad at that), but first, I needed to learn about the GBA, it's capabilities, and what I would be likely able to program on it with my ability. Preferably have some practice writing stuff for it too, so I could jump right into making it after planning it out.

So, I started reading through the tonc tutorial, and ran through each section, and tried to make a demo utilizing everything I learned at the end of each section ("Basics", "Extended", etc.).

However, I decided to take a little break after "Extended" and get a head start on planning, and start working on the graphics for the game. I had tons of ideas bouncing around my head and I wanted to write them down, organize them, and formalize them before I forgot anything.

I just replayed Squirm, so a lot of the ideas I have (primarily the color palettes) are inspired by it. My main first ideas were to have a series of zones ("worlds"), that are connected together à la Metroid. The main world is to be a hub, that is designed with a primarily greyscale, dark color scheme. It is primarily rock themed, and will try to capture a cave-like feel. The primary obstacles will be platforming sections around spikes and other physical obstacles. All of the other worlds aren't going to connect to each other, and will only be connected to the hub, for simplicity of programming, and for enforcing some form of linearity.

The next world (although I may rearrange them later) is a "fire" or "lava" world (I call it fire), that is obviously orange-red themed. The main surface will be sort-of brick themed, but more flat, more akin to lightly textured stone. The main obstacle will be lava, possibly flowing or mobile, and will have unkillable fireball "enemies" also.

The next world may be a water world, but I may change it to a castle or similar themed world. However, the main world that I'm excited for will be the final or second-to-final world, and will initially be cheerful and brightly themed, and be meadow-like. However, after a short distance, it will slowly transition to a brown, dead, corrupted color palette, and will become cavernous, with difficult enemies and obstacles.

The rest of the game is yet to be determined, but, as each world will be fairly long, and I don't necessarily want the game itself to be very long, these worlds may very well be sufficient.


The most current artwork is available on the art branch: https://tildegit.org/nytpu/game/src/branch/art/art

Now we get to where I am now, where I'm designing the sprites for each world. I started out by pulling up coolors and using the palette generator to find a background and foreground color that I liked for the world I'm designing. After finding those, I copied the hex codes into the gradient palette generator to get a gradient of 6 colors that I then imported back into the normal palette generator to touch up. While on the GBA I can have 16 colors per palette, I prefer to use fewer colors because I'm not very good at pixel art, and using fewer colors makes it easier and helps enforce a style. For the overworld palette, I started out generating a nice green palette in the same way I did previously, but added a sky-blue background on top of the 6 green colors, and added 3 additional "accent" colors, that I'll use for flowers and things. Then I duplicated the green palette and messed with the saturation and brightness until I got the brown colors I wanted. I then manually changed shades for each color, touching them up until it was how I wanted. The only thing is I'm going to have to clamp the colors into the GBA's colorspace, so we'll see how that goes.

Overworld 'Good' Palette Overworld 'Corrputed' Palette

Once I got the palette all generated for the world I was looking on, I then started working on the base ground tile (<world>_ground in the repo). I decided on using 16x16px tiles because 8x8px was way too constricting. Once I got that how I wanted, I copied it into the tilemap 9 times into a square, and 3 more times into a line. I then added borders how I wanted. For the overworld, I don't have to make different tiles for the "good" and "corrupted" variations, because I can just toggle the palette in software and it will automatically change the colors. However, I will still export the image in both palettes to ensure that it is viewable in both variants. I continued working on the other tiles in much the same way, and am still working on this process for all of the worlds.

work-in-progress tilemap for the hub

the future

I still have to finish up tiles, and then work on sprites, but I also should work on sound and music too. However, the only experience I have with sound is with LSDj on the Game Boy, and even then I barely understand GB audio. I get the feeling I may be relegated to the digital audio channels for the GBA, but even then I probably will work on sound dead last, the most I may do is write in dummy functions for actions so sound could be called later. I'm probably going to finish up the hub sprites then start coding in core game logic and the game loop.


Hopefully my next post will be significantly shorter, but I had a lot of introduction to get through, and a lot to write about because I only decided to write a chronological dev log now, when I was previously planning on writing one complete overview when I was completely done (although I still plan on doing that). Check out the repo linked at the beginning of this post to see my current progress, although I don't push until I make a major commit.

tags: gbagame