The BitBull Blog

I’ve been really busy with a few pieces of contract work over the Summer. Really glad to have had that as funds have been dwindling somewhat – and once that was over I decided to have some time off (something I rarely do unless I’m actually going away).

Anyway, back on it and decided to (not) ease myself in gently with a fairly mammoth task that’s been on my list for some time now – that of implementing alternate palettes.

I wanted to have ‘proper’ alternate palettes (not just throw some kind of tint over everything) and there seemed to be two ways I could have gone about this. 1) I could implement a shader to swap colours at runtime, drawing to an offscreen buffer and using that as the source for my sprites rather than the original, or 2) I could mess with the palette data in the 8bit PNGs as they’re loaded and re-instantiate the source images from the byte data each time the palette has changed.

I have already used the second approach in a J2ME game I produced a while ago so had a bunch of code to hand for swapping PNG palettes, however I decided to go for the first approach here for three main reasons – 1) Instantiating images from byte streams can be a drain on resources as it requires a lot of memory allocation and garbage collection, 2) I have had bad experiences with instantiating images from byte streams in some versions of MonoGame (see here) and 3) I was going to have to edit some of my existing shader code to cope with palette swapping anyway so figured I may as well do the whole thing in HLSL.

Before I even started on the shaders I had a lot of rationalisation of my sprite sheets to do in order to minimise the amount of images that need to be redrawn each time a palette swap takes place. I’ve decided to allow different palettes per sprite sheet and have therefore consolidated my sprite sheets into seven key components – player, enemies, pickups, terrain, floor, parallax and HUD. Each one can have a different palette applied as part of a palette ‘set’ though often multiple sheets will share the same palette.

Next I had to write the palette swap shader itself. I pass a palette image to the shader as a lookup table, the shader compares each colour being drawn to a reference palette and, if it matches, swaps the colour with the colour at the same index in the new palette.

This fairly straightforward approach seemed to work OK but I was getting some strangeness where colours weren’t always matching or were matching wrongly. This seemed to be almost random and I have no idea whether it was to do with MonoGame scaling the images or rendering into a different colour space or what. I fixed it by having my code find the closest matching colour in the reference palette rather than looking for a (more or less) exact match.

Once the basic palette swapping appeared functional I had to go through some of my existing shader code and edit this to cope with multiple palettes. Some shaders had colours from the original palette hard-coded in there (this was fairly easy to change) – others used algorithms for colour inversion and brightness that I was never entirely happy with (ever notice pixels going a bit yellow-y on some of the GIFs, particularly during the ‘teleport’ effect). I changed both these algorithms to only work from a strict colour index and now they work much better.

Lastly I had to go through all the particle effects (groan) and make sure the tints applied to them were from the appropriate palette. This was particularly time-consuming on weapons as I had to apply a different palette depending on whether the weapon was affiliated with the player or an enemy.

And, of course, I actually have to design some palettes. Not quite sure how I’m going to approach this in-game yet but I’ve included some examples of my initial attempts. I think I’m going to go for more subtle palettes (like the original) as the defaults and then include the more garish/extreme palettes as ‘one offs’ and/or player unlockables. With some of these I’m restricting the colours available to give an even more blocky/retro feel.

Dev Time: 5 days
Total Dev Time: approx 219.5 days

previous | next

I started out with a plan to create a kind of ‘robot/alien wasp’ type creature called a ‘stinger’ and it was fairly straightforward to knock up a version with placeholder art, splitting the creature into three separate sprites for head, thorax and abdomen that could move independently. Getting the final art right though was an absolute nightmare. I think this was due to a number of reasons…

1. Wasps are very dark, consequently reference photos were very unclear on detail. Also creating a dark sprite that stands out from a dark background with a very limited colour palette is tough.

2. Insects in general are pretty ‘fiddly’ creatures. The things that distinguish their character are actually pretty small and/or spindly which make them very hard to render in low resolution. I found the legs particularly hard and gave up trying to render mandibles as whatever I did they just looked like a beak.

3. One of the things that characterises a wasp is (obviously) the stripes on their abdomen. These are hard to render at low resolution as angled stripes just look too ‘jaggy’ and going for straight stripes just makes the abdomen look like a boiled sweet, too cartoony and not ‘creepy’ enough.

I started off trying to make the sprite look too realistic, relying too much on reference photography. I then went down a complete ‘robot’ path, trying to create a creature partly from sprites that I’d already designed (mainly the ‘upgrade weapon’ icons). This had potential but was too bitty and I felt going full-robot lacked the creepiness I was after (never go full-robot)! Things only really started together when I sketched out a very stylised wasp by hand and went for an approach that was 50% ‘real insect’ and 50% ‘steampunk’. I stuck with very stylised angles where possible and this seemed to work, particularly on the legs which I was having massive problems with (I ended up separating these out as individual sprites). I reckon I was 3.5 days on the art for this alone.

Thankfully coding the movement wasn’t too problematic, AI is very simple but seems to work nicely. The gamma-ray that it fires from its ‘sting’ was a bit of a pain in the arse as I had to redo my original gamma-ray code to cope with being aimed at an angle, this meant I needed to use raycasting for the collisions. Fortunately I could reuse code from the ‘shredder‘ weapon but still, this was non-trivial due to my lack of foresight in the way the original gamma-ray was implemented!

There’s a two-stage attack pattern whereby the player must destroy the creature’s abdomen first. At this point the creature becomes faster, more aggressive, and starts to spit poisonous space-venom! The venom-spitting effect is created with particles.

I still need to add some custom audio and maybe work on the explosions a bit more (these ones don’t seem bit enough and bigger enemies also need bigger bones!) but, for now, this one is finally done. Six bloody days!!!

*** edit *** ….and, I’ve just realised when I grabbed this video that I had immunity on the player for debug purposes (groan). That’s why the enemy’s attacks aren’t doing any damage!! I need a break!

Dev Time: 6 days
Total Dev Time: approx 171 days

previous | next