Bio Force Ape Developer's Journal

[PapaStu]

Killing games always comes down to one more simple thing than that. If its expensive, then its likelyhood of being a donor cart goes down. They need something that can be plentifully had for reappropration and Castlevania 3's just arn't it.

I personally don't care if they are gutting SMB/DH's or Castlevania 3's only signed by the creator, i'm getting BFA either way.

[kainemaxwell]

I'd gladly donate a cart for this.

or donate MachineGex's body.

[ProgrammingAce]

Alright, so I've explained how you get the colors for the background, but how do you get the tiles from the CHR rom to show up as the background? It's probably more complicated then you think, and it's strictly because the NES is an 8-bit system. Being an 8-bit system, the NES can only count from 0 to 255. This is a problem when you consider it takes 896 8x8 pixel tiles to fill the NTSC viewing area.

There are several different solutions to this problem, and so far we've used 2 of them. I'll explain each, starting with the method you see in the public demo.

The first method we used, the one that's present in the demo you've all seen, is very simple. What we did was to fill the background with a repeating tile image, in this case the brick pattern, and then draw the other objects over top (the crane/girder and the ground, mainly). This method has the benefit of taking up very little space in the game's ROM.

There are a few downsides though. The more complicated the background, the more complicated the code to draw it. You need to manually assign where each "object" starts and ends and how to draw each shape. As a result, it's much easier to draw repeating patterns using this method, that's why the girder in the background of the demo is basically made up of a horizontal and a vertical bar. Drawing anything with an irregular shape using this method would be a nightmare. The other downside is the rendering time. First you render the background, then you go back and render the vertical girder, then you go back and render the horizontal girder, then you go back and render the ground. That's 4 passes to make such a simple image, and the more detail you add, the more passes it will take.

And here is where we needed to make another decision. This wasn't really a hard choice to make, but it's one of those things you need to keep in mind when making a game. Because of all the downsides to the original rendering method, we decided to scrap it and go with something that would allow for much greater detail using a single rendering pass. The downside is that it would take up more space in the ROM.

So the new method takes advantage of the method that most commercial NES games used, it uses a design called meta-tiles. A meta-tile is simple, it's a group of smaller tiles that can be defined by a single identifier. In this case, our meta-tiles are 4 8x8 pixel tiles aligned in a 2x2 grid.

Let me show you what I mean. Below are a sample of meta-tiles. Each one is made up of 4 of what the NES considers the background tiles.



So we take those meta-tiles as building blocks, and use them like legos to build the background image. We just use a data file to assign where each meta-tile goes, left to right, top to bottom.

So if we use those meta-tiles, and this data file...

	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

The end result looks like this:



From there, it's trivial to add more detail to the background. Just create a new meta-tile and change the value of the data file.

[darkslime]

What an awesome project, definitely gonna buy this when it comes out.

[NayusDante]

Are you using a tilemap editor or writing the maps by hand?

[Kitsune Sniper]

I REALLY recommend using some sort of compression for the tilemaps if possible. All those "0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0" rows could easily be compressed into three bytes if you play your cards right. Something like (Control byte / Tile byte / Number of times byte should be repeated). If the routine that reads the tile order sees the control byte, then it reads the next byte (the tile byte) and the next one says how many times it should be repeated.

I've seen Konami do this on several of the games I've hacked, and they've managed to compress an entire screen's tilemap in a very small space. The space you save can be used to, say, make more levels or such... Those fourteen consecutive 0s could be compressed to three bytes. You may think it doesn't add up... but it does.

[ProgrammingAce]

I REALLY recommend using some sort of compression for the tilemaps if possible. All those "0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0" rows could easily be compressed into three bytes if you play your cards right. Something like (Control byte / Tile byte / Number of times byte should be repeated). If the routine that reads the tile order sees the control byte, then it reads the next byte (the tile byte) and the next one says how many times it should be repeated.

I've seen Konami do this on several of the games I've hacked, and they've managed to compress an entire screen's tilemap in a very small space. The space you save can be used to, say, make more levels or such... Those fourteen consecutive 0s could be compressed to three bytes. You may think it doesn't add up... but it does.

Shhh, now you're ruining my next post! But yes, that is the basis for the compression scheme that i'm applying to the data. There's another step i'm going to add to the process that actually encodes each meta-tile byte with it's palette data as well.

It would save us 64 bytes per screen. Which doesn't sound like a lot, but consider we're looking at 10-15 screens. That's 11% of the remaining ROM space we're have to work with. Anytime we can make something 11% more efficient, we need to go that route.

[ProgrammingAce]

Are you using a tilemap editor or writing the maps by hand?

By hand. I've yet to see any decent tools for NES development, and certainly none that run in linux. If i were concerned about it, i could write a program that takes the artwork Brat gives me and convert it into the tables. But to be perfectly honest, i hate writing game development tools. You spend all this time making a program that does what you can already do by hand in the same amount of time.

Writing better tools may be something i look into between projects, but it's pretty unlikely. If nobody has written decent NES dev tools in the last 25 years, there's probably a reason for it.

[NayusDante]

I mention this because I've been using a rather versatile tile editor called TileStudio. You can define your own output format, and even manage your tileset in the program itself (not sure if that would be useful considering how NES tiles are stored). It's not a complex program, so I'm sure you could run it in Wine. If you can't, I might be able to help out with maps if you send me the tiles and the area layouts. I've been using TS for an RPG, so I'm getting pretty comfortable with it.

[ProgrammingAce]

Ahh! Progress continues!

I'm going to write a bit more about the meta-tile format, I'm not sure i was clear enough. This time with diagrams!

Mind you this is all programmer's artwork, the final game will look much different. Notice how small all of the artwork has to be, it's all designed at the pixel level. The screen at the bottom is the actual size of the NES display



I started with the final meta-tile on the top, that's how it shows up on the screen.

The second row shows how the color information is stored in the ROM. So each meta-tile can be assigned any one of the 4 overall palettes. Each palette has 3 colors, plus the overall background color. The color stored in the ROM assigns which numbered color in the palette the pixel uses. So if the ROM has a white pixel, that's color 1. Red is color 2. Blue is color 3. Black pixels are the overall background color, we'll call that color 0.

The 3rd row shows how the sub-tiles are stored in the ROM. Sub-tiles are the 8x8 tiles that make up the meta-tile. If you look at meta-tile 3, it's all black. Instead of wasting 16x16 space in our ROM storing the same black sub-tiles, we can just repeat the sub-tile 4 times. So this meta-tile only takes up 8x8 space in the ROM. Meta-tile 4 takes up 16x16 space in the ROM because all of the sub-tiles are unique (i can't rotate sub-tiles, so we have to store the rotations as their own sub-tile).

The 4th row shows how you assemble each meta-tile from the sub-tiles. This is all handled in the code, but it helps to show how I'm assembling the meta-tiles. You can see how meta-tile 0 is just sub-tile A copied 4 times.

At the bottom is a picture assembled from the meta tiles.

[NayusDante]

Have you checked out Nesicide? It's an IDE for NES development. Might help here. Again, Windows-only, but Wine might help.

[ProgrammingAce]

Have you checked out Nesicide? It's an IDE for NES development. Might help here. Again, Windows-only, but Wine might help.

I played with it, but it seems more complicated then just writing the code out in assembly. It seems like it's more designed for rom hacking then writing code from scratch. It's not compatible with the source code i've already written, and i'm not about to rewrite 13,000 lines of code for a new tool.

[TRM]

This looks great guys! I cannot wait to purchase the finished game, it would be exciting to buy a fun brand new NES game that actually amounts to something.

Also interesting blurb about grand theftendo being a hoax, ProgrammingAce.

[MachineGex]

Thanks for the updates, I find this project so cool.

[Baloo]

So how far along is this?

[ProgrammingAce]

So how far along is this?

The game is completely playable from start to finish. All of the boss battles are complete. All of the AI and enemies are complete.

I want to rewrite the collision detection, because i think it's a little flaky. We still have the background designs to finish and encode. I really want to do something better with the music, the music engine is pretty damn flexible.

And with that, today's journal note.

I'm not going to go too far into the music right now, mainly because i haven't really explored all the places I can go with the sound engine. I've uploaded the documentation for the sound engine, so you can see how it all works:

http://programmingace.com/images/Bio...pe/nesmus.html

So this is the code that became the music in the demo:

; intro song
t120

;melody
channel 2
v15l8o4cd
;e l4c <l8g> l4fg l2f l8f p8 p4
o3 efg efg efg efg efg p1 def def def def def p1 cde cde cde cde cde

;bass
channel 0
v31l8o2ed
l4c<g>defcf<g>defcf<g>defcf<g>defcf<g>defcf<g>defcf<g>defcf

[ProgrammingAce]

Alright!

So the game is feature complete, meaning that everything gameplay wise that's going to be in the game is in place. We still have some graphics to work out, some bugs to squish, and some gameplay tweeks to implement, but we're well on our way to having a game here.

I thought it might be fun to post a page out of my bug fix notebook:

[PapaStu]

This unicorn better be a sibling to the Unicorn in Diablo 3.

[jcalder8]

I love being able to keep up with the development of this. I can't wait to see the final product.

[Ed Oscuro]

I needed that health :C

Unicrons...rhino's...queens...joys!