Indivisible on NES (Playable ROM inside/Image Heavy)

Ever since the April Fool's Skullgals mockups were released, I wanted to try to make that somehow. But what I know best is NES, and it would not have been very fun to do there. (Insert technical reasons here.) I did some graphics for it before deciding it'd be too time consuming. I'd considered just learning to program for Neo Geo to see if it was easier or even possible there, but nothing specific ever pushed me from, "Cool idea" to "I'm making this."

Then the Indivisible Prototype came out, and I decided I want to demake that for NES. I started to make some graphics for it. NES hardware sprites are 8x8 pixels. There are four palettes containing three solid colors and transparency. Each hardware sprite can use the three colors from one of those palettes.

What most people today would call a sprite is actually several hardware sprites. I made this image some time ago to demonstrate how 5 color sprites like Mega Man work:

This technique is called sprite overlaying. There's one additional restriction to keep in mind. There can only be 64 hardware sprites on screen at one time.

Here are some graphics I made way back in August.

I was trying to minimize sprite count for the very early versions. I was worried about the sprite overlays using many more hardware sprites than I generally expect. Later, I still tried to keep the sprite small, but focused quite a lot on keeping her scowl. The two dot for eyes thing didn't give me the right feel, but none of these really look like Ajna either. At this point, I quit. "Cool idea", but not, "I'm making this."

Then I learned Mike Z was going to NEC. I've gone to the last two NECs. They're mad close to me and fun. I thought it'd be cool to show him in person if I got a chance, and if not... I'd post it on Skullheart like I'm doing now and still have fun at NEC. (I did end up getting the chance, and it was pretty cool! I might write more on that elsewhere.) This gave me a deadline, and a reason to do it. This was probably very early October. There was something really hard I had to finish on another project, and then this would be a really cool quick thing while I took a break from that first project.

Then a bunch of stupid life stuff hits me. It's November 19th and I haven't even really started. I start to create the sprite I actually want to use, and end up with these:

The one of the left has academic appeal. It's 16x32 pixels (excluding the stuck out hair), the same size as big Mario in Super Mario Bros. I decided I could spare the extra two sprites for the better proportions on the right. However I still wasn't done with the really hard thing on the other project, so this went on hold again.

I finish the hard thing. It's December 5th. NEC's like a week away. The only thing I have done is a single idle frame. I sent an action plan to someone I talked with about this.

My plan is:
1. All general movement animation. Running, wall jump, axe swing, airborne axe swing.
2. Maybe non essential movement animation. Crouching, punching the air, airborne punching the air.
3. Break up metasprites into sprites and arrange them into CHR.
4. Animate the character in game.
5. Remake the title screen scene.
6. Make tileset for the temple.
7. Make that collision enabled and scroll-enabled.
8. Enemy Animation. At least... one of 'em.
9. More...?????????????

Writing all that out, yeah I'm not getting as far as I want. But the steps are laid out so that there's something cool no matter when I stop.
...
I only need to get to step 5 for it to be cool. Step 7 is gravy. Assuming each step takes a day, I'm in there for the title screen.

Keeping in mind the goal was to have something to show, I animated everything first. In the worst case that that took the entire week, it would still count as cool fan art. The only "non essential" animation I did was standing axe swing. It contributed nothing "real" to what I thought I could get done, since there's nothing to chop. Jumping axe swing was essential since it's used for hanging and climbing. I did it so that pressing B while standing would do something, given that pressing B in the air does. Someone who saw this at NEC asked me why I didn't do crouching (and the awesome crouch dance). It would have added a crouch frame, plus a crouching axe swing to the list of things to animate.

I had finished all the animations by the 8th. But I still needed to turn all of my animation frames into the 8x8 hardware sprites the NES recognizes. This is what "Break up metasprites into sprites and arrange them into CHR." means. The process looks a bit like this:

This may seem easily automated, but things like sprite overlays and frames being offset makes the naive approach not work. If I start at the top left and grab 8x8 blocks, different head sprites would be created for the hair-stuck-up and hair-stuck-down running frames. The pixel of higher hair would push the rest of the head down, so all hardware sprites in those hair-stuck-up frames would be offset one pixel from the hair-stuck-down frames. This would mean they're different, and couldn't be merged.

I figured I couldn't write a tool faster than I could do it manually. The end result looked like this:

The above contains a couple of duplicate sprites. But NES Screen Tool can easily remove duplicates once things are broken down into 8x8 hardware sprites. I also totally missed a required tile somehow, so I had to add it later. (Downsides of doing it manually.) This took a fair amount of time, since everything else is not as easy as the heads which were designed to be repeated.

So now I've got some graphics in the format NES understands. But it also needs to know where to draw the hardware sprites relative to each other to make up our actual frames. Creating this information is a bit like doing the reverse of the previous step:

This is something that would have been easier to automate, but again, I wasn't sure I'd have the time. So I did it manually. NES hardware sprites can be flipped horizontally and vertically. So at the end you can see I used a sprite normally used for her hair to get just one extra pixel for her footwear.

After that I was finally able to write a tool. NES Screen Tool can export the relevant offsets and hardware sprite numbers used to make up each frame (see the numbers in the gif above), but it exports for C. Indivisible NES is written in 6502 assembly, so this exporting is sort of useless to me. (I also have to edit the output slightly, and it's not as easy for me to parse human readable things as it is to parse raw data.)

So I took a look at the source code of NES Screen Tool and found that it saved this data in blocks of fixed sizes for each frame. No compression or anything. So I wrote a program to read the saved files rather than the exported ones (while offsetting everything so there was never a negative offset which makes something else a little harder), and got my own output that I feed to the assembler.

Early in the morning on December 10th, I wrote my first code for the actual ROM. I began with some defines for how to create and manage objects, using rules I developed for another project. Within a few hours I had a rom that initializes the console, loads the palettes, and displays a single frame of my choosing from the NES Screen Tool data. At this point, I needed to begin to make Ajna move and be animated in game.

Long ago I bookmarked this post that describes Ajna's prototype movement. I scaled that data as a starting point. (value divided by Indivisible's resolution gives a ratio. Multiplied by the NES Screen Resolution should give me a scaled value I can use.) Those scaled values didn't feel quite right (I was later told they had changed some), so I ended up sort of fudging them trying to keep the theme that wall jump was the fastest movement, dash beats running, etc...

I cheated with acceleration and friction. Some things that are easy to do in C are hard to do in 6502. Like... if you're holding left, but you're moving right, apply deceleration. If you're holding nothing, apply friction. If you're holding left and moving left apply acceleration. Deceleration is usually higher than acceleration and friction, so you can stop on a dime, but don't accelerate too fast to control. It's a problem I have solved in something else, but the code is a mess... and this being time sensitive, I took the easiest route. Friction, acceleration and deceleration are the same.

Checking for max speeds is another somewhat tough problem in 6502 assembly but this was actually necessary to the feeling of the game. (It's tough because Indivisible allows you to travel above the "max speed" in a lot of conditions, as well as having a variable "max speed".) I soldiered through it.

By the end of December 10th I had a fair portion of the movement done for the game. NEC technically starts December 11th. I usually don't go the first day anyway, so I decided to take that extra day and go to bed.

The game looked like this at that point (more or less):


I had not yet put in the standing axe motion (again, I focused on essential things first), and she can't dash. There's also some hard-to-see frame offset issues. She's otherwise complete. One of the things I'm proud of is implementing a subroutine (function) for collision detection despite there not really being anything to check. Essentially it's "if point is outside screen, return collided, else return notcollided." This is what allows the Axe Climb to work in the above .gif, but it was also something I could easily hijack later when actual collision information was added to the rom. Yay foresight.

I'm zeroing in on at least getting the title screen done as planned. For Friday what's left is basically adding small things and drawing the Title Screen.

NES can use 256 unique background tiles to draw a background. (Without some tricks that I wouldn't have time to implement.) A background tile is 8x8, just like a hardware sprite. Also like sprites, the background has four palettes of three colors + transparent. The background is drawn with a solid color of your choosing, and then the tiles are drawn on top of that solid color. So in a way, it's like you have four palettes of four colors, but one color must be the same in every palette. However unlike sprites, the background tiles can only use one palette for every FOUR tiles (laid out in a 2x2 square.) There's an exception to that, but let's not talk about it.

I sketched this out:

I try to draw organically at first so things don't look blocky. You can see at the bottom my original plan for the palettes. I needed white and red for the logo, and tried to use a third color that could pair with white to draw the bridge to the temple. The universal color is the sky color. I worked a bit more trying incorporate the bridge with this plan:

At this point I've got an 16x16 grid on so I can make sure only one palette is used per 2x2 tiles. I'm still trying to keep it organic and not blocky, though. I made the palette for the starting rocks contain the bright tree color so the tree could slightly "run into" the rocks without breaking any rules.


At the point, time began breathing down my neck, so I started cheating and painting over actual textures from the game. (I'm so sorry... ;_;.) The palettes in this image are actually not possible on NES. There's not a color that appears in all four palettes.

Lots of texture cheating later, I end up with this:

I abandoned the idea of having a palette specifically for shrubbery, and instead decided to have some fake layers of faraway background. The darker blue in the palette also allowed me to have faded looking leaves for the big tree in the background. I'm happy enough with this image to see what the actual damage is tile wise.

It uses 308 tiles. (Potentially fewer, because Pyxel Edit which I use to draw tiles isn't sensitive to palettes.) Way too many. I spent some time editing it down to under 256. The reason I made the logo so small is because I knew it would use a whole bunch of unique tiles. But the rest wasn't helping either...

After I finished, I made it 4 colors which is how NES expects its tiles:

I wasn't entirely happy with the background, but I was out of time and still had to add collision info and dashing and other things to the actual ROM.

I added dashing, the standing axe animation and fixed some small random stuff. And I created collision info for the title screen, and added it to the game. (I did it in such a wasteful way, but it was after midnight. NEC was the same day at that point.)

It was good enough to show off. I was almost about to go to bed when...



I forgot to make her fall! The collision detection routine I created earlier did indeed allow me to easily add collision for the title screen. But because there used to not be any pits:

I never bothered to check the ground beneath her while standing.
At 4:19 AM the day I was going to show this, I fixed that.

It had a rushed background and one silly animation bug:

But I had to get sleep to not be a zombie for NEC. I made sure it worked on the actual console (which I had not done since the started the project >_>), and thankfully it ran without problems. I packed up my NES and went to bed.

And that is how I made a tiny Indivisible prototype on NES in about a week. Thanks for reading all that!

The version uploaded in the post is a little updated from the one shown at NEC. I fixed the animation bug (she just runs against the walls instead of switching to idle all the time), and cleaned up the background a little. Edit: Well, there's no longer a version in at the bottom of the post. RIP original Indivisible NES, 260 downloads.

(All dates/times are from the files created throughout the project. My memory's not that good. ;) )