I’ve been working on a new little project. It’s a game I’ve been thinking about writing for years that’ll hopefully going to turn out like a cross between the puzzle solving of Dizzy and the exploration of Metroid. Part of the delay in getting started was indecision about the best viewpoint for the game, which I’ve been debating for a long time.

If I opt for a Pokémon-style overhead viewpoint I’ll probably have an easier time with the artwork and the game will be much more sedate, which is something I’m aiming for. On the other hand, it prevents me from including any kind of gravity/jump mechanics, which are an important part of the exploration aspect of the game. If I opt for a Metroid-style sideways viewpoint it’ll allow for jumping but it will also likely introduce annoying Metroid-style platform negotiation that I want to avoid.

Recently I’ve been considering an isometric viewpoint like Head Over Heels or the ZX Spectrum version of Batman. It gives me the advantages of both the Pokémon and Metroid viewpoints, but doesn’t preventing jumping and seriously discourages any finicky platforming action. I’ve decided to give it a try.

I started out with this randomly-generated room:

Rooms are represented as an array of tile structs, which are arranged such that the first element in the array represents the tile at (0,0,0) (the tile at the bottom of the stack at the leftmost side of the image):

The first row of the x axis is the first set of data in the array, followed by the next row, working backwards in the y axis. Once we hit the end of the y axis we move up a level in the z axis and repeat.

The graphics consist of hexagonal bitmaps each representing a single tile in the map. In order to render the map we start with the tile at (0,0,max) and render all tiles to (0,0,0). We then move to (1,0,max) and render to (1,0,0). Once we’ve rendered the entire bottom level of the map we move to (0,1,max) and repeat the sequence again. Simply put, we render from back to front, left to right, bottom to top, using the painter’s algorithm. The map consists of tiles that don’t move and aren’t animated, so we can render it to a buffer and copy chunks of it to the framebuffer when we need to erase things.

Rendering moving objects turned out to be far more involved. The problem is occlusion: sometimes moving objects are in front of background elements and sometimes they’re behind them depending on where the objects are positioned in the 3D space described by the map. Sometimes objects are partially occluded.

The easiest way to handle occlusion is to re-render the entire scene, including moving objects, from back to front each time an object moves. This is inefficient and gets slower in proportion to the complexity of the scene.

A more efficient idea I had was to figure out which tiles were in front of moving objects, render those to separate buffers, and add them to the scene as foreground views. However, this turned out to be trickier to implement than I expected.

Yet another approach I came up with was to use raycasting to render the scene. For each pixel of the screen project a ray into the map and see where the ray intersects a tile. Find that pixel within the tile’s bitmap and draw it to the screen. This approach is promising for two reasons: each pixel is drawn precisely once; and it makes possible interesting enhancements to the game engine, like texture mapping instead of precanned hexagonal bitmaps, and the ability to rotate the map by an arbitrary amount. It’s a much simpler problem than a Wolfenstein-like first-person raycaster because the isometric perspective eliminates all of the complex 3D transforms and trigonometry.

After deciding that a raycaster was overkill I came up with an algorithm that uses a z-buffer instead. It’s split into two parts. First we generate the background image buffer and z-buffer in one step:

Create an array of ints with the same dimensions as the rendered bitmap (this is the z-buffer);

Fill the z-buffer with -1;

For each tile in the map in the order described above:

Draw the tile to the buffer;

For each pixel drawn to the buffer:

Write the depth of the tile (ie the tile count minus the current iteration count of the loop) to the z-buffer at the coordinates of the pixel.

That gives us the background image buffer we need plus a z-buffer in which each value describes the depth of a pixel in the image buffer.

Next we can draw any other objects:

Create another array to store the moveable-object z-buffer;

For each moveable object:

For each point in the left, right and top faces of the object within the 3D space of the map:

Calculate the 2D location of the point within the object’s bitmap and grab the pixel color;

Calculate the depth of the point;

Calculate the 2D location on screen where the pixel will be drawn;

Get the depth of the pixel in the background image buffer by looking up the appropriate index in the background z-buffer;

Get the depth of the pixel from the moveable object z-buffer;

Compare the depths and draw the pixel to the framebuffer if the depth from the moveable object is less than either depth from the z-buffers.

Erasing and redrawing is handled by marking the region that bounds the moveable object bitmap as dirty. When we redraw we blit the relevant background rect into the framebuffer then redraw the moveable objects on top.

If you’re stuck on an aeroplane with nothing to do, what better way to pass the time than to write a new game? I’d written versions of this particular game in Flash and SQL before so creating a new version in C would be more of an exercise in dredging up old memories rather than creating something new (especially as the basics are so trivial to implement), making it an ideal project for a plane flight. I got the game logic working in the air, the rest of the game written over the next few days, and I’ve been mucking around with presentation and fluff for the last few weeks.

Here’s a slightly cropped video of the DS version:

Most of the game works the same way as the monochrome Game Boy version. Personally I think that everything added to the game since the Game Boy version - with the exception of color - has made the game worse, so this version intentionally sticks fairly closely to its minimalistic inspiration. Some of the graphics I redrew from scratch, using the Game Boy Color version as a reference, whilst some started out as screenshots of the GB version. The music came from The Mod Archive; after having no success in using large WAV files of the original audio I was happy to find some great versions of the original music on that site in XM format.

The only aspect of the game I intentionally changed was the responsiveness of the controls. Neither of the Game Boy versions of the game managed to get the controls right. The controls in the GB version of the game were sluggish and unresponsive. The controls in the GBC version grossly overcorrected the problem and made everything move far too quickly. This version finds a happy medium between the two.

I dug out the source code for the Flash version as a reference to see how I’d implemented that, opening it with a hex editor as I haven’t owned a copy of Flash XM or a computer capable of running it for years, but surprisingly there was barely any code in it. Thinking back, the two trickiest parts of the Flash remake were coming up with a function to rotate multidimensional arrays by 90 degrees (in order to rotate the shapes) and trying to increase the automatic drop speed by a constant amount in each level. The Flash version tried to solve the drop speed by using an ugly system in which, instead of regularly dropping the shape every n frames, drops were triggered by a repeating pattern of frames - eg a drop after one frame, then after two frames, then after one frame, etc - in order to simulate fractional frames. Rotating the shapes was tricky because each shape was contained within an array just large enough to accommodate the shape (the box was stored as a 2x2 array while the line was a 1x4 array, for example), so the rotation algorithm had to work with multidimensional arrays whose dimensions changed size as they rotated. Worse, each shape has a rotation point that can fall outside the bounds of its array making it difficult to reposition correctly in the grid once rotated.

For the DS version I avoided the rotation problem entirely by storing all possible rotations of the shapes as pre-canned data in the game, and solved the repositioning problem by representing all shapes using 4x4 arrays. There’s no need to reposition the shapes following a rotation because the arrays are large enough to contain the correct position of each rotation. I solved the drop speed problem by using the frame counts from the Game Boy version as listed over at HardDrop.

Of course, creating a new game led to a number of improvements and enhancements to the underlying libraries, which is the fun but time-consuming part. I wanted to support graphics that were 50% larger on the PSP and 3DS, which meant changing my PNG-to-C tool so that it could convert two PNG files into one C file with #ifdefs to switch automatically between small or large graphics depending on the target platform. I was already embedding two copies of the bitmap data - one for the DS and other platforms and one for the Dreamcast - so I first had to implement real fixes for the hacky system that handled the color space conversions for that platform and get rid of the unnecessary bitmap data.

Once I had support for multiple bitmap sizes I realized I’d also need to be able to support multiple font sizes. I finished off my objc tool for creating fonts from PNGs and added large font support to it.

Supporting XM mod files meant adding mod support to the sound system. That was straight-forward enough: SDL’s mixer library uses libmodplug for mod playback; the DS uses MaxMod; and I’m using MikMod for the PSP. I haven’t figured out mod support for the Dreamcast or any kind of sound for the 3DS yet. Hanky Alien, Chuckie Egg and this game all had their own sound implementations, so I divided the class into two pieces (a data provider and a sound server) and moved the server out into the shared hardware abstraction library. Chuckie Egg and this game now use the server code; Hanky Alien will use it eventually.

Finally, I’ve been adding macros for reducing the amount of boilerplate necessary when creating classes. I’ve also created a tool that will generate new source and header files for classes.

There’s still a bunch of tedious presentation work to do to finish this off. I wrote a hierarchical menu system for Amy Zing that I’d hoped would be the only menu system I’d ever need to write, but naturally the menu system I need here uses a different structure. It’s more like a graph of screens than a hierarchy, in which the decision about which node to visit next depends on logic in whatever object owns the menu instance rather than the option that the user just selected. I’m hoping that the high score system I wrote for Chuckie Egg will just drop in to this game, though I’ll need to write a new view to present it. I need a title screen, a “game over” screen, a “game complete” screen (for the B-type game), some alternative background graphics, launcher assets for the PSP, a two-player mode (on the same device) and music/sound on platforms that currently don’t have it.

This is a very little game created solely for one very little toddler who kept harrassing me to draw mazes for him to solve. The effort involved in creating the mazes vastly outweighed the effort it took him to solve them, so I figured I needed to automate it. The game is loosely based on the snail maze built into some revisions of the Sega Master System BIOS but it isn’t a remake. Like the snail maze, the objective is to guide the red square through the maze from the starting point to the finishing point.

Here’s a screenshot:

I used the Kruskal algorithm to generate the mazes. On the linked page the author complains that the algorithm “tends to create a lot of short dead-ends”, but that property makes it perfect for toddlers who don’t have the patience for extensive backtracking when they take the wrong path.

The game itself took almost no time at all to write; excluding libraries and presentation fluff the game weighs in at around 600 lines of C. The most complex tasks were fixing a weird rendering bug (that turned out to be a missing conversion between co-ordinate systems in the layer library) and writing a bunch of transitions between scenes. The first, and most troublesome, transition looks just like this one I made 7 years ago in JavaScript (hit refresh if the image doesn’t show up; the script doesn’t preload the image), but with the addition of fade out as the image disappears. Unfortunately that proved too complex for both the DS and the 3DS to render at 60fps so I replaced it with a simpler cross-fade transition.

There’s no title screen bitmap and the player’s character is just a red box. I’d intended to come up with a pixel art title screen showing Amy Zing herself, and an Amy Zing sprite that would wander around the mazes, but that’s beyond the limit of my drawing ability (if anyone is interested in contributing a title screen and a sprite in 3 sizes, let me know).

Tinkering with menu systems, transitions, difficulty levels, presentation and general polish took long enough that the toddler in question has long since lost interest in solving mazes.

The output of this program is ClassAClassC. The call to super in ClassC is smart enough to realize that ClassB doesn’t implement the method and will fall back to the implementation in ClassA. super can be used recursively to move up through the class hierarchy despite the type of the object being acted upon not changing.

I’ve been trying to come up with a way of supporting something like this in SZLib, but it turns out that it’s tricky to implement tidily without compiler support.

First, I moved the callbacks struct out of the objects that I create and into their metaclasses. Here’s the callback struct from SZObject:

Aside from being awkward, this meant that each object could only reference the single callback struct passed to it in its initializer. There was no way to work back through the class hierarchy and examine the callbacks of any superclasses. The workaround I used was for classes to expose their callback functions and allow subclasses to call them (so SZSomeObject had a function __SZSomeObjectEquals() exposed in its header, which subclasses of SZSomeObject could call in their own equals implementation). This too was awkward, as it exposed the internals of the superclasses and required that subclasses knew more than they really needed to about the implementation of their superclass.

Callbacks are now passed to the allocator, not the initializer, as part of the metaclass:

Accessing the parentClass in this way gives us the same metaclass each time, so if the superclass’ implementation of equals calls its own superclass it’ll get stuck in a loop. We’d need to pass the metaclass as an argument to the function so that we can update it on each successive call:

I’d rather hide the metaclass stuff somehow rather than force each overridden function to deal with it;

There needs to be a function to lookup the correct callback for each callback;

Callbacks need to be looked up each time the function is called.

The overhead of the lookup isn’t significant so I’m not worried about that, at least with the shallow class hierarchies I’m building. The proliferation of additional functions is unfortunate but I don’t see a way around it in C (I came up with a macro that would generate lookup functions automatically, but it transpires that the C preprocessor doesn’t allow the token pasting operator to inject struct fields (obj->metaclass->##name## is forbidden) which killed that idea).

In spite of the limitations this system works well enough, and achieves the initial goals:

Superclasses can stop exposing their implementations of the various callbacks;

Subclasses can call the standard …UsingMetaClass() functions instead of trying to figure out what their superclasses are doing;

Subclasses can specify NULL as their callback function and the system will gracefully fall back to the superclass’ implementation.

Backup to any computer running CrashPlan in addition to CrashPlan’s servers;

Multiple computers on a single plan;

Unlimited storage;

User-defined encryption key;

Backup external disks;

iOS app;

Reasonably priced;

Simple restore process.

I’ve been looking around for a replacement system. CrashPlan themselves recommend two options: their “CrashPlan for small business” offering, and former competitors Carbonite. Neither one matches my requirements. The CrashPlan alternative has two huge drawbacks:

Instead of being ~$14/month to backup all of my computers, it’d cost $10/month per computer (which works out as $40/month for me).

It can’t backup to other computers running CrashPlan, so I’d need a second system for local backups.

If the feature set was the same I’d consider keeping CrashPlan, but they’re charging more for less.

Carbonite has its own set of limitations:

The $5/month service doesn’t backup external drives, so I’d need the $8/month service (per computer);

The $8 service can only backup one external hard drive;

Files over 4GB aren’t backed up automatically;

It can only backup to Carbonite’s servers;

It only backs up files in your user directory.

It’s cheaper than CrashPlan’s own option, but a backup system that requires a greater-than-zero amount of effort to maintain after the initial setup is a bad idea.

I’m currently evaluating BackBlaze as a possible replacement. It retains many of CrashPlan’s essential capabilities:

It’s priced at $5/month per computer, which makes it more expensive than the old CrashPlan service but cheaper than the other options, and as a bonus it’s a native app.

That takes care of online backup, but what about a local backup? Local backups were unique to the consumer version of CrashPlan, so regardless of what I switch to I’m going to have to run two systems. I have a MacMini that acts as a backup server, so I need something that can backup to that. Time Machine would be ideal, except its GUI melts my GPU and it won’t reliably backup for me across a network (which is why I switched away from it and started using CrashPlan for local backups in the first place).

Arq looks like it might work out. It seems to do everything TimeMachine does, except the UI is a standard Mac app and it backs up via SFTP.

Just in time for it to be killed off by Nintendo in favour of the Switch (if you could ever find them in the shops; grumble grumble), Hanky Alien and Chuckie Egg now run on the 3DS. Getting the new platform up and running was pretty easy. Input was straightforward: the d-pad required switching to a couple of new functions for reading the button state but otherwise the constants are the same in libctru as those in libnds. Touch somehow just worked, which was surprising.

The hardest part was getting the graphics up and running. Not only does the 3DS introduce yet another set of RGB encodings, but the output of the LCDs is rotated 90 degrees from the VRAM. What’s that? You have a bunch of 2D graphics functions that are all optimized around VRAM being laid out in rows, from left to right? Bwahaha! Now VRAM is organized into columns, from bottom to top.

Though graphics were the trickiest part, the most laborious exercise was checking that the projects continued to build correctly for all 5 of the currently supported platforms (DS, 3DS, PSP, Dreamcast and SDL). I really need to come up with a better build system for the PSP and Dreamcast, and it’d be neat if devKitARM supported makefile names other than “makefile”.

There are a few things still to do:

libctru introduces yet another sound API, so there’s no sound yet;

SZLib doesn’t cater for the possibility that a device has multiple screens with different dimensions, so the bottom screen is off-center.

Anyhow, here are early 3DS builds, which I’ve tested out on my old 3DS XL and Citra (which is shaping up to be a great homebrew tool):

I had some problems with devKitARM recently that broke Chuckie Egg and Hanky Alien. Thinking that the problem might be related to some DSi-specific code that got added to libnds, I decided to try out the games on my DS Lite. Unfortunately, the console no longer recognized DS carts. No amount of fiddling would get it to read either of the two carts I tested.

Nuts.

I’d heard that AliExpress - purveyor of fine knock-off Chinese electronics like the GB Boy Colour - had a selection of fake DS Lites on offer, so I went digging. I eventually settled on a cobalt blue DS Lite for the very reasonable price of $40. Given that an original Nintendo console would have cost more than double that back in the day, and given that it’s difficult to find an original, new DS Lite for less than ten times that, it seemed like a chance worth taking.

Here’s what arrived:

Let’s start with the bad first. Side by side with a real DS, the shell is obviously not original. The top case is slightly larger than it should be and bulges outwards slightly along the edge where the clamshell opens. The square black rubber pads that are dotted around the upper screen are fitted imprecisely. The plastic feels cheap, especially when compared to the beautifully glossy Nintendo device. The A, B, X and Y buttons are horribly mushy, and the Start and Select buttons are too small for the holes that they sit in. The cover over the top screen is fitted incorrectly, allowing light from the screen to bleed through its top edge. The screens themselves are set deeper into the casing than on the original. The DS cartridge slot makes a series of nasty griding sounds when a cartridge is inserted, and the cover over the GBA slot is looser than on the original handheld.

In short, the casing is cheap and poorly assembled. But it’s close enough.

Now the good. My original DS Lite came from the factory with a dead pixel; a common problem. Cracked hinges were another, and the hinges on mine cracked not long after I bought it. The clone device doesn’t exhibit either problem (yet). Both screens are perfect and indistinguishable from the original. We’ll see how long the hinge lasts.

Functionally it appears identical to the Nintendo console. When you consider that the K1-GBA still isn’t a perfect clone of the GBA, and that this thing has a GBA embedded within it, that’s stunning. The only explanations that make any sense are that this clone is from a DS factory secretly making extra devices on the side, or that someone stole and replicated the PCBs like the Everdrive clones, or that it’s assembled from spare OEM parts and a third-party case.

It even comes with a box (missing the serial number, of course), manual, soft case and screen protectors.

I haven’t really tried the stylus yet. It’s possible that the touchscreen is terrible. The screen’s texture feels different to the original, though that could just be because it’s new. I haven’t tried the charger yet as the battery is fully charged. The combination of a knock-off charger and a knock-off battery is a little concerning. Other than that, it looks to be a good alternative to either buying a second-hand DS Lite (and possibly ending up with a device that was mistreated) or paying a crazy amount for a new official device.

Oh, and now that I have a second DS Lite, my original console has started recognizing carts again.

This blog is 10 years old. I’d planned to write a retrospective and publish it on the anniversary, but I completely forgot. I did post a new version of Chuckie Egg the day before which was far more entertaining.

In the first post, entitled “Go!”, the blog was running on WordPress and I complained that I didn’t have time to write my own blogging software. After 10 years and 518 posts, the blog runs on my own blogging software that is written in Go. I like to pretend that was clever foreshadowing.

One of the neat features in early Woopsi was screen dimming. The class responsible read each overlapped pixel from the framebuffer, adjusted its brightness, and wrote it back. I eventually had to kill the feature when I changed how the rendering system worked and broke any support for transparency.

Each layer is expected to own all pixels within its rectangular region. To support transparency, there would need to be a way for layers to opt out of subtracting themselves from the redraw rect so that lower layers could draw into the same area. Even if there were a way to achieve that, we’re traversing the hierarchy the wrong way. Transparent views need to render over the top of existing framebuffer data. We need to draw from the bottom up.

The CanvasLayers JavaScript library has a workaround but it’s really inefficient. When setting the library up, it includes the option to support transparency. With that enabled, this is the algorithhm:

Pass in a rect that describes the area to be redrawn;

For each layer in the layer hierarchy, from the bottommost up:

Draw the parts of the layer that intersect the rect.

It’s just the painter’s algorithm. Its awfulness is slightly mitigated by all of the dirty rectangle work that the library does, but we’re still pointlessly drawing a bunch of stuff below opaque layers. We’re also forced to maintain two algorithms to do the same work.

SZLib needed to support transparency in order for overlapping objects in Hanky Alien and Chuckie Egg to work, so I put some thought into the problem and arrived at the obvious (with hindsight) solution: a two-pass algorithm. In pass 1, we iterate over the layers from top-down to figure out which layer will be responsible for drawing what. In pass 2, we iterate over pass 1’s results from bottom-up and perform the drawing.

Pass 1 looks like this:

Pass in a rect that describes the area to be redrawn;

Create an array of layer/rect tuples;

For each layer in the layer hierarchy, from the topmost down:

Find the intersection of the layer with the rect;

Create a tuple containing the intersection and the layer;

If the layer is opaque, remove the intersection from the rect.

Note that we don’t consider an intersection to be “used” if the layer is transparent, which allows lower layers to create their own tuple in subsequent iterations.

In pass 2, we iterate backwards over the tuple array and redraw each tuple. Pass 1 gave us an array ordered by z-index from high to low; by iterating backwards we therefore redraw from the bottom up. Lower opaque layers are drawn before higher transparent layers.

This new algorithm supports transparency with the minimum amount of redundant drawing.