#1443 - Phattso - Sat Jan 18, 2003 10:37 pm
Hi, folks!
Recently I've resurrected some old sprites I had from the early 90's. They're all in .TIF format (24bit). I've used Paint Shop Pro 7 to batch convert them to .BMP files (ready to be converted to .h files).
The trouble is, each frame has a slightly different palette - an unfortunate side effect of the conversion process.
I was wondering if any of you knew where I could find a utility to merge the palettes into one, and then re-save the .bmp files with the new palette/raster data?
Thanks in advance for any suggestions that can save me having to write my own tool to do this. :-)
Cheers!
#1444 - ampz - Sat Jan 18, 2003 10:54 pm
Not that hard to write a tool to do that...
Check out the map editors for GBA... They should be able to load a bunch of custom images and produce some useable output.
#1445 - Phattso - Sat Jan 18, 2003 11:31 pm
Ampz,
Indeed there are a lot of conversion tools that merge palettes and produce .bin or .h files for use.
Perhaps I should have gone into more detail: I specifically need a tool that updates the source bitmap files, and not one that just takes loads of inputs and generates some seperate output files.
The reason is that I'll actually be converting these files one more time into RLE bitmaps, and then using a custom tool to save the RLE raster data as a .h file. These sprites have *many* frames of animation, so I need them to be as small as possible (without having to incur the runtime penalty for other types of compression).
As you say, not a difficult job per se - but it could become time consuming and I'd rather not re-invent the wheel if someone else has already done this. If they haven't, then I'll just write my own and release the tool when I'm done.
Thanks for replying.
#1465 - JonH - Sun Jan 19, 2003 2:56 am
mmm...
i know it may not exactly meet your requirement, but gifs2sprites will merge the palettes of every single one of your sprites. then, if this is greater than 256 colors, it will decrease the palette to adapt to the color depth.
quote from the readme included with the tool:
| Quote: |
If the result palette grows too large for the desired color depth, the number of colors will be decreased with help of color quantization. (All colors will be placed in a cube that is divided in a number of blocks until the number of blocks corresponds to the number of colors). If this happends, a warning will be displayed when the command is run.
|
then if this doesn't help, just ignore my waffle ;)
#1471 - Phattso - Sun Jan 19, 2003 11:09 am
JonH,
I've tried that particular tool and others like it when I've been working with sprites in the Tile Modes. For that they are invaluable, and their palette merging is really good.
Sadly, the problem for me is that I don't want it to generate a unified palette for the images and then reflect it in a .h file - I need it to physically update each of the source images with the new palette and raster data so I can then feed the images into my own converter.
As has been suggested, it's not that tough a tool to write (especially since I know that each palette contains the same colours, just in a different order). Perhaps I'll just kick myself out of lazy mode and write something custom. :-)
Thanks for the suggestion, though.
#1479 - tepples - Sun Jan 19, 2003 3:20 pm
| Phattso wrote: |
| I need it to physically update each of the source images with the new palette and raster data so I can then feed the images into my own converter. |
Why would you make it go in and modify your source images in-place? Wouldn't it be a cleaner design to have the palette unifier output the images under a new name or in a new folder, leaving your source images unchanged? Imagine what happens when you run an in-place palette unifier, edit one of your source images, run the palette unifier, edit, rinse and repeat. You start seeing weird color shifts across all your sprites. Eventually, your images would lose quality.
Never make a processing step that modifies your source images.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#1485 - ampz - Sun Jan 19, 2003 3:38 pm
I put all my sprites on one big bitmap, then I just convert the entire bitmap to an C array.
No palette problems whatsoever...
Of course, this means I have to use the 2D mapping mode, wich sometimes can be a bit of a pain in the nic'tah' (a goa'uld word for a specific bodypart)
#1487 - tepples - Sun Jan 19, 2003 3:49 pm
I too put all of a sprite's cels on one image before running it through the converter. Sixteen colors, four bits, zero problems.
You don't have to use 2D mapping mode if you either A. make your bitmap 32 pixels wide (assuming 32x32 sprites) or B. use a tool that converts bitmaps to 1D mode sprite cels (which shouldn't be too hard to write).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#1494 - Phattso - Sun Jan 19, 2003 4:54 pm
tepples,
Indeed, you are right. They should be output to a new .bmp file. I was only trying to make obvious the fact that I don't want it output to another format (.h or .bin). My explanation was badly worded. :-)
As soon as I get the sprites with a unified palette, I won't need the tool any more (which is why I'm keen not to have to spend time writing one just for a one-shot deal). But it is obviously not good programming practice to arbitrarily destroy ones source images.
I understand what you're all saying about having a single image, uinifying the palette, and then extracting the images. This is how I do it for my mode 0/1/2 projects.
As I've already mentioned, however, my situation is slightly different in this case. I have some legacy images (128x128 .tif's) numbering into the hundreds (423, in fact) that were professionally created for a project on an ARM platform back in the early 90's. It would have to be one *hell* of a big bitmap to do it the normal way. ;-)
Thanks for the comments, all.
btw, tepples: I downloaded TOD and had a quick play.
My head *still* hurts some 20 minutes later! ;-)
#1497 - ampz - Sun Jan 19, 2003 5:13 pm
| tepples wrote: |
I too put all of a sprite's cels on one image before running it through the converter. Sixteen colors, four bits, zero problems.
You don't have to use 2D mapping mode if you either A. make your bitmap 32 pixels wide (assuming 32x32 sprites) or B. use a tool that converts bitmaps to 1D mode sprite cels (which shouldn't be too hard to write). |
True, IF all your sprites have the same dimensions you can use 1D mode by setting the image to the same width as the sprites. But very few games use only one size sprites.
And no, it is impossible to write a automatic conversion tool that makes a 1D mapping out of a large image containing sprites of different sizes. A semi-automatic one can be done, but it's not that easy.
BTW, I have to switch to 1D... Animated sprites require me to write awful code if 2D mapping is used.
#1517 - tepples - Sun Jan 19, 2003 8:18 pm
| ampz wrote: |
| But very few games use only one size sprites. |
The NES allowed for only one sprite size per screen, 8x8 or 8x16 pixels. The Super NES allowed for only two sprite sizes per screen. Thus, NES and Super NES games often built their sprites out of small tiles, 8x16 pixels in the NES case and 16x16 pixels in the Super NES case.
| Quote: |
| And no, it is impossible to write a automatic conversion tool that makes a 1D mapping out of a large image containing sprites of different sizes. |
Impossible? The Allegro library's "grabber" tool does it. It reserves color 255 for "boxes" around sprite cels and then assumes that any rectangular area surrounded by color 255 is a sprite cel.
| Quote: |
| A semi-automatic one can be done, but it's not that easy. |
It shouldn't be too hard to write a GUI tool that displays a bitmap, lets the user draw boxes on the bitmap, and saves the boxes' coordinates to a file that a converter uses.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#1522 - ampz - Sun Jan 19, 2003 8:50 pm
| tepples wrote: |
| ampz wrote: | | And no, it is impossible to write a automatic conversion tool that makes a 1D mapping out of a large image containing sprites of different sizes. |
Impossible? The Allegro library's "grabber" tool does it. It reserves color 255 for "boxes" around sprite cels and then assumes that any rectangular area surrounded by color 255 is a sprite cel.
| Quote: | | A semi-automatic one can be done, but it's not that easy. |
It shouldn't be too hard to write a GUI tool that displays a bitmap, lets the user draw boxes on the bitmap, and saves the boxes' coordinates to a file that a converter uses. |
As I said, a semi-automatic conversion tool can be done. The user must specify the size of every sprite manually in some way.
#1526 - Splam - Sun Jan 19, 2003 9:05 pm
Mentioned this in another thread... My grabber can either take "minimum rectangle" areas drawn by the user or do it automatically. It removes any 8x8 pixel blocks and packs the rest together into 1 run of data, makes a header for the sprites which is a map of where actual 8x8 blocks exist and when it's being drawn my code can be set to either do it all as 8x8 sprites OR make the sprite out of the maximum size sprites it can (to reduce OAM usage and allow for more sprites per line). All done with 1d mapping so each sprite can be transfered with 1 dma. Only thing that causes problems with grabbing minimum rectanlges is you then need to position each frame in the correct place on the screen but my grabber contains an animation editor too which includes that info + collision info :)
#1983 - headspin - Mon Jan 27, 2003 1:26 am
If you have photoshop, you can make your sprites have the same palette in the same order by doing the following:
1. Load a sprite, set it to Image->Mode->Index Colour... and select the amount of colours you want (make sure this sprite has *all* the colours needed, otherwise paint a pixel with the extra colours needed. This will now set the colours & order of colours.
2. Load each sprite and "cut & paste" it onto the one created above and save, the sprite will now look the same, but the order of colours are forced to be the same as the one pasted to.
-or-
You can do like 1. but then save the palette, and load it for each sprite.
-or-
If you have got some time and patience download a program called pedit (Palette Editor) and you can change the order of your colours in your palette, but it's not easy.
#1984 - Splam - Mon Jan 27, 2003 1:45 am
There are some windows apps around that will do batch colour remaping/reduction etc can't remember the names (last time I used one was a looong time ago) but try searching on google and you should hit something.
#2001 - Phattso - Mon Jan 27, 2003 4:18 pm
Many thanks for the suggestions!
What I've actually done is code up a proprietary app to reindex the palettes for me. It's an automated version of what you suggested with Photoshop, headspin, but without having to open up each one of the hundreds of files manually. ;-)
It's a pretty messy tool, and damned slow considering how little it does, but I may fix it up and release it for others to use in the future. Having said that, I doubt there's much need for such a specific tool (TGA -> BMP -> RLE BMP with unified palette), and thus not worth spending any more time on making it half decent.
Still - the job is done now, and hopefully I'll never have to do it again! :)
Thanks again, folks!
#2008 - tepples - Mon Jan 27, 2003 5:37 pm
Of course, one of the advantages of 16-color tile modes is that the GBA reindexes the palettes for you in real time. If "Kirby", "Wario Land 4", and "Metroid Fusion" can get away with it...
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#2065 - Phattso - Tue Jan 28, 2003 4:37 pm
Indeed - very useful features in the tile modes (in fact, I'm constantly impressed with what people achieve using them).
We're working in Mode4, however, and using the full complement of colours. :)