I'm Kasumi. I made Indivisible on NES.

Kasumi

New member
Yo! I'm Kasumi. I made Indivisible on NES.
xjClQGL.gif
txbs03f.gif

Vo3mi3w.gif
WlJmCW9.gif

You can download that here: https://kasumi.itch.io/indivisible
I also made an infographic about NES graphical restrictions:
xZeDpmK.gif

Some of that stuff can be got around, but I only had so much space. (It was for twitter)
I wrote this more detailed post on a pixel art forum: https://pixelation.org/index.php?topic=10784.msg115062#msg115062
I made this program that will take an animated image sequence and turn it into a ROM (must obey the above background rules!): https://kasumi.itch.io/ichr
S48Ne2z.gif

I'm nearly done with some metasprite stuff for it, but I'll probably only release stuff for background overlays initially. For what it's worth, I'm not really trying to compete with NES Maker as far as no coding required, there are just a few things existing tools don't solve very well for NES. (Animated backgrounds are one, metasprites are another. NES Screen Tool allows the second part, but when you have as many frames as Indivisible, it's very time consuming.)

Anyway, I'm interested to see how NES Maker develops. I'll probably primarily answer technical questions here and there and lurk otherwise.
 

JakeSpencer

New member
Hi Kasumi! I really enjoyed Indivisible, and it's cool to be able to talk with you! I loved the cultural representation of your game more than anything else. Your games and style are exactly what's needed in the NES homebrew scene, and I look forward to seeing more of your creations.
 

Kasumi

New member
Hi and thanks, all! Praise be to the original game for cultural representation, I just followed their lead.

I really want to get back to making games, but my focus has been on making better tools so I don't have to do some of the crazy stuff I did for Indivisible manually again.
 

twelveplusplus

New member
Thats awesome! Thats cool that you premade a game! I was an indigogo supporter for indivisible, cant wait to play it! Actually, my friend knows those guys at labzero. Have they seen your version? I imagine they would be stoked.

Also, your sprite tool looks super useful. Im making a tool to turn 3D animations into pixel art spritesheets , so i can prolly just call your tool to process the output...

That will really speed up the process of getting the color quantization settings and all that to look good/be correct.
 

Bucket Mouse

Active member
I read your entire devlog this afternoon:
http://skullgirls.com/forums/index.php?threads/indivisible-on-nes-playable-rom-inside-image-heavy.8488/
This took a lot of time and effort with just Assembly alone.

I have a question after reading that infographic: If only 8 sprites can be displayed on a scanline, and Mario is 8 sprites in size, how come Super Mario Bros. has no flicker problems?
 

MistSonata

Moderator
Welcome, Kasumi! Love your stuff here, and I'm sure those infographics will be of great help.

Bucket Mouse said:
I have a question after reading that infographic: If only 8 sprites can be displayed on a scanline, and Mario is 8 sprites in size, how come Super Mario Bros. has no flicker problems?

A scanline is a horizontal line across the screen. When someone says that the NES can only display 8 sprites per scanline, it just means that they can't occupy the same horizontal line without flickering issues. Mario is 8 sprites, yes, but that's 4 sprites tall and 2 sprites wide, meaning that there's enough room for 6 more sprites on any given scanline that he's on. There's no such limitation for putting 8 or more sprites in a vertical "line", though.
 

Kasumi

New member
twelveplusplus said:
Actually, my friend knows those guys at labzero. Have they seen your version? I imagine they would be stoked.
Yes, it was retweeted by the official Indivisible twitter account, retweeted by one of their artists and quote tweeted by two programmers there. I can't really link to retweets, but here are the quote tweets:
https://twitter.com/MikeZSez/status/904850015423651840
https://twitter.com/renderling/status/904857942549299200
Mike Z played and beat it in multiple ways. If anyone else played, I don't know about it. But it was definitely seen.

Also, your sprite tool looks super useful. Im making a tool to turn 3D animations into pixel art spritesheets , so i can prolly just call your tool to process the output... That will really speed up the process of getting the color quantization settings and all that to look good/be correct.
Well, my tool does no quantization at all, just palette matching. If your image is too many colors, It doesn't try to make it fewer colors, it stops. (Well, for backgrounds the plan is to allow a user to add sprite overlays if it breaks background restrictions. But an image >25 colors is not a problem I want the program to try fix automatically. And even for <25 colors, if it's going to take more than 64 sprites, it's going to error out.)

It's also only a background tool right now, no sprites. I thought I had jumped the last hurdle conceptual hurdle for the metasprite part of it, but there's a bit more to plan. Currently it imports an image sequence and finds a set of candidate sprite tiles to take from the image. "All" that's left is choosing the best candidate tile and repeating the process until there are no non transparent pixels left in the character's animation frame, then move to the next. But there's one case left I'm not entirely sure what to do with.

When I decide, it will be basically a fully automatic import for sprites just like it currently is for backgrounds.
I did this:
3HZZooq.gif

and this:
kGo8PYT.gif

For all 200ish frames in Indivisible.

With the new tool, I can just load the frame sequence, and I'm done (if it works well.) My goal is to not use NES Screen Tool anymore. One of the reasons I did it manually for Indivisible is all the sprite overlays. I also anticipate the algorithm will do less well manually than I did as far as tile re-use. But if it's close, it's a fair trade for the time saved.
Bucket Mouse said:
This took a lot of time and effort with just Assembly alone. ... I have a question after reading that infographic: If only 8 sprites can be displayed on a scanline, and Mario is 8 sprites in size, how come Super Mario Bros. has no flicker problems?
Making games is time consuming, regardless of platform. I'll say assembly language was not really the hard part, it was the asset creation and design. Indivisible is short, but has more assets than some full length games. It contains more than 200 frames of animation.

Here is the version of Indivisible I made in 5 days:
weUoT5c.gif

Troll Burner took 8 days with a team, I did the above alone. But gamedev progress is not linear. As more things get added, you have to be exponentially more careful of breaking previous things.

MistSonata is correct that it's sprites per horizontal line of pixels. Super Mario Bros. DOES have flicker, but it's not easy to encounter. Mario is two sprites wide, as are most enemies. So Mario and 3 enemies can all be standing on the ground with no issues. Introduce a fourth enemy and the limit gets hit. (5 objects * 2 sprites per row in each object = 10 sprites in some rows. 10 > 8 )

As for why it's per row, it has to do with the way the screen is rendered: https://youtu.be/3BJU2drrtCM?t=3m3s
There's only so much time in each row (with a break in between to restart the line), so it drops sprites if there are too many to fit in the time. (Greatly simplified.)
 

Bucket Mouse

Active member
Kasumi said:
MistSonata is correct that it's sprites per horizontal line of pixels. Super Mario Bros. DOES have flicker, but it's not easy to encounter. Mario is two sprites wide, as are most enemies. So Mario and 3 enemies can all be standing on the ground with no issues. Introduce a fourth enemy and the limit gets hit. (5 objects * 2 sprites per row in each object = 10 sprites in some rows. 10 > 8 )

As for why it's per row, it has to do with the way the screen is rendered: https://youtu.be/3BJU2drrtCM?t=3m3s
There's only so much time in each row (with a break in between to restart the line), so it drops sprites if there are too many to fit in the time. (Greatly simplified.)
There's that classic scenario where four or five Goombas are marching in a row, Mario has a Koopa shell, and he can knock them all out. That breaks the 8-sprite line easily. I don't remember any flicker occurring there.
 

Kasumi

New member
Bucket Mouse said:
There's that classic scenario where four or five Goombas are marching in a row, Mario has a Koopa shell, and he can knock them all out. That breaks the 8-sprite line easily. I don't remember any flicker occurring there.
You may not remember it, but I guarantee it's there! Be aware that some emulators and clone systems let you disable that limit.
OcCLq6B.gif

Note the left and right goomba alternating being visible when there are four on screen, and the right side of the goomba directly in front of Mario disappearing when a new goomba appears half on screen from the right.
Edit: One more example. Not Super Mario Bros. but Mother:
OTcaTea.gif

Because the sprites aren't constantly moving toward offscreen, the effect lasts for longer and you can see it in real time.
Which things keep visibility can be controlled in software. In the above image 3 of the characters are always visible and 2 flicker. But you could have all 5 flicker. (Or worse, just have the extra stuff always be invisible.)
 

Godzil

New member
There is no flickering unless you do it yourself, the 9th and over sprite on the line are just not shown at all, if it flicker it is because the game do some rotation on them to try to display all of them
 

Bucket Mouse

Active member
Godzil said:
There is no flickering unless you do it yourself, the 9th and over sprite on the line are just not shown at all, if it flicker it is because the game do some rotation on them to try to display all of them

Sounds like this would be an important function. I sure hope it's baked into NESMaker.
 

FrankenGraphics

New member
I'd assume so, yes. Most games have some variant of sprite priority cycling going on (which is why the misconception that sprite flickering is inherent to the system is popular).

Examples of exceptions would be isometric games (the immortal & solstice) where shuffling sprite priorities would mess with depth perception.

In some game situations, you might want to split sprite OAM into priority partitions where low-priority sprites are cycled among themselves and high-priority sprites are fixed (ie always shown on top in a certain order of each other).
 

Kasumi

New member
I made a program that turns a PNG sequence with a palette into sprite tiles and OAM for "metasprites".

CBLUJDl.png

The above are the 8x8 tiles needed for 255 frames of a color reduced Sakura. You'll note she's more than 3 colors+transparent. That's fine! The program still figures it out.
However, most of the frames need more than 64 sprites to display which is... less fine. Talk about flicker!
But the 8x16 version: https://i.imgur.com/WRFCJhI.png
Usually gets under the limit. Here's how many sprites each frame for the 8x8 version uses:
sMLYykH.gif

Disclaimer: I don't really plan on making a Street Fighter thing, this was just a test case with images that weren't made with NES in mind.

This may at some point get added to my program I-CHR... I also guess at some point I'll just create a topic here for the program. But for now, there's not a lot of activity anywho, so I'm cool in this introduction thread.
 

FrankenGraphics

New member
Coincidentally I did some rough concept work last week remodelling the barbarian from the game with the same title for the eventuality of working with the epyx guy. Big meta-sprite fighters are notoriously hard to make on the NES! I'm on the fence wether to use 8x16 (will result in more flickering since it is less flexible with placement, but is less CPU intense and you can use both chr pages) and 8x8 mode (where i'm always on the threshold). In this downsized remake and because of dynamic placement of sprites, the barbarian is usually 3 or 4 sprites wide (except when the sword or kick is extended) even though it looks wider when assembled.
[img=https://frankengraphics.files.wordpress.com/2018/03/frankengraphics_rough_example.gif][/img]
 

Kasumi

New member
Deja vu, but a chance to condense my thoughts. A solid benefit of a tool like this is you can switch all your art from 8x8 to 8x16 at any time.

I'm usually happy to throw lots of tiles and sprites at the main character. In the universe where I remade Indivisible, I'd probably not change her, but I'd animate the enemies less so they didn't need the banking. For a couple of future games I'm making, I think that's what I'm planning. (One swappable bank, or part of a swappable bank dedicated to the main character, the rest for the rest.)
 
Top Bottom