Indivisible on NES (Playable ROM inside/Image Heavy)

[Kasumi]

I demade the Indivisible Prototype by Lab Zero Games on NES.

Get it here: https://kasumi.itch.io/indivisible
Edit: The link is right, I promise. itch.io is 404ing on it every now and then :(

This tweet shows a side by side:

https://twitter.com/x/status/903741052007395339

And this shows off some of the animation in the game:

https://twitter.com/x/status/903741941388644353

Spoiler: Original First Post

(Bad picture of it on real hardware)
It contains the movement things from Indivisible and not much else. It was made in a week more or less. Seriously, the .gif contains 100% of the content of the ROM. I guess you could call it "Interactive Fan Art", rather than a game.

Grab it at the bottom of the post. (For Mods: This isn't a hack or anything illegal, despite being a ROM. It's 100% original code.) It doesn't do anything fancy, so it should work in whatever emulator. But if you don't have one lying around, I recommend FCEUX.

Edit: Well, there's no longer a version in at the bottom of the post. RIP original Indivisible NES, 260 downloads.

A Button = Jump. (Facing a wall in the air will wall jump)
B Button = Swing axe. (Hold while in the air to attach to walls)
Left/Right = Move. Double tap to dash.


I probably won't work on it more. What follows is information about its development that may be interesting.

Spoiler: Long Making Of

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. ;) )

 

[chickenwithtie]

Super cute!!!

 

[missingno]

Saw this at NEC, hella awesome. Thanks for sharing all the behind the scenes details, I love reading this kind of stuff.

 

[Smile]

Wow, I can clearly see how much work you put on this. This is amazing! :D

 

[KaboomKid]

Hey Retro Ajna! Meet Retro Leilani:

Spoiler: Kind of

But yeah, great job on this, and for sharing your process while getting it to work on an NES. I guess it's way too soon to think about a full Indivisible retro spinoff, but it'd definitely be cute to see Ajna go on some old school mini adventures like this. I'd certainly rather play that than the Indivisible First-Person Shooter (Call of Iddhi)!

 

[Gamrdogg]

This is amazing.

 

[Kasumi]

Thanks all! This was a pretty fun project, and taught me how stressful a game jam might be.

I can't wait until Leilani's Island comes out for real. I've been following it for a while.

 

[Goodbye18000]

I'm amazed at how close this FEELS like Indivisible, in terms of speed and angles of jumps. That's insane! Real cool stuff, man.

 

[KaboomKid]

I can't wait until Leilani's Island comes out for real. I've been following it for a while.

Me too! That and Jack the Reaper are the two games I've been following most regularly over there. I can't believe some people actually thought Indivisible's Leilani was a ripoff though. How could anyone gloss over the leiomano toothsaw, among other major differences, in order to reach that conclusion? lol

Speaking of devlogs, have you posted about this fan project on any other sites? If you ever decide to continue working on it, that might be a cool way to keep spreading awareness about the game.

 

[SkullMan]

I just found this out today and this looks fantastic. I especially like how you showed how you made the sprites for Ajna in your first post.

 

[the_rpg_king]

Your creation for the NES version of Indivisible is well done! I never been this proud since the campaign is a success!

 

[Meow-Professor]

This is very interesting, actually. I'm not sure if you mentioned it in the OP somewhere, but I was wondering if you have any more plans for continuing this to some degree, or adding enemies? What's there is great, though.

 

[JinKazama'94]

I'm amazed at how close this FEELS like Indivisible, in terms of speed and angles of jumps. That's insane! Real cool stuff, man.

For 3 months of work, they put a lot of effort into physics and sprite work. The frames on Anja are surprisingly fluid, especially for NES.

 

[Kasumi]

@Goodbye18000 ;) I see you!

@KaboomKid: I hadn't really planned to post it anywhere else. The cool part for people who know nothing about Indivisible it that it's on NES, but there's only about 30 seconds worth of things to do. If there were more, other communities might find it more interesting, I think.

@Meow-Professor: It does say in the post that I probably wouldn't work on it more, but I'm starting to rethink that.

@Mc.Rad: 3 months of work in the actual prototype or this? All the animation/everything for this was only a week of work, except for one frame. (Standing idle was finished in November.) I had planned to do it for longer, but life got in the way.

(Do people like to be @'d? I realize it sends an alert by default if you're quoted. So it seems like if I respond but don't quote people might still like the opportunity for an alert. Let me know.)

Thanks for the kind words, everyone else.

My original plan was to at least have a temple to platform in, but once the surprise happened a big part of the drive to work on this went away. However, the reception to this has been pretty amazing, so I think I may try to fulfill that plan. I don't promise this, so definitely don't expect I will remake every aspect of the prototype. But know NES can basically handle all the game logic. The main issue would actually be getting 4 incarnations and enemies on screen at the same time with the 64 hardware sprite limit. But it is all... real work, and this was partially made only as a break from something else I'm working on.

 

[the_rpg_king]

What can I say, your work is actually like the real thing. I guess this could be an accolade...

 

[Kasumi]

So I am updating this, but there's a lot of other things I've had to do which is making progress slower than I hoped. I wanted it to be done like last week. It's mainly asset creation left now, but I'll not post any more info than that. I want the progress to be a surprise on release I guess.

 

[Kasumi]

In theory, I'm a programmer and an artist. But I guess the art part is slow.

So here's a tiny update:

The first making of post goes into it a bit, but getting graphics into an NES game isn't so easy when they're not just drawn in a rectangle. I wish, wish, wish I could just paste these frames in without having to break them into 8x8 sections, but that's not how it is. There's also a hard limit of 256 8x8 sections at once, which all of Ajna's animations alone will probably exceed. Extra stuff has to be done to overcome that. But that's a coding thing, and will actually be super easy. Currently, I'm just animating things.

It's taking all of my willpower not to post something cooler.

Edit: Upload crouch+uncrouch for a better loop. Previously it was just crouch.

 

[missingno]

But can she do the leftrightleftright crouch dance? This is the most important part.

 

[Broseidon Rex]

Sure that's great, but will she punch bats?

 

[Kasumi]

missingno: Are you sure you want such vital information spoiled?

Spoiler: No turning back!

Yes, she probably can.

Broseidon Rex: Of course...

not.

For those not in the know about Super Bat Puncher

 

[Kasumi]

Eh, one more sneak peek. Maybe this one gives away too much, I dunno. I'll say it's still not the cool thing I want to post.

Reached a pretty big milestone, so hopefully not too much longer before this is out.

 

[Kasumi]

I'm running out of reasons to keep this thing's development private.

This animation is actually pretty subject to change. I haven't checked if it's a reasonable number of sprites yet. The sprite limit has been hitting me very, very hard for this project. I could make a thing, but if it uses too many sprites, I have to remake it smaller or make it use fewer colors, or tetris together its pieces differently.

I basically deeply underestimated the amount of time art would take on this. (And also, my standards got higher as time went on.) All of the code has been maybe... 4 days? Remaining code work will probably take about as much time as the initial release's code which I basically put together in 2 days. All other time spent is art, art, art.

The end is in sight, there's only one remaining thing I'm worried about. I will say one thing now so whoever might be following this doesn't get their hopes too up. I am actually not doing the battle system. I'll go into more detail about why whenever this drops, but short version is I've already spent a hefty amount on this and the battle system requires some tough things still. Still, I'm quite sure everyone will be pleased.

Until the next update. (Which may just be the finished thing, who knows)

 

[KaboomKid]

I am actually not doing the battle system.

Good! Not that I doubted your skills or anything, but you were already putting in more work than I'm sure a lot of us expected, so it's great that you're not letting yourself get too overwhelmed. It's looking great so far, and I think a nice simple fangame will be more than enough for everyone to enjoy. I can't wait to check it out!

Best of luck wrapping it up, and thanks for sharing with us!

 

[Goodbye18000]

Yeah man, getting the Indivisible battle system on NES would be super tough. No reason to be THAT accurate.

I mean, to compare, the "NES Version" of Azure Striker Gunvolt and Mighty No 9 don't have either of their "battle systems".

 

[Kasumi]

RE: Battle System.

Thanks for the support. I've actually written the "Why I didn't" thing, but waiting to post it. To be honest, the making of post for the finished thing is looking kind of daunting to write, so at least that part's done.

I tried really hard to avoid revealing the scope of this for a long time, but I guess I don't care as much anymore. One more gif:

(Much less likely this one'll change, but also unchecked.) Okay, but now probably no more updates for a while because I'm running out of things that don't really ruin this.

Edit: Actually may as well give what is close to an actual update instead of a tease since the scope thing isn't... very secret anymore.

I have 25 remaining things on the "outside of my usual realm" todo list. Maybe 12 non small things on the "comfort zone" todo list. One thing I may release without honestly... depends on my mood on the particular day I try it.

I can see that end, but it's not quite close yet.

 

[Kasumi]

Slowly spoiling the whole thing.

Who wants to see what an animation looks like before I butcher it to make it fit within sprite/tile limitations?

I will probably have to wreck this animation to get it to work, so here it is unwrecked. I'm finishing all the animation before cramming it down. Cramming as I go is bad, because realizing something won't work and having to fix it is not good for motivation. It'll be less so when the rest is done, I think. It'll feel like the current task, rather than extra work keeping me from the actual task. (I did at least check a single frame for each enemy design, though. Having to redo an entire enemy's animations because the original was too large is the kind of massive mistake one tries to avoid... Belu used to be green, but he used far too many sprites that way because his red clothes/tongue were not in the green palette. Luckily his actual colors are basically in between the green/blue so either is close enough. Still kinda prefer the green, but them's the breaks.)

Still a fair amount of things to animate, but when that's done I'll feel like the project has actually begun. I'll probably make another post when all animation is complete, since someone told me I should post updates to keep motivated. There really won't be any more fun tease images, though. I have already posted a bit more than I wanted to. (Edit: Actually, nah. I know what I'll post when all animation is complete.)

Provided there are not any hard animations left (this was a hard one), maybe this'll be out in #twoweeks. Also depends on that thing I'm considering releasing without.

Edit 2: Actually one other "fun" thing to share. I haven't touched the game's code since March 3rd. So much animation work for one person who's more a programmer. :(

 

[North888]

hey man, your animation is legit. You want any help with some spriting? I dont know if I could help myself, cause I'm busy, but still, anything to keep this going.

 

[Kasumi]

Late response: First rest assured that there's no way this won't keep going/won't be released. (Unless err... something happens to me.) I definitely wish it was already finished >_>, but I'm not just gonna stop with as much as I have.

I wrote a long thing, but tl;dr: I'm open to help if it's better quality than what I can do. Bluntly if it's not better than I can do, it's only saving time and I'm aiming for quality, at least for a long short-term project, which I guess this is...

I don't want help with sprites specifically because it's just too much work to request of people. It's not just drawing the frames, there's a lot of dumb NES stuff you have to be intimately familiar with. I've had a couple of pixelation members offer help on backgrounds. You can see some general pixelation work here in the NES Castlevania "remix" thread to get an idea of pixelation quality, but I won't point out specific people who have offered.

Music was maybe slightly a secret, but really all the secrets are out at this point. To help with music, you've gotta be decent at Famitracker (2A03 since this game doesn't use hardware that allows for extra sound channels) as well as being able to additionally limit yourself to Famitone2 restrictions. It doesn't matter if the NES can do it if the music engine can't. A lot of general Famitracker stuff you see couldn't really appear in a game because it'd be too huge, or too CPU intensive, or too something else.

I do have a person in mind for music if I fail spectularly in my attempts, but if anyone thinks they can do it let me know. Same for backgrounds. Realize all followups on this project are basically waiting on all animation being complete (and in the game), though. With all animation complete, the project stops being hard.

Hopefully that's not too offputting a response, I do appreciate the concern/offer.

12 or 13 animations remain, 7 of which should be significantly easier than any of the other animations that will end up in the game. If you're clever you can guess which those are, but I sure won't confirm. ( ͡° ͜ʖ ͡°)

Hopefully the "all animation is complete" update isn't too far away. If I channel my inner animator, maybe I can finish the hard ones today...

 

[Kasumi]

All animation is done. (But not in the game.)* Getting it in the game is easier thanks to some tools I wrote, but still time consuming.

43ish animations total. I suppose that's a number like lines of code, though. It doesn't actually mean anything.

Idle bros:

Ajna actually doesn't have her idle animation. Maybe that'll change like minutes before release. All these animations are subject to change to make them fit snugly together.


*Does not mean all graphics are done. Excludes effects animation. Excludes the inevitable revisions to get them to fit in the game. Side effects are generally mild. Ask your doctor before trying Indivisible animation.

 

[Meow-Professor]

Roti's idle is so perfect.
This all looks really great so far.

 

[Kasumi]

Thanks, Meow-Professor. I actually... regret how much time I spent on the Roti idle, but also really like how it came out. There are a few completely unimportant animations that ended up being a lot of trouble.There is certainly some stuff I plan to write about the animation at length when this is all over.

Figured I'd give more of a devlog like update this time, since I care less and less about the development being secret. I have four specific things I'd rather not show still.

Anyway... NES can have 256 unique 8x8 sprite tiles in memory at once. In the initial demo, Ajna's animations (which... were the only thing that used sprites) used 180 unique 8x8 sprite tiles. That's... a lot. But it didn't matter because there was nothing else. I put all 180 in memory at the same time, and there was still room for 76 more.

All of her animations together currently use more than 256 unique 8x8 sprite tiles. (Perhaps around triple? Maybe more? I'd have to update a program to get an exact count.) But the limit isn't unique tiles. It's tiles in memory. You only need the tiles for the animation frame you want to display for the current game frame in memory.

You may not know that NES games actually had wildly different sets of limitations based on the hardware in the cartridge. This is a surprise to many people who ask,"What are the NES restrictions?" That is an impossible question to answer for most things people want to know. Basically every possible thing you could say has some game somewhere that wasn't limited by it. :( Even uh... the 256 unique 8x8 sprite tiles in memory, depending on how you look at it. >_>

Anyway, due to the nature of Indivisible for NES' current hardware setup, I can only swap in and out of memory four 64 tile blocks. I wrote a tool that automatically takes Ajna's animation definitions and splits them into 64 sprite tile blocks, duplicating tiles across blocks as necessary. This tool might choose to pair her run frames together in a block since they all share sprites for her "side-facing" face for example. But if it needed to add a frame that needed say... 12 new sprite tiles in addition to the shared ones, and the block already had 60 sprite tiles in it, it would place those 12 new sprite tiles in a new block as well as duplicate the shared ones from the block it first attempted to the new block. This is part of why I don't know how many unique sprites her animations have. I only know how many blocks, which contain duplicates.

So, one of the four 64 tile blocks is reserved for Ajna. The game just loads the block that contains the sprite tiles for whatever frame she's currently displaying. (Other frames will be in the block too, and that's fine.) This leaves 192 for whatever else needs to be in that frame. But... there are some subtle disadvantages to this behavior. Say I wanted this game to be two player. Imagine if both Ajnas needed to display frames in different blocks! I could just reserve a block per player, but then there are only 128 left for everything else. In the original demo, I could also totally have two Ajnas, because all her sprite tiles were in memory at the same time. But in that case, only 76 were left for everything else.

We're now done with the preinformation and getting to the meat. I do not have room in the 192 tiles not reserved for Ajna to do some of the things I kind of wanted to. I haven't checked for duplicates yet, but the Hungry Ghost's breakdown is over 64 unique tiles. I have not yet broke the Ahp down, but I expect it will use even more. And Belu... I've always known that probably just three frames of Belu will use more than 64 unique tiles.

If I just decided to do

Ajna Block
Hungry Ghost Block
Ahp Block
Belu Block

similar to the problem of having two Ajnas... I can't have two hungry ghosts if they want to display different frames. Or two Ahps. Or two Belus. At least not for free.

My original plan was to have just one Belu on screen at once with a reserved block like Ajna's. This left 128 tiles for all of the Ahp and Hungry Ghost frames. This seemed reasonable: As I stated before, Ajna in the original demo used 180 tiles. I thought I could squeak under 128 with the Ahp and Hungry Ghost that have fewer unique frames, fewer overlays, and are smaller. But unless I really luck out with the Ahp breakdown, I'm a bit up a creek with that plan.

There are actually all kinds of ways to solve this if I decide I want to...

1. Animate everything smaller. (Hah. No.)
2. Change the hardware setup of the game. (Also probably not. One hardware change that would make this particular thing pretty easy to do would make some of the stuff I'm keeping secret harder.)
3. Something like Skullgirls assists. (Well, not really like it. But hopefully y'all get what I mean.) Duplicate idle/hit/death in each enemy block. When something wants to attack it swaps in the block for the attack frame it wants. (But because the idle/hit/death are duplicated, anything not attacking will never change.) I can't have two things attacking at the same time, but I can have any number of them on screen at the same time (if all are under the 64 tile limit). Not... too bad a choice. If idle+WALK+hit+death+any unique attack frame fits in 64 tiles, this is actually cool. Something can attack you, other things on screen can be attacked and even MOVE. I bet no one would have even noticed only one thing could attack if I hadn't wrote this. :P
4. Waste a BUNCH of space. Instead of dividing the blocks into 64, divide them into 32. Then create number_of_32_tile_blocks*number_of_32_tile_blocks 64 tile blocks. (It's possible to do less than that so you don't need block1+block2 and the mirror block2+block1, but it's a touch harder to program.) This would get me up to two of anything on screen. To display, the first would store which frame it wants, the second would store which frame it wants, and the game would display the 64 block that contains the two 32 blocks with those frames. This is easier than the above by a fair amount, but gets only two of whatever it is I do it with on screen. (That is about all the NES can handle anyway, though. Just due to the 64 sprites on screen limit.)
5. Instead of dedicating blocks to a type of object, dedicate them to in game entities. So I could have Ajna, Hungry Ghost, Hungry Ghost, Hungry Ghost or Ajna, Ahp, Ahp, Hungry Ghost, or Ajna, Hungry Ghost, Ahp, Belu. You get the picture. No more than three enemies on screen, but they could be any three. This is also pretty easy to do.
6. ??? (I have something in mind, but it gives away one of the secrets. It's... a lame solution, though, and not like the actual game.)
7. Break Belu down into using a unique block for every frame. Use the rest of Belu's reserved space for the Ahp and Hungry Ghost. (Actually super great, and only thought of it moments before clicking reply. This post was good for Rubber Duck Debugging. But it won't work if any single Belu frame + all unique Ahp frames + all unique Hungry Ghost frames > 192. But then I could also do the same with the Ajna block. Break her stuff into say... 32 tile blocks, to get another 32 tiles of room for the Ahp and Hungry Ghost. I'll have to cut her stuff down for some other stuff already, though. If I cut so much there's not room for the largest number of unique tiles in other of her frames, this can't work.)
8. Some combination of the above.
9. Realize the Ahp uses very few unique sprite tiles, and regret writing this post.

Hoping for 9 myself.

Your reward for overcoming the wall of text:

A broken down Hungry Ghost Idle. It looked like it was going to fit under... then... well let's just say the other frames use more than tiles these four. Hopefully this was interesting. If not, well... I got something out of it, anyway.

 

[Red Witch]

Oi, homey, I gotchu on music. I think. I can make 8-bits, but i'll see about doing one that actually works on a NES, assuming you'll have enough memory. Then again, SFX are integrated into the music... hmm....


yeah, if you'll have me, I want in.

 

[Kasumi]

I was trying to wait to have a real update to post, but... ain't got one, probably won't for a couple of days.

So @A Red Mage as stated I do have a person in mind, and may still attempt it myself. I wish progress was faster and I knew how these cards would fall... Music will be the last thing I worry about. But nothing to stop you from trying.

If you're windows, here is a thing that lets you get music into an NES rom that uses the music engine I'm using: http://forums.nesdev.com/viewtopic.php?p=163799#p163799

Here is famitracker.
Apparently you can use musetracker too, but I don't have a thing to test music set up for that if it's different.

The rules are:

- Allowed notes are C-1..D-6, Note Cut (rest note)
- Only Volume, Arpeggio, and Pitch sequences (no Pitch for noise
channel) supported
- All instruments should have a volume envelope assigned
- Only the loop part of sequence is supported, release part is not supported
- Pitch envelope accumulate the offset at conversion time only, thus
it can't go further -64..63, and can't accumulate the offset with loop
- Only first step of Duty envelope for pulse and noise channels is used,
there is no Duty sequence
- 64 instruments max
- No volume column support
- Tempo is set with the global setting, speed can be changed with effect
Fxx (1..21)
- Bxx effect for looping without an intro, does not support forward
references
- D00 effect to cut patterns early
- No effects other than listed above are supported
- Up to 17 sub songs in a file, they will share instruments and pattern
data

Which should mostly make sense if you're familiar with Famitracker, or even just some other tracker. Even if not, the NES rom tool will complain if you use something not supported. So use it to check your work. I'm obviously looking for covers of music in actual Indivisible, but whatever is made can be super note heavy or super advanced or whatever so long as it fits within the above restrictions. The resulting output also has to be less than something like... maybe 14KB? But if you hit that, something is very wrong.

The rule not written there is you must use 2A03 alone, and no music extensions. This means if you have columns in your song beyond Pulse 1, Pulse 2, Triangle, Noise and DPCM, it cannot be used. But... also don't use DPCM. (The engine supports it. But... don't use it.)

When I did a small test attempt at music, I found that Lost Genesis ripped from the game is 1:31, but is basically looped at 46 seconds with more percussion.

Next update should be some enemies moving around, but there's some stuff I need to figure out with how to interact with them.

 

[Kasumi]

I had written a long post on Tuesday thinking the content for it would be ready... but uh... no. No it's not. So how about a short post with gameplay footage?! (Less exciting than it sounds)

How hits work is 100% not final.

Full disclosure: The engine doesn't yet have anything to compensate for more than 8 sprites per scanline, so for the above gif (and below png) an emulator option has been turned on that draws all sprites. (If you don't know what that means, you may have to wait for the next making of. Explaining it is how the other post got long.) As well, the Hungry Ghosts don't actually have any AI. They hop left and right purely because I'm pressing debug keys!

All the enemy graphics are in the game, displayable, and linked to hitboxes, but they have zero logic beyond that. I only kinda started on the Hungry Ghost.

Here is a funny thing that happened while I was testing if they were displaying properly:

I was scrolling through the frames, and where they were placed, they ended up like that.
Another bonus! This glitch:

This is not a test of a Heruka running afterimage. It's just a result of trying to execute code that... isn't there yet. (Usually this means a crash.) I was adding an enemy, but didn't add its address to the list. Notice it missing my jump/axe input sometimes.

I have no idea what the next update will be. Maybe all enemies programmed?

 

[superj3]

I don't know coding, but it looks like you already got the speed run animation already done.

 

[Kasumi]

Long time, no post.

An educated guess of what was happening for the run was that Ajna was being rendered multiple times without the sprites being cleared. Each frame, a different set of graphics is switched in to display the active frame for Ajna. Parts of the after image look glitched because they are frames that require a different set of image data than the active frame. They're still drawn, just with the wrong data. This would eat up all available sprites, so that can't really be made into a feature.

Actual update: All enemies are basically done. Oh, and also the game engine is done (more or less).
So... what's left? There are a few things things that aren't enemies. (HUD, and some other stuff.) There are some non enemy, but still sprite graphics to do. (HUD... and... some other stuff.) There is background art. There is the music. There is polish.

So the current plan is to finish all non background art/non enemy things. With this done, this will be a complete gameplay experience. From there I will send it to a small elite team to test. (Please, don't ask to get in on that.) While awaiting their feedback, I will work on (or... get someone to work on) the background art. Finally, I will attempt to make some music.

I wrote a Lua script that runs through the emulator and lets me place enemies where the mouse is, as well as display hitboxes and other info.

Here's a gif for each enemy:

Hop, hop, hop.

Notice Belu doesn't get launched as high as the Hungry Ghost. (How hits work is still not final, of course.)

Nothing special here.

I didn't go full tilt, but how the enemies move is at least reasonably accurate to the game.


Once again, all sprites for a scanline are displayed for the above images. The last engine things I have to do are put in a "flicker" algorithm, handle the game trying to draw more than 64 sprites better, and create a way to force a frame to be displayed with one palette. (So enemies can flash when they get hit.)

 

[Kasumi]

Hey, why I don't show the game looking really bad?

So in this image, the game is trying to draw ~93 sprites sometimes. NES can only display 64 at a time, and then only 8 on the same horizontal line at the time. Ignoring the scanline thing, this means it has to drop about seven sprites per object on screen. And then... there's also the scanline thing.

There will never be 3 Belus on screen in the real game, but yes... this game will have intense flicker. Now you know why most NES games don't bother with all this large animation. It looks a little better at 60 FPS, I promise.

 

[Goodbye18000]

You know if this was just a retro-styled fan game, that'd be a feature, not a problem.

 

[Kasumi]

Tanner (Obeying the signature): You're not wrong!

I haven't made a lot of time to work on this recently. Social things and whatnot. It's basically a half year old now, though. Yikes. All of this is spoilery, but anyone's who is following this probably gets the idea of what I'm aiming for anyway.

I wanted to do that the easy way. Except that "environment" is too long a word to draw with sprites and avoid flicker. I'm mad because I actually went through it in my head so many times thinking I could do it with sprites. I was worried about "traverse", which is exactly eight letters... thought I was good because of that. Apparently never looked further. This was tough in ways I don't wanna get into right now. Although... part of it was me misreading documentation, so that's on me.

Here's another thing...

(Obviously the timer won't display during real gameplay, that's a debug thing.) That timer was also work. So there's a thing the NES can do every frame consistently. Lots of games use it for music playback so that even if the gameplay slows down, the music playback won't. Seems like it'd be easy to rig a timer to. Except there's... a lot of reasons you might want to turn off that consistent thing, because it can WRECK things that aren't prepared for it to run. And disabling it anywhere meant the timer would not count those frames.

I could not allow that to happen. What I did just to make the timer not stop while loading new areas... I'm terrified it's gonna lead to the game crashing in some cases. I've actually done a few things recently that I'm terrified will make the thing crash. Another thing that might make this crash? What I did to make sprites fade in. High stakes for such small things.

The timer will still be "wrong", though. Because NES runs at not-quite-60FPS and the timer assumes 60FPS. I think even I'm not crazy enough to care about that, though. The fact is it's counting actual gameplay frames and (hopefully) isn't missing any. So even if the time doesn't match real time, you can still use it to compare records.

Tetris Grand Master 2 has a similar quirk: The timer assumes 60FPS, but the hardware runs at not-quite-60FPS. Source.

Edit: I haven't even put time into the two remaining big things... hopefully it's not another two weeks before the next update. Looks like the release isn't coming before page 2 of the thread D:

 

[Goodbye18000]

I'm terrified it's gonna lead to the game crashing in some cases. I've actually done a few things recently that I'm terrified will make the thing crash. Another thing that might make this crash? What I did to make sprites fade in. High stakes for such small things.

Gaming is built on such risks!
Though seeing it like that makes me actually mad about Simon's Quest. Remember how IT faded out?

If only they had 2016 knowledge of building NES games.