Figured I could get some neat effects by storing color data with 1 byte per pixel (xlibc palette), and then applying filters at display time. The result is the input data takes less space to store, but you'ld get more interesting results than just having the same palette all the time.

Anyways, to make it easy to test different effects I made this
http://z80.ukl.me/palette/
You can write JS code which runs on all the values from 0-255, and returns the high and low byte of the color separately. Click 'Regenerate' and the resulting palette will appear up top.

Fair warning: while the browser never GETs any external data, it does run whatever code is inside the box with eval() when you click the Regenerate button, so if you don't like that don't use it.

(also I'm not sure if this should go in the z80 programming section instead, but let me know one way or the other / move it if you need)

Somehow I completely missed this topic when you first posted it! It came up today because geekboy and I were discussing, prompted by tpw_rules asking why my xLIBC activities have a lot of dithering, if the high=low scheme that xLIBC uses is the best 256-color-palette approach. In fact, Merthsoft threw together http://merthsoft.com/color.html, which is very similar to what you made here, so I'm sorry that I didn't realize this already existed! Out of curiosity, what kinds of interesting effects did you discover? We explored inverting the byte and rotating it.

IIRC making the high byte always 0 gives a set of blue - black, making it 255 gives a nice set of yellow - white. I think there were some other neat ones but I don't remember off the top of my head.

Just messing around with it now, left-shifting the low byte 1 ( [col, col << 1] ) gives a palette that actually looks quite usable, as long as you dont need any super-green greens.

You could probably find a good palette that would make palette rotation viable to create a cheap animation (in terms of storage space, not execution time of course).

I'm wondering if adding something like two bytes as shifters for both the high and low bytes in a sprite routine might be a viable option. It would just require 2 extra bytes per image, and add a much greater range of colors. Of course, converting this could be challenging..?

Interesting idea, I might try to write a converter tomorrow to see how fast a brute-force method works

Heh, oops for duplicated effort. It is cool that we had a similar idea, though! The biggest difference is that yours has the user return high and low bytes, and mine has the user return RGB. I guess it's good to have both

Nice! I heard that it seems to work; but conversion time is pretty lengthy? I imagine that you could minimize time by scanning for the different amounts of R-G-B colors, and depending on which one, either R,G, or B holds the most substance of the picture, begin from there? That way you might not have to check all possible combinations? Good luck!

On IRC yesterday, he said that conversion took about half an hour, brute-forcing all possible combinations and finding the one with the lowest possible difference from the original. I suggested exploring gradient descent as a way of picking those two offset values (actually, I think there's only one independent variable, actually, isn't there? so there should only be 256, not 256^2, possible combinations)?