Bio Force Ape Developer's Journal

[ProgrammingAce]

Well, i think most people have figured out that there is a Bio Force Ape homebrew in production. A demo was released a few weeks ago, you can find it in the link at the bottom of the post.

We've gotten a lot of requests from people as to how the game is coming along and what is going to be included. We're not ready to discuss all that right now, but we thought it might be fun to show off a bit of what's going on behind the scenes.

To give an idea of where the game is right now, 4 of the boss fights have been completed and are playable from start to finish, 5 of the cut scenes are in place, the "level engine" is complete, and 98% of the graphics are in place and final. The game is sitting at 8,765 lines of code right now, I estimate it will be over 10,000 by the time it's complete. We're not prepared to discuss the game's progress much beyond that, we want to leave some things a surprise.

I thought it might be fun to post some of the notes from my notebook without any explanation as to what they mean.

http://programmingace.com/images/BioForceApe/BFAQueen.jpg


http://programmingace.com/images/BioForceApe/BFAProjectiles.jpg

Link to the demo rom: http://programmingace.com/downloads/BioForceApeDemo.nes

[PapaStu]

I bet you used ink laced with Dur Butter didn't you?

I demand to see the min/max's for his fart attack! I must know how many apples one has to eat to shoot pixelation out of their butt!

[Gameguy]

ProgrammingAce, are you paulB812?

[Oobgarm]

I can assure you, he is not.

[MachineGex]

I may have missed it, but is there going to be a "cart" release of this game?
If so, I want to pre-signup for the pre-release signup list. ;)

[jcalder8]

I may have missed it, but is there going to be a "cart" release of this game?
If so, I want to pre-signup for the pre-release signup list. ;)
Well I pre-signup for the pre-release special edition release

[GrandAmChandler]

ProgrammingAce, are you paulB812?

No, Garry Shandling is.

[Bratwurst]

I may have missed it, but is there going to be a "cart" release of this game?
If so, I want to pre-signup for the pre-release signup list. ;)

A cartridge release with color booklet and box is planned.

As I admitted in an earlier thread, I'm PaulB812. I'm doing the graphics for this homebrew, so it must be authentic!

The method we're using to draw characters on screen breaks down each sprite into 8x8 pixel tiles, in the demo it's not apparent if you look at the character data but in the final build there is some serious efficiency going on.

http://home.roadrunner.com/%7Esaucisse/DPcomics/apesprites1.gif

The ape character is 4 tiles high by 2 tiles wide, but you can see that part of his head is 'recycled' in a running animation frame, making him occupy 30 tile slots between standing and running. However, if we reuse his legs, the lizard man enemy here ends up only occupying 14 tile slots, once again incorporating one frame that recycles the head of another.

[ProgrammingAce]

Those graphics Bratwurst posted are actual size by the way, and those colors are how the NES stores it's sprite data. I have a tool that converts a bitmap from a 24 bit 4 color bitmap to an NES compatible CHR rom.

Because we're not using a mapper for this project, all of the sprites need to fit in 128x128 pixels. Same for the background tiles. Which is pretty impressive when we managed to include something the size of the logo on the title screen.

As was the case in many comercial NES games, Bio Force Ape uses both sprites and background tiles to draw some of the game's bosses.

[ProgrammingAce]

http://programmingace.com/images/BioForceApe/BFAMines.jpg

[ProgrammingAce]

Heh, i first had this crazy idea while i was quite drunk at MGC earlier this year. Why hasn't someone homebrewed this game yet? Well, i'm a pretty decent programmer but i suck at artwork (see the stick figures above). I needed help. I knew Bratwurst was PaulB, and I had seen some of his artwork around, mainly on the genesis covers he made.

I may be a good programmer, but i haven't worked in assembly in years and i've never even considered writing code for the NES. I had no idea where to start, and before i pull someone else into this project i needed something to prove, not only to Brat but to myself as well, that i could pull this project off.

So i spent about a week learning how the NES works, how code interacts with the GPU, how the controllers are handled... etc. I admittedly didn't have a very good understanding of how everything worked, but i knew enough to start putting things together. I finally sent a quick PM to Brat telling him my plan. He came back pretty quick, he was up for the task. Kick ass, we're on our way.

Brat sends me the original images he used for the hoax. At this point i'm probably one of the very few people with a clean source image for the butter monster (i'll let Brat discuss that whole thing). So i take the sprites he drew for the ape, and put them together into the quick and dirty engine i was making to learn the NES.

This is the first time we actually got the ape into an NES game. I sent this back to Brat as a proof of concept, to show we really could pull this together and make a game out of it. After this, we really got started on making the game in full.

Just a few notes on this rom, i'm not sure how much of this even Brat knew:
- The green "ground" the ape is standing on was my attempt at making the girders that ended up in the final demo you all saw before. I was still trying to figure out how the NES' background palettes worked at this point.

- The ape in this rom is about 50% bigger then what we ended up with. See, Brat was very careful to take the NES' color palette into consideration when he made the hoax images, what he didn't realize was the NES requirement of 8x8 pixel tiles. All the images in the hoax were made from 10x10 px tiles. In order to pull off this early test build, i stuck with the 10x10 tiles for the ape.

- This was the final build of the test engine i was writing. Everything beyond this was officially work done on the Bio Force Ape engine. As such, i *still* haven't changed my build script to update the name on the final executable. Every time i hit compile, it produces a file called bg_sprite_demo.nes. It stands for Background and Sprite demo, from when i was trying to figure out how sprite and background tiles would come together to form the final screen image. This has created some problems in development where i've mistakenly emailed off the wrong build of the game...

And so you can take a look at the *original* incarnation of Bio Force Ape, here's the rom: http://programmingace.com/downloads/BFApe(initial_test).nes

It's funny, when i look back at that rom i realize how little i really understood about NES programming...

Controls:
D-Pad: Movement
A: Jump
Start: Turn off physics
Select: Swap background and foreground images (more to the point, cram the ape behind the background tiles.)

[Fuyukaze]

I still dont believe in bio force ape. April fools was last month. Besides, isnt the joke like 4 years old already? I know classic gaming is all about realy old systems that have lost new releases on a mainstream level but that doesnt mean our sense of humor has to collect dust and focus only on the same old things. New fake proto destruction please.

[TheDomesticInstitution]

I pretty sure they're serious about making some homebrew carts with this. You know there's now a playable ROM of the game right?

If this is indeed some sort of asshattery, they seem to be putting a lot of time and detail into it just for the sake of being known as supreme smartasses.

[jb143]

Make sure you test on a real NES as you go. An emulator will let you get away with things that the real hardware won't.

Good luck with the project.

[ProgrammingAce]

We're testing the game on a powerpak as we go, we'll be testing on final carts before we ship. We want to be absolutely sure that the powerpak itself isn't causing any issues.

[Bratwurst]

I still dont believe in bio force ape. April fools was last month. Besides, isnt the joke like 4 years old already?

This is not a joke, I get to do what I've wanted to do for a long ass time. I get to help make a Nintendo game!

Here is a sketch I did some time back hashing out the idea of a mine cart level, the squares representing graphic tiles:

http://home.roadrunner.com/%7Esaucisse/DPcomics/minecartride.gif

And here's a preliminary box design, incomplete:

http://home.roadrunner.com/%7Esaucisse/DPcomics/boxthumb.jpg

[thom_m]

If this is indeed some sort of asshattery, they seem to be putting a lot of time and detail into it just for the sake of being known as supreme smartasses.

And, let's face it, if it is indeed the case, supreme smartasses they'll be.

But, for now, I do believe it's a real homebrew - the first one I'll actually bring myself to deal with all the importing annoyances and buy.

[PapaStu]

Guys, if this was April Fools, it would have run its course on April 1, not May 12th and beyond.

It is real as real can be. Not to mention the fact that this stuff has come out away from the Bio Force Ape thread because that thread is seen as pure joke vs. this thread, which is pure serious.


I can't wait to pre-order my copy.

And Brat, seeing that cover in color does wonders for it. I wasn't sure about the line art alone. Now i'm sold.

[cyberfluxor]

Intense.

[Tupin]

Glad to see that someone decided an actual game was needed. My only complaint is the hit detection; you hit the air above the enemy and it dies.

Of course, that's probably intentional, isn't it? LOL

That said, I can't wait.

[ProgrammingAce]

Glad to see that someone decided an actual game was needed. My only complaint is the hit detection; you hit the air above the enemy and it dies.

Of course, that's probably intentional, isn't it? LOL

That said, I can't wait.

That's something of a technical limitation, let me see if i can explain.

To the NES, a sprite is a 8x8 pixel tile. In order to make the characters in Bio Force Ape, they're made up of groups of tiles. The ape is 2 tiles wide by 4 tiles tall.

The NES has a limitation of 8 sprites per horizontal scan line (each scan line on the TV). After the 8th sprite, the system just stops displaying them.

So in order to fit more enemies on the screen, we decided to make a short enemy that's only 1 tile wide. The little squid thing is 1 tile wide and 2 tiles tall.

So when all the enemies are on the screen at once and the ape is just standing there, the tiles go like this:

2 tiles for the ape
3 tiles for the Ant dude
2 tiles for the lizard.
------
7 tiles

When the ape punches, he becomes 3 tiles wide, maxing out the number of tiles we can have on a scanline. Luckily the ant dude is only 3 tiles wide at the top and 2 tiles wide at his feet. So the end result is the squid thing that's only 2 tiles high.

Now why can't we have a kicking animation? There are a couple of reasons. First, same as above, there's a good chance that unless we've killed something else on the screen first, we already have 8 tiles on the scanline. We don't have anything left to draw a kick. The second issue is that we're quite frankly almost out of tiles for our sprites. It would suck to have to cut one of the enemies just to add a kick attack just to handle a single enemy. Now the other issue is that we've already mapped Down + B (Attack) to the special attack. The only other button combination that makes any sense is Down + A (jump). But that needlessly complicates the controls and isn't very intuitive. You're just as likely to forget that a downward kick isn't Down + Attack and use up your special attack.

We can't remap the special attack because "paulB" already said that's the button sequence to use the fart attack. We're trying to stick to the hoax description as much as possible unless it's detrimental to gameplay. Obviously we're going well beyond what's been referenced by that thread, but we're sticking to it when we can.

So the end result is that you punch over the squid's head when you go to kill him. To make up for it, i extended the hit box for that enemy so he's easier to punch. One of the problems in early testing was that he could get too close and be really hard to hit. I'm going to tweak the hit boxes before the game ships though and review all of the enemies.

[hellfire]

you better put dur butter somewhere in the game, even if its in the credits. IF dur butter iz not in the game I will not buy it

[walrusmonger]

Soooo amazing, can't wait to buy one!

[ProgrammingAce]

you better put dur butter somewhere in the game, even if its in the credits. IF dur butter iz not in the game I will not buy it

Ja he is dur butter and he is worth 2k monies.

You can't honestly expect us to leave him out. Hell, he even has his own copyright notice.

The... er... special attack... is also in the game as well. Actually, both features were in the game prior to the release of the demo and had to be cut from the code before we released it. We didn't want people poking around with a game genie and giving away all of our secrets.

[kainemaxwell]

Looks awesome so far. Be sure to test it with a Game genie and GenNEXT also.

[PapaStu]

Looks awesome so far. Be sure to test it with a Game genie and GenNEXT also.


This should only be played on a real NES. Not being played on a NES will just make the game dump its save and delete its rom.

[ProgrammingAce]

I guess now would be a good time to explain one of the inside jokes you'll see in the game, since i just finished up that section. Something the size and scope of Bio Force Ape is going to eat up a lot of free time for everyone involved. Right now, the source code for the game is sitting at just over 10,000 lines of code, and we still have plenty more to add.

As Brat and I are working on the plot, i decide it would be funny to fit my fiancee into the story somehow. The original plan was to make her the wife that John is trying to rescue. As the story progressed and we ran into some technical issues, it became apparent that wasn't such a good idea. Without giving anything away, you'll probably see why when you play the finished game. So I just scrapped the idea of having her in the game.

Later on, as we were working on one of the levels half way though the game, we realized we needed another boss character. Out of the blue, Brat offers to make a pterodactyl boss. I stare at the email for a few seconds and suddenly a lightbulb goes off in my head... See, my fiancee's name is Terri. So from there, the Terri-Dactyl was born.

BEWARE THE TERRI DACTYL

[Bratwurst]

When I want to make graphics with lots of detail, like a portrait for a cutscene, I find it easiest to draw big and then shrink the image down. This is probably cheating, but I don't care.

http://home.roadrunner.com/%7Esaucisse/DPcomics/apeface1.gif

Here's a quick and ugly sketch of Mr. Ape. He has seen better days.

http://home.roadrunner.com/%7Esaucisse/DPcomics/apeface2.gif

Resized, and in need of cleaning up. This is basically for me to get a general idea of proportions.

http://home.roadrunner.com/%7Esaucisse/DPcomics/apeface3.gif

Finished product, ready for packaging and subsequent reheating to stuff down your throat.

[Ed Oscuro]

ima sic the pixel art peoples on you

so they can cry when they see resizing works

IT'S SETASTIC! Hoping for some Musya cameo though. Evil jumping Boddhavistas for the win. You know this game wants some random decrepit shrine stage, you know it.

Holy Butter, can't wait to preorder like five copies. You know I will (well, obviously I imagine the plan is to get them out to as many people as possible, instead of speculators, but yeah, I'm stoked, especially knowing that the demo was just meant to be silly and not 100% GAEM QUALITY).

p.s. if you put some cheetahmen II mixes in there the Japanese retroscene will be all over this too. ;)

[whiskeyvengeance]

I'm stoked! I just hope this doesn't suffer the same fate as the much-fabled Neotoxin...

[ProgrammingAce]

I'm stoked, especially knowing that the demo was just meant to be silly and not 100% GAEM QUALITY).


Well, I had hoped it was pretty evident from the demo that we were going for a tongue-in-cheek parody, i think some of that may get lost when you realize a lot of NES games really did have shitty translations and ridiculous stories.

One of the goals in the game is to duplicate the original hoax as closely as possible, but without using some ridiculous mappers, we're not going to be exact. The bigger and more important goal is to make sure the game is actually fun. I can't ask you to pay for a game that isn't worth the price. We're not going to use the fact it's an NES game as a cop out.

I'm fairly confident that aside from some content issues, this game could have been sold at retail back in the 80s. The only thing that really would have held it back is the "bio force attack" special move... i don't think that would have made it past the censors. Don't get me wrong, it's a side scrolling beat-em-up, it's not Mario 3 or Final Fantasy. But if i didn't think the game were fun, i wouldn't have made it.


I'm stoked! I just hope this doesn't suffer the same fate as the much-fabled Neotoxin...

Right now the game is playable from beginning to end. There are a few additions we still need to do, plus some polish and bug fixes. If i were to be hit by a bus tomorrow, Brat would still have something to put on a cart and call Bio Force Ape.

[Ed Oscuro]

I'm fairly confident that aside from some content issues
Better go full-tilt and put the girl turns into a tanuki scene from Musya then.

[whiskeyvengeance]

Right now the game is playable from beginning to end. There are a few additions we still need to do, plus some polish and bug fixes. If i were to be hit by a bus tomorrow, Brat would still have something to put on a cart and call Bio Force Ape.

I think it's amazing that you guys have been able to construct a more or less complete game this quickly. Correct me if I'm wrong, but won't Bio Force Ape be the first full-length NES title since Nintendo stopped supporting the system
back in the 90's?

P.S. I'm gonna feel really stupid if this turns out to be another elaborate hoax.

[ProgrammingAce]

I think it's amazing that you guys have been able to construct a more or less complete game this quickly. Correct me if I'm wrong, but won't Bio Force Ape be the first full-length NES title since Nintendo stopped supporting the system
back in the 90's?

P.S. I'm gonna feel really stupid if this turns out to be another elaborate hoax.

I'm not sure on this, to be honest i'm not well versed with the NES homebrew scene. I guess it comes down to what you would call a "complete game".

I've looked through all of the documents on nesdev, and unless i'm missing something, this is probably the first game with a plot, levels, bosses and cutscenes of any real length. I would hesitate to call it the first "complete" game though.

Someone with more experience in the NES scene may want to chime in. Before this project started, I quite frankly haven't sat down and played on an NES since the 80's.

So an update on the game, it's sitting at about 11,000 lines of code, up from 8,700 when i started this thread. Those numbers don't include the background designs (stored as maps in the rom) or sound files.

And now to bore you with some technical details. Someone asked me about compression and why we can't use that to store more artwork in the game. The answer comes down to how the NES stores the graphics tiles. The quick answer is that it's already compressed to hell. Let me explain:

If you look at the artwork that Brat has posted, you'll notice some of it is in really weird colors. That's a representation of how the NES stores graphics tiles in the CHR rom. Because ROM was expensive back then, Nintendo really cut down on what the programmers could use (and i'll give other examples of cut corners in later posts). For the CHR ROM, you get two 4K banks. One stores the background tiles and the other stores the sprite tiles.

Each of these 4K banks can be represented as a 128x128 pixel grid, and that's how we do represent them when we're messing around in photoshop. Now when you look at this grid, you'll see it only has 4 colors, black, red, blue and white. Because there are only 4 colors, each color can be represented by just 2 characters in binary, 00, 01, 10, 11. Since a byte is made up of 8 binary characters, a single byte can hold 4 pixels worth of data when stored in the NES CHR ROM.

In case i lost you, let me try to demonstrate. If the first byte of the CHR ROM is 11010010, then the first pixel is the 4th color (11), the second pixel is the 2nd color (01), the third pixel is the 1st color (00), and the fourth pixel is the 3rd color (10).

While this compresses the data in half, it creates an obvious problem. You can only have 4 colors in your game.And, well... that would suck. It's also pretty obvious that most NES games have more then 4 colors, so there must be something else going on.

So in the next installment, i'll explain how games get their color, the limitations of this system and why it sucks. As an extra bonus, you'll see why the screenshots from grand theftendo show why the game never existed...

[ProgrammingAce]

Ok, so in the last episode you saw how the NES stores data in the CHR ROM (graphics rom chip). You saw how the ROM chip only stores enough data for 4 colors. So how do you get different colors out of the system?

The answer is by using color palettes. The NES allows you to set 4 different 4-color palettes to be used at a time. This should allow you 16 colors at a time, but remember how i said Nintendo went cheap on RAM? It hits us again here. So if i were to describe the first color palette as Black, Red, Brown, and Yellow those would be the colors that make up palette 1 (yes, redundant sentence is redundant, but stick with me here). Now because Ninty cheaped out on RAM, the first color in each of the other 3 palettes *must* be black. The first color in each of the 4 palettes must be identical, it's considered the "background color". In Mario games, for example, that color is usually the sky.

This limitation of RAM means that the NES can only display 13 colors for background tiles on any given screen. Sprites have their own palettes with a similar limitation, but have their own colors.

But that still doesn't explain how the color palettes get assigned to the background tiles. That's where you have something called the "Attribute Table", and once more Nintendo went cheap on RAM. Unfortunately this is also the most complicated part of the NES architecture. If you can follow along with me here, you'll have no trouble understanding how the NES works.

Nintendo only set aside 64 bytes of RAM for the attribute table. Since there are only 4 palettes available per screen, you can represent each palette with 2 characters (bits). Again, there are 8 bits to a byte, so you can represent 4 "areas" with each byte of RAM. With 4 areas per byte and 64 bytes to work with, you can set the palette 256 times across the NES scree. So if you divide that by the NES' resolution, that means that each definable area makes up a 16 x 16 pixel area on the screen.

I hope you're still following along. (i'm going to get a bunch of tl;dr's after this)

So what that means in practical terms is that each 16x16 area in the background *must* share a palette of 4 colors (3 if you discard the background color). To give you an idea of the size, this is the same size as one of the question mark boxes in the Mario games.

How does this play into Grand Theftendo? I'm colorblind, so i can't tell if the screenshots abide by the 13 color limit, but it certainly doesn't abide by the 16x16 grid layout for the background palettes. There are a few other problems with the screenshots, mostly involving how the game's sprites are arranged. The NES does not have sprite rotation, what you draw is what you get. If you look at the screenshots, there are cars twisted every which way. While it's possible to store all of those rotations in the CHR ROM, no programmer would ever do it because it's a huge waste of space.

[OdSquad64]

I'm pretty excited about this game. I haven't played my NES in a while, but this thread has definitely given me the itch again. I'm also really enjoying reading about the making of this game and the little incites into programming for the NES and the NES hardware limitations. Keep up the good work guys, I can't wait. Might I suggest a DP seal of approval on the box?

[ProgrammingAce]

When you're making a game, you'll end up having to make certain choices when it comes to content. These choices are usually due to either space, schedule, or budget. Being two dudes making an NES game in our free time, schedule never really comes into play. Budget was an issue in initial planning, it really set the mappers we could use to design the game. As much as we would love to use every advanced feature in the NES, we would have to destroy copies of Castlevania III to do it. When it comes to the NES, space really becomes the largest limitation

To show some of the choices we've had to make, below is an email from myself to Brat. Before anyone becomes concerned that we're gimping the background design, understand that I fully expect that we're going to use the full palette colors. If somehow push really comes to shove and we have to limit the colors on a few of the screens, Brat has already proven that he can draw some really cool backgrounds using only 4 colors.


I've been thinking about the backgrounds...

I assume for the concept art, you've been tiling them in photoshop (or something). That's probably more work then it needs to be, i can work just as well using a sketch like this:

http://picasaweb.google.com/h4ckur/PhonePics#5341000607952104306

And that's a really poor quality example, but i can work with it. Just tell me which tiles go with what number.

As for the colors of the background, that becomes a little tougher. If we want to use more then 4 colors per screen i'm going to have to assemble the tables by hand. It's not hard to do, it's just time consuming. Here's how it works:

You have 4 palettes per screen: 00, 01, 10, and 11. If the first 4 tiles use palettes 00, 00, 01, 10, then the first byte of the table would just be those numbers put together 00000110. Then i would convert that back to base 10, so it equals 6. So 6 would be the first entry in the table.

Now i just do it 63 more times per screen. Like i said, it's not hard but it takes some time. I'd certainly like to do it though because it adds a lot more to the backgrounds.

The only real problem is size. A background is setup by a grid of 224 bytes. Each byte describes a meta-tile of 2x2 tiles. Add in the 64 bytes for each attribute table and we're at 288 bytes per background (plus some extra to define each tile). We have about 9k of space left in the rom (from a total of 32K). If we set aside 3K of space for backgrounds, we can fit in 10 different background designs using 4 color palettes. If we were to limit the backgrounds to 4 colors, we could fit 15 backgrounds in the same amount of space.

The wild card is the compression scheme i came up with to reduce the size of the backgrounds. It's a very simple compression, but it doesn't take up much code to execute. I could do better compression, but that takes more code and more CPU time. If the decompression code takes up more space then it saves, it doesn't do us any good.

- Ace

[Gentlegamer]

we would have to destroy copies of Castlevania IIIThat would be a crime against humanity.

[MachineGex]

I probably will get killed for this, but if you are only going to make 100 or so new games, killing a few Castlevania's would be worth it. Gotta be over 1,000,000 Castlevania 3 carts, I don't think taking 50 or 100(to make a new game) would even make a dent.

Not that anyone would ever do it. But I personally dont see it being such a huge crime against the gaming commmunity that some think it is.

Back on topic, thanks for the updates! I really admire anyone who can do what your guys are doing. Keep up the hard work and the updates!

[Gentlegamer]

I probably will get killed for this, but if you are only going to make 100 or so new games, killing a few Castlevania's would be worth it. Gotta be over 1,000,000 Castlevania 3 carts, I don't think taking 50 or 100(to make a new game) would even make a dent.

Not that anyone would ever do it. But I personally dont see it being such a huge crime against the gaming commmunity that some think it is.

Back on topic, thanks for the updates! I really admire anyone who can do what your guys are doing. Keep up the hard work and the updates!Where do you live so we can kill you.

[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.

http://programmingace.com/images/BioForceApe/meta-tiles.jpg

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:

http://programmingace.com/images/BioForceApe/backgroundsample.jpg

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 (http://tilestudio.sourceforge.net/). 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

http://programmingace.com/meta-tiles.jpg

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 (http://www.nesicide.com/)? It's an IDE for NES development. Might help here. Again, Windows-only, but Wine might help.

[ProgrammingAce]

Have you checked out Nesicide (http://www.nesicide.com/)? 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/BioForceApe/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:
http://cinematicbazaar.com/wp-content/uploads/2009/08/wpid-12515139319262.jpg

[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!

[Blitzwing256]

I needed that health :C

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

the game has unicron's? how can you even fit one into the memory of a nes

this game must be trully epic ;-)

[udisi]

wow, I totally missed this, I thought ProgAce may have been working on this, but it appears it's almost done. Very Cool. There's actually suppose to be a few good nes homebrews completed this year. The last 2 or so years for Nes Homebrew have been great. Not a whole lots of side scroller/platform games yet, but there's been some really nice puzzle games, single screen classic arcade type games. D Pad hero hasn't seen an official cart release but is available in rom form and is an amazing piece of work for a nes game.

Very happy to see more new NES homebrew.

[ProgrammingAce]

I needed that health :C


That's certainly possible, the mine cart level is rather difficult. Normally the ape has a max health of 8. He can be hit 8 times before he dies (when he gets down to 2 health, he starts blinking red. You can see this in the demo).

We went in kind of an interesting direction with health packs. You don't get the health bonus when you pick it up, you get to choose when you get the health bonus. This allowed us more flexibility when placing the bonuses. I hate picking up a health pack when my health is already full. Unfortunately you can't apply the health bonus during the mine cart level. So if you go in with low health and get knocked around, you'll die.

As a temporary solution while designing the level, i put in some code to boost the ape's health up to 10 regardless of how hurt he was going in. But that's not a very good solution to the problem.

What i have in the back of my mind, i may save the player's health level before going into the minecart level, boost the health back up to 8, then reset it back to the initial value when you load the next level. Or i may just leave it as is. If you go into the level with 1 health, sucks to be you.

I'm going to want to watch some people play through the game in playtesting before i make a decision on that.

And another page knocked off my bug list. I'm still tracking some bugs, and i'm sure there's a few i'm still missing.

http://cinematicbazaar.com/wp-content/uploads/2009/08/wpid-1251763907805.jpg

[MachineGex]

I am so glad to see an update. I know how much work this kind of project can take up and was getting worried that real life might have gotten in the way of finishing. Keep up the good work and thanks for the updates!

[darkslime]

I am so glad to see an update. I know how much work this kind of project can take up and was getting worried that real life might have gotten in the way of finishing. Keep up the good work and thanks for the updates!Basically what he said. I was curious on what was happening with this game. It looks great, keep going and I will definitely buy a cart!

[tomaitheous]

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/BioForceApe/nesmus.html

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


Hey, that looks just like BASIC play syntax. No duty cycle modes though? No hardware volume envelopes (simple linear decay) on the square channels or hardware frequency sweeps either? Both could be easily implemented in a single byte command.


Your game is expected to run at 30 frames per second and update the music loop once per frame.

Curious too (since I've been doing a lot of sound synth code in the past year), the music engine note and tempo are running off a 30hz tick? Why not 60hz? Even 60hz is kinda low for fixed pointed tempo (assuming you're using a fixed point counter), but much nicer than 30hz.

Do you have an external converter to convert the ascii text into command bytes?

[Ed Oscuro]

You don't get the health bonus when you pick it up, you get to choose when you get the health bonus.
YES

Beyond that, nothing much I can comment on. Keep up the good work!

[ProgrammingAce]

Curious too (since I've been doing a lot of sound synth code in the past year), the music engine note and tempo are running off a 30hz tick? Why not 60hz? Even 60hz is kinda low for fixed pointed tempo (assuming you're using a fixed point counter), but much nicer than 30hz.

Do you have an external converter to convert the ascii text into command bytes?

The NES is locked at 30 FPS on the sound channels. I can only buffer sound in between screen refreshes, so i'm stuck there.

The hardware doesn't really allow for sweeps or fades. Fades you can kind of fake by manually playing the note at a progressively lower volume, but sweeps can't really be faked. You can pull something similar off by layering the sound channels, but i haven't really tried. The NES doesn't let you play a second note without a rest in the middle, that's why NES music is always so staccato.

[tomaitheous]

The NES is locked at 30 FPS on the sound channels. I can only buffer sound in between screen refreshes, so i'm stuck there.

You mean, your code/engine is locked down to 30fps? The sound channels aren't locked to anything. You can update any of the APU registers at any time. Most engines sync the sound engine code to vblank, which is still 60fps (50 for PAL). Using an external interrupt from some mappers, you can create some interesting sounds via high speed updates.


The hardware doesn't really allow for sweeps or fades. Fades you can kind of fake by manually playing the note at a progressively lower volume, but sweeps can't really be faked. You can pull something similar off by layering the sound channels, but i haven't really tried.

It allows for sweeps(repeat), fades(decay envelope), or manual volume. All are hardware supported. Volume envelopes are as simple as writing the length variable. The decay is handled in hardware and the envelope tick is 240hz. Doing it manually with direct volume control isn't faking it though. Manual volume control offers the composer to do more complex envelopes like ADSR or echo effects or tremolo (low frequency volume modulation).

But my original point was that you could easily support duty cycles or volume decay in your existing engine without writing more complex code. Just add two more commands which directly translate to the hardware. A decay command with a length counter parameter and a waveform command with a duty cycle parameter. Same with sweep - although you can't use sweep and decay at the same time. It's one or the other. Anyway, in relation it would give a little more flexibility in sound with little effort on the code side.


The NES doesn't let you play a second note without a rest in the middle, that's why NES music is always so staccato.

You mean poly voice per channel? Neither did the Genesis, PCE, SNES, etc. A more complex sound driver resolves most of this issue though. Or do you mean actual forced rest periods in between notes? That isn't true. You can adjust the frequency of the channel to whatever value without stopping the channel output.


If you don't mind me asking, what mapper are you using? Are you going to add horizontal scrolling to the engine? If you do, I highly recommend using the +32 increment option for the PPU. Much easier to write vertical strips than trying to seek metatile positions in horizontal strip map format. You can still do RLE on vertical strips. Any newer demos or videos available?

[ProgrammingAce]

To be perfectly honest, you've completely lost me. What you wrote is way over my head, i barely understand how sound generation works.

All i did was write a music engine that takes a binary file with the "music" in it and shoves it into the right memory register to make it play sound.

As for the mapper, we decided not to use one. Leaving out a mapper gave us a few more options when producing the final carts. Only 1 level has horizontal scrolling, the rest are static. Since we're not using a mapper, we can't swap the PPU increment on the fly, so everything is just +1.

I don't think we'll be doing any more demos, but will have some videos later on. Right now the background graphics aren't all in place.

[tomaitheous]

To be perfectly honest, you've completely lost me. What you wrote is way over my head, i barely understand how sound generation works.

All i did was write a music engine that takes a binary file with the "music" in it and shoves it into the right memory register to make it play sound.


Oh.. sorry about that ^^; Was just trying to explain that duty cycle and volume envelope would be pretty easy to implement in your existing sound engine. Just simple as passing those values to the right regs.



As for the mapper, we decided not to use one. Leaving out a mapper gave us a few more options when producing the final carts. Only 1 level has horizontal scrolling, the rest are static. Since we're not using a mapper, we can't swap the PPU increment on the fly, so everything is just +1.

I don't think we'll be doing any more demos, but will have some videos later on. Right now the background graphics aren't all in place.

Hmm.. non mapper setup. That's rough trying to fit all the graphics into two pattern blocks (4k+4k) for chr-rom. Since you're already using extended ram at $6000, why not use chr-ram too? You could fit more graphics in (like cinemas). I mean, you have 32k of non mapper PRG rom to store stuff in. Oh and you don't need a mapper to use use PPU +32 increment. It's on register $2000. But if you're not going to do scrolling, then not a big deal. Are you going to manufacture the boards yourself (i.e. not use the power pak cart or recycle old carts)? If you plan to recycle a cart, SMB/DH combo cart has a decent mapper. Allows 16k of chr-rom and 64k of prg-rom. And there's got to be a bazillion of them out there. ;)

[dao2]

i think i understood the first 3 words in your posts :P

man u seem really knowledgeable about that stuff :o did program for it before or somethin o_0

[ProgrammingAce]

Hmm.. non mapper setup. That's rough trying to fit all the graphics into two pattern blocks (4k+4k) for chr-rom. Since you're already using extended ram at $6000, why not use chr-ram too? You could fit more graphics in (like cinemas). I mean, you have 32k of non mapper PRG rom to store stuff in. Oh and you don't need a mapper to use use PPU +32 increment. It's on register $2000. But if you're not going to do scrolling, then not a big deal. Are you going to manufacture the boards yourself (i.e. not use the power pak cart or recycle old carts)? If you plan to recycle a cart, SMB/DH combo cart has a decent mapper. Allows 16k of chr-rom and 64k of prg-rom. And there's got to be a bazillion of them out there. ;)

The PRG rom is getting pretty full too, we're sitting at just over 12,000 lines of assembly to make this game work, I have about 6.5 K of space left in the rom and i haven't put the meta-tile data into the rom yet. Basically, it's going to be a tight fit. I have enough features on my "wish list" to fill up every last byte.

We've been super efficient in our use of the CHR rom, we've managed to fit every graphic we wanted into the two 4K banks, i think we still have 5-6 tiles left blank too. We even went with "oversized" graphics compared to most NES games, the ape is made up of 8 tiles and has 9 frames of animation. A relatively unheard of number for an NES game. I'd really love to show you what the CHR rom looks like, but i don't want to ruin any surprises.

We certainly didn't skimp on the graphics in other areas either, the game has 14 different fully animated characters. Plus there's projectiles, cutscene graphics, and a few "extra" things thrown in there. Once the game is out, i'd love to sit down with Brat and go over how we managed to squeeze everything into a 128 x 128 pixel area. Quite frankly, Brat was amazing in his art design in coming up with creative reuses in tiles. The steps to assembling some of these characters is quite complex.

As for the 32 vs 1 increment of the PPU addresses, i misspoke. I was under the impression that there were some mappers out there that would allow you to change the register on the fly after the code was launched, that's all i meant.

For the final carts, we're doing a full boxed release. I have a friend who's producing the carts for us, i believe he's using donor carts.

I'll be honest here, what the lack of mapper really comes down to is my lack of knowledge when this project started. Before this, i hadn't written in 68K assembly in 10 years. I had never written a line of code for the NES and i didn't understand how all the registers worked, i didn't understand the PPU at all, and i had no idea what i was doing. The original idea was to keep the game as limited as possible so i didn't fuck it up. So i made a quick crappy demo of the ape sliding across the screen and shoehorned Brat into helping me out.

As the game progressed, we realized we actually wanted to do this the right way, actually make a fun and interesting game. In the process, i've rewritten the game engine 4 times. I have about 500 hours into the project, and while i always wish i could add more, i'm pretty happy with what we have so far. Of course there are things I would have liked to have done differently, i would have preferred the game to be side-scrolling, i *definitely* would have loved to use a mapper... Now that the game is basically done, I can't go back and make those things happen. It would take a complete rewrite of the game, delaying the release by another year, possibly killing the project all together.

In order to optimize the code and make it as efficient as possible, I had to hard-code a lot of information. Normally it's poor programming practice, but when i'm counting each calculation for number of CPU cycles, it's a necessary evil.

A perfect example... when i originally wrote the game, i just picked a random spot on the screen to be the ground height, I just made sure it was divisible by 8. It worked fine until i realized i was 4 pixels off from the attribute table and my colors weren't going to match with the background tiles. My only option was to shift the backgrounds up by 4 pixels, which leaves the ape's feet 4 pixels below "ground". When i did conditional statements ( if x > y then do this ) I couldn't use a calculation. So i could either waste more CPU calculations to calculate how high the enemy's head was from the ground, or i could just hard code it. Of course i hard coded it, and adjusting the ground height now crashes the game. Going through 12,000 lines of assembly code digging out variables i didn't bother to mark without access to a debugger would be a nightmare. Instead we're going to adjust the artwork to match the ground height, and nobody would ever know if i didn't say anything here.

This kind of stuff comes up a lot in video game development. Is it faster/cheaper to change the artwork or the code? In this case, the artwork by a landslide. It makes no difference to the player either way...

[tomaitheous]

We've been super efficient in our use of the CHR rom, we've managed to fit every graphic we wanted into the two 4K banks, i think we still have 5-6 tiles left blank too. We even went with "oversized" graphics compared to most NES games, the ape is made up of 8 tiles and has 9 frames of animation. A relatively unheard of number for an NES game. I'd really love to show you what the CHR rom looks like, but i don't want to ruin any surprises.

So no cinemas pics then? Like in the fake thread?




For the final carts, we're doing a full boxed release. I have a friend who's producing the carts for us, i believe he's using donor carts.

From the demo you released, I see that the rom has extra SRAM (mapped to cpu logical address range) enabled but you're not using it. I take it the final game engine doesn't use it? If not, like I said previously - SMB/Duck Hunt combo cart would work (and has a super easy mapper on the board if you wanted/needed up to twice the chr/prg rom space). Even if you don't use the extra space, the cart is a candidate :)

Best of luck. Hope to see this final version soon. :)





i think i understood the first 3 words in your posts :P

man u seem really knowledgeable about that stuff :o did program for it before or somethin o_0

Me? I code for a few consoles ;)

[ProgrammingAce]

So no cinemas pics then? Like in the fake thread?


There are, but they're not quite as big and there aren't as many.




From the demo you released, I see that the rom has extra SRAM (mapped to cpu logical address range) enabled but you're not using it. I take it the final game engine doesn't use it? If not, like I said previously - SMB/Duck Hunt combo cart would work (and has a super easy mapper on the board if you wanted/needed up to twice the chr/prg rom space). Even if you don't use the extra space, the cart is a candidate :)


The game was far beyond what the demo showed, even when it was created. We ended up cutting several thousand lines of code and blanking out half of the CHR rom for the demo. We didn't want people hacking the rom and getting to other levels. The final game uses the entire addressable range. all 4 banks of PRG rom.