What is it?
This project started out as just a simple program that extracted tilesets from game maps, but since I've started a few more coding projects along the same line, and I'm learning Qt, I've decided to pack all my mini tools into a GUI suite that I'm calling The Spriter's Toolkit. There are currently three tools in the works which, when used separately, operate by changing settings in an INI file and then dragging files onto them to make them run; not very user-friendly. The GUI is going to remedy that, though the current method really isn't that hard.

I'm making these small tools as part of my new "lots of pots" approach to programming, so I'm gonna be making a bunch of little tools as practice and then packing them together. Each one is named for its function, as one would expect. Here's the designs I have so far:

Tigestion:
This is my tileset "digester". Tigestion takes an image and breaks it into chunks, then compares each chunk and keeps only the unique ones, deleting all repeats, and then saving the remainders into a new sheet. I got the idea after doing my Metroid: Zero Mission tile rips, since pulling them directly from the RAM gave me a bunch of duplicate tiles, which made the sets look bigger than they really were. The tool also works on maps from games, breaking the landscape apart and extracting the unique tiles right out of them. It can also be used for sprite sheets to eliminate repeated frames to allow people to examine the individual frames better, or to edit one and paste it over all the same ones.

Here's a mockup for this one.


SNEStify:
This one's a palette adjuster that was originally just meant to make color palettes compatible with SNES by making each color value a multiple of eight, but I figured it'd be nice to allow that value to be changed, as well as to set minimum and maximum color values, and even divide by arbitrary amounts. I designed it to quickly convert all my existing sprites to my new color rules, but I think others may find more uses for it.

Palomine:
Takes a given palette and applies it to an image. It works by comparing each color in an image and checking it against the given palette, then assigning it to the nearest color in the palette. For instance, a photograph could be quickly altered to look like an NES picture by matching it to the NES palette. Used in conjunction with SNEStify, any image could look like an authentic retro console splash screen.

Remarkable work so far.

Thanks! Lemme know if you guys have any tool ideas I can add to this. I'm working on Tigestion's functionality first, so I'll update here when it's stable.

Really interesting program! It could be really useful!
Here are some things i thought that could be useful too:

Load files to sprite sheet: You select multiple files, and the program allign them on a single image with the given number of collumn and row, spacing between each image etc. This could be useful when your using a macro and you end up having 100 files with a single sprites on each.

Instant Animator: Find each sprite on the sheet, and display each of them, one after the other, in a panel. Of course, this would never be as perfect as the original animation, but it could be useful to see if there are missing frame or other errors. Maybe it could even create a gif out of it?

Background remover: Remove the background leaving only the sprites. Would only work if the sprites have an basic outline.

Seem like some pretty neat tools. I'm curious how Palomine works, how do you calculate the "closest" colour?

(04-13-2015, 01:45 PM)daemoth Wrote: Background remover: Remove the background leaving only the sprites. Would only work if the sprites have an basic outline.

I made a program for removing sprite backgrounds a while ago. Not sure if it's exactly what you mean though.

Animation organizer/compiler: compile sprite sheets with a specific animation order (idle, walk, run, etc) either from gifs or saved folders (or by importing each frame manually)

(04-13-2015, 01:45 PM)daemoth Wrote: Really interesting program! It could be really useful!
Here are some things i thought that could be useful too:

Load files to sprite sheet: You select multiple files, and the program allign them on a single image with the given number of collumn and row, spacing between each image etc. This could be useful when your using a macro and you end up having 100 files with a single sprites on each.

Instant Animator: Find each sprite on the sheet, and display each of them, one after the other, in a panel. Of course, this would never be as perfect as the original animation, but it could be useful to see if there are missing frame or other errors. Maybe it could even create a gif out of it?

Background remover: Remove the background leaving only the sprites. Would only work if the sprites have an basic outline.

1, could probably do that, if they're all the same dimensions. 2, do you mean on a grid or finding them in one of the layouts typically used here? 3, I could see that being done with outlined sprites, yeah, but hollow parts or things that partially overlap would likely cause problems. Though, it might help if it were to search for a particular palette.

(04-13-2015, 08:39 PM)puggsoy Wrote: Seem like some pretty neat tools. I'm curious how Palomine works, how do you calculate the "closest" colour?

It makes a list of the color palette and sorts it, then finds the colors on the palette that the pixel in question fits between and checks the difference to see which one it's closer to. Of course, different sorting methods cause different results, so I'll have to make options for which one to use in order to get the best results.

(04-14-2015, 05:04 AM)Sketchasaurus Wrote: Animation organizer/compiler: compile sprite sheets with a specific animation order (idle, walk, run, etc) either from gifs or saved folders (or by importing each frame manually)

Not quite sure how that would work, unless I were to program it to actually recognize shapes of characters and figure out what goes where, but in some cases, even humans can't do that.

(04-14-2015, 09:14 PM)Kelvin Wrote:

(04-13-2015, 01:45 PM)daemoth Wrote: Really interesting program! It could be really useful!
Here are some things i thought that could be useful too:

Load files to sprite sheet: You select multiple files, and the program allign them on a single image with the given number of collumn and row, spacing between each image etc. This could be useful when your using a macro and you end up having 100 files with a single sprites on each.

Instant Animator: Find each sprite on the sheet, and display each of them, one after the other, in a panel. Of course, this would never be as perfect as the original animation, but it could be useful to see if there are missing frame or other errors. Maybe it could even create a gif out of it?

Background remover: Remove the background leaving only the sprites. Would only work if the sprites have an basic outline.

1, could probably do that, if they're all the same dimensions. 2, do you mean on a grid or finding them in one of the layouts typically used here? 3, I could see that being done with outlined sprites, yeah, but hollow parts or things that partially overlap would likely cause problems. Though, it might help if it were to search for a particular palette.

2. Well, in a grid, left to right, top to bottom.

I think Sketchasaurus just means to load GIFs and individual images. Then compile/bake/organize all of them onto a single file (basically what daemoth said).

Yeah, Imagine you have your animations organized like this, each frame being a different image (in numerical order)
You would be able to have a list of animations in a particular order which you want to organize your sheet in a txt file, then the program would search for a folder (or gif) and compile a sheet in that order.
Or, you could manually insert the order and directory of each animation.

I'm sure there'd be other features that'd be included like padding, number of columns, etc. Anything that would make compiling sheets cleanly would be very useful.
Maybe there would also be the option of adding a tag to a sheet, but it should definitely have a size limit (large tags are messy and there are tons I've seen that make up at least half of a given sheet)

I think I see what you mean. Take the images and lay them out onto neat rows with a label. Yeah, I think I could do that.

As to the above question of how Palomine locates the closest color, I've come to realize that no matter how you slice it up, creating a one-dimensional array of colors just isn't gonna cut it. Color is three-dimensional, and I have to treat it as such, so I'm changing the color distance to actually use 3D distance.

Also, a lil snippet of Tigestion's code. I'm gonna make it open-source anyway, but if anyone using SDL needs a way to ensure two images match, here ya go:
This checks that two images are of the same size, then if that check works, it checks that all pixels are the same color. Because Tigestion needs to check every new tile against every saved tile, it may seem slower as it goes through the list, but this is normal behaviour, and shouldn't be worried about. Though, if you end up with the same exact image, just skewed in a funny way, chances are you used a JPEG or something.

(04-17-2015, 03:24 PM)Kelvin Wrote: As to the above question of how Palomine locates the closest color, I've come to realize that no matter how you slice it up, creating a one-dimensional array of colors just isn't gonna cut it. Color is three-dimensional, and I have to treat it as such, so I'm changing the color distance to actually use 3D distance.

Let me know how this goes. A while back I was trying to figure out how to go about this, I gave up but I plan to get back to it eventually. The problem is that you can't decide whether 0xFF0000 or 0x0000FF is closer to 0x00FF00, so the RGB colour space isn't reliable. Something like HSV might work, although I think I remember having issues with that as well.

(04-18-2015, 04:34 AM)puggsoy Wrote:

(04-17-2015, 03:24 PM)Kelvin Wrote: As to the above question of how Palomine locates the closest color, I've come to realize that no matter how you slice it up, creating a one-dimensional array of colors just isn't gonna cut it. Color is three-dimensional, and I have to treat it as such, so I'm changing the color distance to actually use 3D distance.

Let me know how this goes. A while back I was trying to figure out how to go about this, I gave up but I plan to get back to it eventually. The problem is that you can't decide whether 0xFF0000 or 0x0000FF is closer to 0x00FF00, so the RGB colour space isn't reliable. Something like HSV might work, although I think I remember having issues with that as well.

Actually, you can. There are methods using bit shifting to separate red, green, and blue from each other into separate values, letting you turn a color into a 3D point. For instance, here's a function that splits a 24-bit color value into three 8-bit values:


If the recieving variable is only 8 bits long, it'll automatically trim off the extra bits, leaving you with just the parts you need for that one color.

I know how to do that, but that's beside the point. The 3D points for 0xFF0000 and 0x0000FF are equal distances from 0x00FF00, you can't say which is closer.

Perhaps you can allow color weights or allow the user to choose the preferred color? The tool is for the user so let them decide, and have some kind of default.

An example of weighting, let Red have weight = 80, Green = 20, both in the palette. Now, which color should Blue be swapped with? -Red, since it has higher weight. Manual weighting might become tedious with many colors, which is why there should be a default or an alternative.