Category: News


Tool: Tile Converter

Throughout this project, taking a concept drawing of a background screen and converting it into data the NES can use has been a time consuming process. I’ve been converting the meta-tiles, drawing up the data, working out the compression and assigning the colors all by hand in a small notebook. The process takes about 2 hours per screen and it’s not fun.

So I finally decided to do what I hate to do and write a tool that does some of the work for me. I wrote a script called TileConverter. What it does is simple, you give it a bitmap made up of tiles, it spits out a table of tile data you can import into a game. It works with any sane tile size 8×8, 16×16, 32×8, it’ll even do 10×93 if you want it to. Just make sure your image is actually divisible by the tile size. If you split a 100×100 px image into 8×8 tiles, you’ll get weird results.

So how do you run it? Simple. First thing to keep in mind is that it’s made for linux. You might be able to get it running under cygwin, but you’re on your own for that. Second, you need to have imagemagick installed. This is an image manipulation program that should already be in your repository. If you use linux, you probably know how to install software if imagemagick isn’t already on your system.

So to run the script, just type in “./tileconverter bitmap.bmp”. It’ll only take a second or two to do it’s thing, then it will spit out a text file with your tile data. Your meta-tile numbers probably won’t match up with with what the script outputs, but a simple find/replace will put it in order.

So download here if you want to try it. I’ve included sample input and output. As always, I make no implications that this is the most efficient method of doing anything. If you want efficient use of code, I wouldn’t be looking at bash scripts for examples… Download here: TileConverter

Possible future features:

- Automatic RLE compression

- Meta-Tile offset (if this level’s meta-tiles start at 20, the script will start it’s output at 20)

Just a reminder for those of you who have purchased the competition cart, the actual competition mine cart mode is hidden behind a password.

At the title screen press A + B + Down on controller 1. Press select at the title screen to access Volleyfish.

Thanks to everyone who ordered a copy of the competition cart, we really appreciate the support. All orders that have been paid for have been shipped. We are temporarily out of stock at the moment. We will be doing another run of carts later this month.

If you’d like a heads up when we’re back in stock, just sign up here on our site and we’ll let you know.

Someone asked to see what the RLE compression I described yesterday would actually look like. In the interest of time and sanity, I wrote out the scheme for the hybrid RLE in pseudocode.

I guess first, an explanation of what pseudocode is, since wikipedia’s definition is way too damn complicated… pseudocode is like a sketch of what final programming code would look like. Like an artist might sketch a painting beforehand, a programmer may write out pseudocode to outline what the software should perform.  Generally, someone with programming experience should be able to take reasonable psudocode and turn it into code for almost any language.

So here’s how to implement RLE compression, you can use it for NES, GBA, SNES, etc..:

int i = 0
int active_tile = 0
int RLE_counter = 0

.loop:
    active_tile = compressed_data[i] //read the i byte in the array
    if active_tile = 99 { //if the active tile number is the flag for compression
        set active_tile = compressed_data[i + 1]  //set the new active tile as one byte up from i
        set RLE_counter = compressed_data[i + 2]  //set the loop counter 2 bytes up from i
.RLE_loop:
        write active_tile to $2007
        i++
        RLE_counter--
        if RLE_counter != 0 goto .RLE_loop
        goto .loop
        }

    write active_tile to $2007
    i++
    if i < 240 goto .loop

That looks lot more complicated then it really is… Just keep in mind that “i” is keeping track of how many meta-tiles have been written to the background, and the RLE_counter is keeping track of how many tiles are left to draw in the RLE compression. One’s counting down, the other is counting up. It may be easier to follow if you start i at 240 and work your way back to zero.

Compression

Another day, another lesson. I’m skipping over collision detection for the time being, as I don’t think I see eye to eye with the general stance on NES collision detection. We’re going to go straight into data compression, yay! Stick with me though, it’s not as boring as it sounds.

As I’ve said before, NES games typically use a form of meta-tiles. What this does is allow you to paint a large group of tiles with a single byte. This is already a form of data compression, but we can do better.

If we go back to our topic on meta-tiles, we can see that we used these tiles:

Drawn in this pattern:

Code:
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 3, 3, 3, 3, 3
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 3, 3, 3, 3, 3
	data 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 3, 3, 3, 3, 3
	data 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 2
	data 6, 6, 3, 5, 4, 6, 6, 4, 5, 3, 3, 3, 3, 5, 6, 2
	data 5, 5, 3, 3, 4, 3, 5, 4, 3, 3, 3, 3, 3, 5, 5, 2
	data 3, 3, 3, 3, 4, 3, 3, 4, 3, 3, 3, 3, 3, 3, 3, 2

to produce this picture:

Now that’s all well and good, it produces a pretty picture and the data is easily read by a human, but there’s a lot of wasted space in that big chunk of data. We can use some simple compression to knock it down.

There are a lot of ways we can do this, we’re going to focus on two of the simplest called Run Level Encoding (RLE). One way we’ll call a hybrid compression, it would allow for both compressed and uncompressed data within the same block. The other way assumes all of the data is compressed. There are benefits to both methods, depending on how complicated your background designs turn out to be. If you have a fairly simple background with lots of repetition, compressing all of the data is the way to go. If your backgrounds are complicated and use a lot of different meta-tiles without much repetition, you may be better off with the hybrid approach.

We’ll start with the hybrid compression. Both systems are very simple, the only difference is that the hybrid compression uses a flag in the data to signal when the game should draw repeating tiles. So let’s say the flag to trigger compression is 99. If you look at the data above, we want to draw the “0″ meta-tile 14 times in the first line. So we’d set the flag for compression, 99, then set the tile we want to draw, 0, then the number of times we want to draw it, 14. We’ve just reduced 14 bytes of information down to 3. After that, the rest of the line doesn’t have any repeating tiles, so we don’t set the compression flag.

So using the hybrid compression, the first line of data for our background looks like this:

99, 0, 14, 1, 2

We just knocked 16 bytes of data down to 5. But can we do better? Maybe, it depends on the data we’re trying to compress. And that’s where assuming all of the data is compressed comes into play.

So instead of using a flag to tell the drawing function which data should be repeated, let’s assume all of the data is formatted that way. So for our first line we have tile 0, repeated 14 times. Then we have tile 1, 1 time, then tile 2, 1 time.

So if we were to draw that out, our first line would look like this:

0, 14, 1, 1, 2, 1

This knocks our 16 bytes of background data down to 6 bytes. You can see even though we took out the control byte to flag compression, the end result is slightly larger. Which system works best depends on the data being compressed. You would probably have to try each one and see which produces a smaller chunk of data. Generally speaking, the more complicated the design, the better the hybrid method would work.

The lesson of the day? Using a combination of compression and meta-tiles, we can designate 32 background tiles in as little as 2 bytes. For our example above, we knocked 32 tiles into 5 bytes. We could actually go farther with the compression if we need/wanted to, but generally this is pretty sufficient. You’ll quickly start getting into algorithms that take too much CPU time, or too much rom code. This is a pretty happy trade off between code, storage, and CPU time.

At MGC, Robot Panic was kind enough to host the Bio Force Ape competition. At the end of the competition, they interviewed me for their podcast. If you’d like to learn more about the competition or Bio Force Ape in general, this is the place to go. Thanks to some awesome guys and gal at Robot Panic for all of their help!

Website:  http://www.robotpanic.com/?p=7798

Podcast: (Bio Force Ape starts at 29:11) http://www.robotpanic.com/podcasts/2010/03.28.2010.mp3

Instead of making a video and showing some of the gameplay from the competition cart, I’ve decided to provide something better… Screenshots!

Click the images below to see them in full size.

Ok, so here’s how to order the competition cart.

Paypal $39.85 to Dave2236@hotmail.com . Make sure you select payment as “Goods non-ebay” or paypal won’t include your shipping address and we will have to cancel the order.

For international orders, please send an email to Dave2236@hotmail.com for a shipping quote.

Or just click the butter monster above.

Ok, so Midwest Gaming Classic went great. We ran the competition on Saturday from 10:00 AM until 6:00 PM. I’ll post more information on the contest later, but the winner ended up with a score of over 13,000 points, beating the developer’s high score by more then 2,000 points.

For MGC we decided to produce a limited edition black cartridge, nearly selling out within the first hour. The first, second, and third place winners in the competition won gold, silver, and bronze copies of the game.

Here is a pic of the 3 championship prize carts:

Because MGC is the birthplace of the Bio Force Ape rom, we also released a limited edition black cartridge just for the show. For those of you keeping track, these were numbered 20-40. You can see it here:

And of course, we have an extremely limited edition green version of the cart. It’s one of a kind. More details on how to get this cart will be available soon.

Pricing has been announced for the Bio Force Ape Competition Cart. It will go on sale at the Midwest Gaming Classic on 3/27/10 for $35. Online orders will open up on 4/1/10 for $35 + shipping.