Let’s try this again

OK so after almost a year of posting nothing, I’m gonna try actually post on this more regularly. The past 11 months have been kinda occupying, I started university and that just kind of consumed my attention (both in terms of having lots of work and also now having some of a social life). However I think it would still be nice to document things I do here, hopefully as a sort of development blog, and maybe even some more possibly helpful or interesting posts like the previous one.

So. Right now I’ve got 2 big things going on in terms of programmy stuff. Well, one, but I have a second that I intend to start working on soon.

The first is Chacket Valleyparker: Drill Bunny, a game I’m helping developing as a part of Dream Show Adventures. Some people may now of Pipe Works, which is a game we have been working on for a while. Right now it’s on hold, and we decided to make something not quite as ambitious, but still fun and a good place to start. I will try to post some progress on it every now and again, with maybe a screenshot or two, or even a GIF. Although our original intention was to make it in 2 weeks, and although that didn’t quite work out we still got a solid engine going. Right now we’re mainly trying to get the rest of the core stuff done. I’ll explain more about it in a later post.

The other, not-yet-existent thing is a program that is able to convert or dump 2D graphics using scripts. The idea is based off of QuickBMS, a great program by Luigi “aluigi” Auriemma that allows you to use scripts to extract archives. Although it is possible to write scripts to do some other fancier things, graphic format conversion is not one of them (or at least, it would take an impractical amount of effort to write one and probably wouldn’t be very fast either). The idea is that instead of having a different program for each kind of archive, people can just write scripts that outline the extraction process, and then the program does all the boilerplate stuff. Not only are scripts easier to share, but they’re also much quicker to write. Even for non-programmers, it’s relatively simple to get the hang of as long as you can understand the format you can make your own scripts.

Now, I’ve made a number of custom graphic conversion programs, but I’ve always thought it would be way quicker and simpler if there was something like QuickBMS to write scripts for. I used to write archive programs before I learned about it, and it’s saved me a heap of time. I decided that I might as well make a similar program that focuses on 2D graphic conversion, to save time for both me and other people. So, I will try to get that underway sometime soon, sharing progress on here to keep me motivated.

So that’s that for now. These two things, along with anything else code-or-whatever-related that I feel like talking about, will hopefully give this blog some content. I really do like the idea of having my own corner of the Internet to put this stuff, I just need to actually sit down and do it.


Game Boy Palette Tricks

A while ago I was looking into the palettes of the original Game Boy, I was reading some discussion about how to emulate the console’s sprite style. I discovered something rather neat, which might be useful for anybody making a Game Boy engine/game or emulating the sprite style.

First off, I’ll explain a bit about the Game Boy’s palette. It’s 2-bit, meaning that it can hold 4 different colours (2 bits can hold values of 00, 01, 10, and 11). These aren’t really “colours” as such, but rather monochrome shades; white, black, and two shades of grey. One of these is actually used as transparency (i.e. rendered invisible), meaning that sprites can be made up of 3 colours + transparency. Simple enough, right?

And if you take a look at the overworld sprites from Pokemon Red/Blue you can see that this is true enough. But if you look at the trainer sprites, you’ll see… 4 colours + transparency? How is that possible?

Well first of all, that’s not what’s going on. There are 3 colours + transparency, as there should be. But if you’ve played Pokemon Red/Blue you will remember that the background of the battles were pure white. What these sprites are doing is just letting the background fill in for the transparency.

It’s a bit hard to explain, so let me illustrate. Say you’re battling your rival, Blue:


You’ll see that both Red and Blue have 4 colours. Except they don’t; their fourth colour, white, is actually transparent. Let me show you what I mean. Say I magically turned the background green:


All of the white pixels in the sprites have been replaced with green. This is because they were never white, rather, the background was. They were just transparent, and the background was filling in for them.

To further illustrate, see what happens if they overlapped:


Obviously, very ugly. This is why the majority of sprites, such as overworld characters and so on, only have 3, and save the last for practical transparency. Luckily, trainer sprites are never seen above anything but the white background, and that’s just the thing; because of they never are and never need to be, they can utilise the background as a fourth colour. The same goes for in-battle Pokemon sprites.

Now technically speaking, they do actually have white in their palette, that’s the colour that the game interprets as transparent. That’s only for these sprites though, you can choose which colour is interpreted as transparent for each sprite.

That’s pretty much it! So if you’re ever making a game that keeps with the Game Boy restrictions, remember that any sprites that will only appear above a solid background can use that as an extra colour. And It doesn’t have to be white, as I said you can choose which colour is rendered as transparent for each sprite.