Maxim Said: PNGOUT works by doing a more intensive search for high compression, and also by dropping unneeded parts of the file (eg. metadata), and trying to re-order/optimise the palette to give more compressible data. It can also reduce the bit depth in cases where it is lossless (eg. reducing a 200-colour 24-bit image to an 8-bit paletted image). It is possible to gain more by brute-force iteration through other parameters (eg. some 4-bit images compress better at 8bpp) but it's generally too slow to bother with that. In all cases, it is always lossless.
The slicer/splicer can be useful, especially for finding mistakes, but I find the sheer volume of tiles hard to manage; a GUI might help there.
Indeed. That's one of the major features I plan on implementing. It will shade the image according to tile frequency, so the uncommon ones will stand out.
Revned Said: Maxim Said:
The slicer/splicer can be useful, especially for finding mistakes, but I find the sheer volume of tiles hard to manage; a GUI might help there.
Indeed. That's one of the major features I plan on implementing. It will shade the image according to tile frequency, so the uncommon ones will stand out.
That sounds incredibly awesome. I've had to work with hundreds of tiles before.
(When I was making the Star Trek To Star Wars wallpaper images, I ran the splicer/slicer on the one I made for 800 x 600. It didn't work because 600 isn't a multiple of 16, so I changed it to 800 x 608. It came out to exactly 1000 tiles...neat! A coincidence, that. Though that wasn't the same situation as a game map (i.e. not made of repeated tiles).)
The slicer/splicer was instrumental in making the Super Kid Icarus maps, as I mentioned before, probably, and I also used your slicer/splicer to check for errors when making the Oracle Of Hours maps. I didn't make too many errors, but it allowed me to find the few I did. I think I did really well for not working with a grid, but nobody's perfect. But thanks to the slicer/splicer, my maps are! :D
Or at least closer to "perfection" than if I hadn't used it.
Maxim Said: You seem confused about colours. PSP will count the number of unique colours in the image. If you reduce it to some smaller number, you are throwing away some of the colour information. This might be an acceptable tradeoff in some situations but for game mapping it certainly is not.
An inefficient paletted image might have "duplicate colours" in its palette, but it's not hard to avoid that; just convert to true colour and back to paletted, or use PNGOUT.
As for reducing the file size by resaving in a different program: that's hardly surprising, but you will still get significant improvements by using a dedicated compressor like PNGOUT/PNGGauntlet, compared with pretty much any image editor's compression routines.
PSP(7) can do a passable version of "tile stamp mode" if you turn on the grid and snap to grid. Its texture fill mode also gives you a "stamp flood fill" feature which I find extremely handy.
I'm not confused really. Before I reduce the colors I always have to change to a high color mode before reducing the palette back anyway and when reducing after, no colors are lost, only the unique colors are left which are the only colors in the original palette of the image. I've never seen a difference with 256 color images when I have done that. I never argue when reducing high color images to 8 bit. If the image uses more than 256 colors I never reduce them.
I haven't used the grid, tile stamp mode with psp. It's much quicker with Character maker not having to past in each new stampable tile and stamp it.