Many of you probably knew that SourceCoder could convert images and sprites to 16-bit-per-pixel color_t arrays of 5-6-5 formatted pixels. I had previously added a feature to turn "grayscale" images into palette-based images, but I left it up to the programmer to define the palette. I have finally gotten around to updating SourceCoder so that it defines and outputs palettes for 8-bit, 2-bit, and 1-bit images; presumably I'll have to add 4-bit at some point, if people really, really need it. SourceCoder finds the first 256/4/2 colors in the image, uses that as the palette, and generates indexed image data. Enjoy!

http://prizm.cemetech.net/index.php?title=CopySpriteNBit

Awesome work, this will definitely prove super-useful for me in the future and of course, I definitely vouch for the usefulness of 4-bit encoding; many of the sprites I make have exactly 16 colors in their palette, and using the full 8-bit encoding is rather wasteful for that.

Yay! And is 16 colors mode + palette planned?

Sort of planned, if I feel like implementing it. As you guys know, I have a massive number of projects multithreaded through my work, schedule, and life. I would appreciate some testing, by the way; I didn't get a chance to test my new routine for N-bit sprites yet.

IS the universal n-bits sprite routine slower than the others?

I would expect it to be slightly slower due to the N-bit logic, yes. However, if you flatten it to a single bit-case for your particular purposes, it will be just as fast. You could even force GCC to do it for you by replacing the bitwidth argument with a #define, which would make GCC treat it as a constant and collapse the math together.

I just started using the N-bit routine in my RPG (Considering how much imagery I have, compression like this is absolutely necessary). I did encounter a few issues though.

First, the image data that SourceCoder generates for 8-bit images has too many commas. I have to delete commas from the beginning of every single line in the image data. The palette data does not have this problem.

Second, when I used a 24-bit bitmap SourceCoder was unable to generate a good palette, probably because it ran out of colors to use. Giving SourceCoder a 256-color bitmap fixed that problem.

Third, using the unmodified data generated by SourceCoder with the CopySpriteNBit routine from the wiki generates the following warnings:

Code:
Other than that everything works as advertised.

I really, really appreciate the ability to generate compressed image data for the Prizm. Without it my tilemaps alone are larger than the default amount of ROM that the compiler sets. Thank you very much for this amazing feature

1) Fixed the comma issue; that was a silly one on my part
2) That palette behavior is to be expected.
3) Mmm, dropped an extra "unsigned" in for the 8-bit, 2-bit, and 1-bit color data from SourceCoder

Thanks for the bug reports, and thanks for your gratitude.

You're welcome, this feature has really been a lifesaver.

I noticed that you said that you said that you could add support for 4-bit images. I don't need something like that right now, but I think I could put it to very good use later for NPCs, battle images, and attack animations. I do not plan to work on battles for a while but I think 4-bit imagery would be very useful for them.

Yeah, I could add it, if I didn't do so already (I don't think I did, did I?). It wouldn't be that bad.