I-CHR: Turn an image sequence into bankswitched CHR

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: I-CHR: Turn an image sequence into bankswitched CHR

Post by Kasumi »

@Bregalad: Yeah, Justin Cyr's work is pretty cool. I tried to match his style with my spinning girl, but his is way more dynamic.
FrankenGraphics wrote:I just had a first go with this tool, though maybe not for what it was primarily intended for but for one of its side features? It helped me organize a sprite overlay made in PS into a tidy chr at perhaps a quarter of the time it would take doing that with nesst :beer:
Thanks for trying it! I consider that use within the intent. Easier image->CHR is why I made it. It fixes two of my bigger issues with other tools. (Requiring creation of indexed palettes/images, and rejecting images that use colors outside an arbitrary NES palette.) Of course, creating a palette still helps if you want a specific result.
Any chance you might be interested making it accept a NES .pal binary as an option? I usually have those ready anyway while a bitmap strip on the other hand needs to be made. Not much of a problem, but i might as well ask.
There are two types .pal files associated with NES.
If you mean load a 192 byte NES palette from an emulator .pal instead of "Assets/nespal.png", probably.
If you mean load a 16 byte NES Screen Tool palette instead of "(file)_palette.png", you'd still end up needing to either provide "(file)_palette.png" or hack "Assets/nespal.png" to ensure a specific result.

Image->Bitmap Strip Palette->.pal indices. (The bitmap strip ensures the index order of the colors is preserved, and the .pal replaces the color algorithm's guessed indices with the indices actually intended for each color. You'll get exactly the result you want.)
Image->.pal indices (It would look up each color index provided within the included palette, and then find the closest color in the image. But there's potential for say... two similar blues to have their color indices swapped due to the differences between the palette your .pal refers to and the included RGB palette.)

I don't think it'd be too hard, just realize you would have to change "Assets/nespal.png" to match the NES Screen Tool palette (which your .pal refers to) as well as only use colors in the NES Screen Tool palette in the image itself to ensure a specific result if you didn't also provide a bitmap strip. Let me know if I'm misunderstanding.
I’m curious as to why the output chr starts (at least in this particular case) with a series of identical blanks? Are those reserved?
To answer the why...
Short answer: They're not reserved, but they're padded because of the animation support. It grows from 255 down rather than 0 up.
Longer Answer: I wanted the tiles to be contiguous and I wanted animated tiles at the end of the set. The diving girl is 65 tiles, 64 of which are animated. So all the animated tiles are put starting from tile 63 to 0 of one 64 tile bank, leaving one tile at the very end of a new 64 tile bank (to satisfy the contiguous condition). Starting at tile 0 would mean two 64 tile banks for every frame instead of one (to satisfy animated tiles being at the end of the set.)

You bring up a good point that this isn't too intuitive a default configuration for people not working with the bank swapping features. I'll come up with something to help with this.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: I-CHR: Turn an image sequence into bankswitched CHR

Post by Kasumi »

Watch... as I keep posting updates here, but never actually release the program with the updates.

You can now create, manage, and export animations:
Image
You can export multiple characters into a ROM too.
You can now also save and load characters to a file. This would allow you to share them, or whatever. But it also allows you to avoid the time consuming tilification™ process.
(There very likely won't be "level" saving in the next release, but it takes way less time to reload that stuff.)
Here are some animations from Street Fighter 3: 3rd Strike's Chun Li:
Image
(The holes are because most of these metasprites are more than 63 8x8 sprites. I-CHR only supports 63 [rather than 64] to avoid moving a pointer.)

I made the Chun Li animations 3 colors to make it use fewer sprites, but the program can import 12 color characters if you really want.

What's left is a lot of... file stuff and error checks, I guess. I-CHR gives .nam files for NES Screen Tool but the chr isn't padded which makes NES Screen Tool reject it (unless it uses more than 192 tiles).

I'd also like to make it export useful sprite data (rather than just a ROM.) A NES Screen Tool .MSP/.MSB file, CHR, etc. Interoperability with NES Screen Tool is one of the goals. At least... as far as I can get. Multiple MSP/MSB would need to be exported for characters that use >256 tiles like Chun Li. There's code to break them into chunks for the ROM, but non contiguous metasprites get put together randomly. Ideally it'd start at metasprite 0 and add metasprites until a 256 tile bank was filled, then export that as 0.MSB and 0.CHR and start on 1.MSB. That's more or less how I handled characters in Indivisible using NES Screen Tool.

I really do hope to have it out soon, though. I want to work on a (non NES) hitbox tool and some other gamedev instructional stuff.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: I-CHR: Turn an image sequence into bankswitched CHR

Post by Kasumi »

Time for another update on the program that will never actually come out:
Image
(Full disclosure. Some load time was edited out. For these it was only like four seconds per sequence. It can get long, though, if you give it something nuts.)
You can set how many palette sets the program is allowed to use when it guesses palettes. If the set of images is impossible to do with the given number, it will mark pixels of the least used colors. (For example, if two palettes are wanted, and there are seven non transparent colors it will mark pixels of the least used color across the animation. If two palettes are wanted, and there are eight colors it will mark pixels of the least used two colors.)
You can now import a new image sequence without replacing the old one. It automatically creates a new animation of all the frames for just that sequence. So you could import say... your idle animation as one sequence. Then import your walking animation as another. The sequences DO need to match colors exactly (except for the transparent color, which can actually be unique in each image. It's whatever the top left pixel is). They also need to be aligned beforehand for the exported data to be useful... It's one of the many things I'm aware would make this better, but I want to kick this out the door just to make sure the base functionality is not totally broken.

The file loading tries to figure out the file type. If you load a 4, 8, 12, or 16 byte file, it loads it as a binary palette. If you load an image with 4, 8, 12, or 16 pixels, it loads it as a palette image. If you want to import a really small sprite, well, just add transparency around it!

You can remap the current palette (changes the colors used to display, does not require new tiles to be made). OR you can load a new palette. (Colors outside the new palette get marked, since that prevent the creation of new tiles.)

Not shown in the gif, but you can toggle between NES display and the original input images. (Which might be useful to see what the image looked like before remapping.)

That was all for sprite mode. The tileset mode is pretty behind. I plan to make it so you can load palette images and binary palettes like FrankenGraphics requested in uh... April. The padding thing won't be changed for the next release, that requires changing a lot of things in both the ROM and the program.

I actually feel like whenever this does come out, the coolest part of it (sprite stuff) won't have very much use to most people here. :cry: It's hard coded to 128 tile banks (because the background is hard coded to 64 tile banks), and 8x8 sprites. The program can totally make arbitrarily sized banks (Ajna in Indivisible used something like... 50 so the HUD could fit in the back side of every one of her banks), but I'm still planning out how to get that to scale to be actually useful. So no UI for it. It might still be fun to play around in, though. I've found it cool to just import random NES sprites and put them on top of random NES backgrounds. :)

As you can see from the Mario metasprites, 220 tiles is a LOT compared to the actual game. I do have some plans and other algorithms to improve this (including a way more simple one that would probably do way better on Mario), but the primary reason behind this program is not having to do it manually. (Or at least, only committing to doing it manually once you're sure the graphics won't change.)

Edit: I forgot about my deduplication algorithm which is not run automatically (because it's stupid slow right now). Mario after deduplicating is 151 tiles. (Vs 220.) Mario+Mega Man is 668 tiles. (vs 1152.)
Edit2: It's only stupid slow for insane use cases like Chun Li. Mario+Mega Man is only three seconds! Still, I'd like to improve it before I make it automatic.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: I-CHR: Turn an image sequence into bankswitched CHR

Post by Banshaku »

Always interesting to see result from your tool. Good work!

If the imported data can be easily be updated by hand after, even though there is some duplicate it can be quite handy compared to build then all by hand (like I did long time ago). That does save a lot of time.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: I-CHR: Turn an image sequence into bankswitched CHR

Post by Kasumi »

Thanks! The most immediate plan is to import/export data for NES Screen Tool which has alright tools for tweaking existing data. There's some groundwork to be done before that's useful, though. Currently the program is likely to destroy any imported hand edits with its own guesses in short order!

I did plan out a really fast way to make CHR/metasprites by hand before my thinking got super... automatic. It would turn what is currently many manual steps (isolating pixels of a certain palette for a tile [assuming sprite overlays], indexing the tile, creating the right coordinates within the metasprite) into 1 step. (Or 0 steps!)

Especially since the program can already do it automatically, it could even show you a guess which you could use instead of going your own way. We'll see if I actually get to building it.
Post Reply