Art is Art and Water is Water

August 1, 2016

MURIDOS Devlog 4: Backgrounds 2

Filed under: MURIDOS — foone @ 11:11 pm

The next step: Investigate the palettes being generated and see if there’s something going wrong there.

I completely rewrote the palette generation (not hard when it’s just a big unix command line), reexamined all the images, and compared against the existing palettes: perfect match. I double checked the palette loading code, to make sure there’s no issue there, with swapping channels or some similar issues. Nope, everything looks kosher.

So let’s pretend we don’t have a palette issue and move onto the next step: DUM loading, DUM being the custom image format I created for this project. It’s very simple! 5 bytes of header, giving it a unique identifier (D8 for “Dum 8-bit”) and width/height, followed by zlib-compressed image data.

This is a straightforward if tedious process. Using the 5-lines of python that comprise the encoder as a reference, I write 70 lines of simple C++ to load DUM files. And then run the prototype to test it, and hey, look!


Suddenly our colors look a lot better from last time. My hunch was accurate: something about the TGA conversion process or TGA loading process was corrupting the colors. DUM has no conversion, and therefore has no problem.

The only remaining issue with backgrounds is that the loader needs to be expanded to be more efficient. Currently it loads the entire image into RAM, creates an equally large allegro image, and does all the decompression in one shot. This requires more ram that is necessary, and won’t work on real DOS hardware, where we may not be able to access all the video ram at once, thanks to bank switching. For this early test it’s fine, but it may become an issue in the future once we start running on real DOS hardware.

For next time, we’ll look into loading objects into our empty levels.


July 28, 2016

MURIDOS Devlog 3: Backgrounds

Filed under: MURIDOS — foone @ 9:21 pm

We’ve got a blank window with correct palette, so what’s the next step? Backgrounds!

It’s not as simple as a plain background, like a single image. Or even a single layer of tiles! no, this is a multilayer system. The first step is converting the output of the room-dumper script into something that’s easy to load with C++ code.

 -50: x=90, y=38:  0, 0:bg_tiles1
 -50: x=90, y=39:  1,16:bg_tiles1
8999: x=50, y=32:  2,20:bg_tiles1
8999: x=50, y=33:  6,20:bg_tiles1

This means “layer at priority -50,  coordinates 90,38, draw tile at 0,0 from the bg_tiles1 set”. But thankfully the background tiles are all the same size (16×16 pixels), so we don’t have to encode that.

The scheme I ended up using, for tiles:


a 16bit integer, with the first 4 bits indicating which of the 5 tilesets are used. The next 4 bits indicate the x-coordinate (The tilesheets are 8-12 tiles across), and the next 8 are used for the y-coordinate. Naturally these are tile coordinates (so they’re interpreted as times 16) instead of pixel coordinates.

Then those raw blocks are grouped into rectangles, which have a width/height and an x&y offset. This will be more efficient than having all the layers be the same size, as most layers will only encompass a small subset of the map, and we don’t want to waste time processing empty tiles. We just need to sort the layers so that they render

So here’s a display of level 1-1, with the layers outlined:


It’s as simple as that! we go through the layers, blitting out of the selected tiles to the screen (eventually backbuffer).

The only problem so far is that those colors are completely and totally wrong. And some layers seem to be missing. More investigation is needed!

July 27, 2016

MURIDOS devlog 2: Initial code

Filed under: MURIDOS — foone @ 10:30 pm

So now that we’ve got all the resources helpfully extracted, it’s a matter of putting them to use. We have all the code from the original game, but that’s not yet helpful;

  1. It’s not a language we can directly use (it’s Game Maker 7 code) or emulate
  2. It’s only half the code of the game. It handles interaction between objects and when to spawn them, but all the code that draws them or detects collisions, draws backgrounds and sprites, plays sound and handles input? That’s all built into game maker.

So let’s put the code aside for now. We need to build something from scratch, and we need to use it in DOS. This limits our options. Running SDL/pygame/opengl? out of the question!

So I’m going to be using Allegro. Specifically, Allegro 4.2 as that was the last version that supported DOS. This gives us much of the functionality we’d get out of something like SDL, and we can compile for DOS using DJGPP. We can also compile for Linux/Windows natively, which means we can easily develop without having to keep a DOS VM on hand.

Now using Allegro with DJGPP means we’ll be targeting a 32bit extender (so a 386+) and VGA graphics. This may seem like overkill for the type of game MURI is in tribute to, and it is. MURI is definitely inspired by 16bit EGA games like Captain Comic, Commander Keen, and Duke Nukem. But the reality of how this game will be played is that it’s most likely going to be in DOSBox or in (relatively) modern DOS gaming machines. So neither 386+ or EGA will really hold us back in terms of what computers can play it. It’s a minor inaccuracy, but one we’ll have to live with.

So to begin with, we start with a simple allegro example. We set up graphics and keyboard, display a simple screen, and exit. The first things added are loading the palette:


Which has several similar but not exactly identical colors. This is another reason we’re not targeting real EGA: EGA is limited to 16 colors and we have 26. We could merge some to get it down to 16, but even then we have the problem that these aren’t the 64 EGA colors.

So if we’re using VGA, we have 256 colors to work with, so there’s no reason to not use the colors as-is.

Next time, we get backgrounds working!

July 26, 2016

MURIDOS devlog 1: Resources

Filed under: MURIDOS — foone @ 7:30 pm

So, extraction should be done. I’ve got all the original art (objects and backgrounds), levels, sounds, and code extracted out of the MURI Game Maker file. This should have been a simple task, but Game Maker 7 is a mess.

There’s a “save all source” option, but it gives you the source of all user-defined functions and nothing else. There’s also plenty of source associated with event handlers, which have to be manually extracted. I said “screw it” to the manual process and wrote a script to extract them by automating opening all the various windows and clicking on all the buttons.

As for images, backgrounds were simple as there’s only a few and they can be done manually. Object images was much harder, and required automation again to extract them.

For extracting level data I went the opposite route and modified the source, so that when it loaded a new level it also created a pair of text files listing where all the tiles were and their properties, as well as the objects loaded into the level.

Sounds were done manually, although they’re temporary. MURI uses WAV soundfiles for the effects, done in a style to emulate the PC speaker. Well, I’m making a DOS port. I happen to have a PC speaker! So I’ll need to reverse engineer how they work, and encode that into an equivalent series of instructions for the PC speaker. Time to break out the (virtual) oscilloscope!

There was also a lot of cleanup to make later steps simpler. Unifying all the files into 256-color images with the same palette (the raw images are true color, even if they only ever use ~20 colors). I created a very simple image format called DUM to easily encode the images, as no existing image formats really fit my needs. It’s basically just a header and gzipped pixels, no palette or other metadata.

(Most of this was done nearly a year ago. I’m just now getting back to this project)

Create a free website or blog at