Is there a way to do this without making any changes to the actual pallete? (probably not).
I want to be able to blur images using a regular gradient pallete. But how do I get the sprite editor to realise that "red and blue make green" without making changes to the pallete?
You can use a fake true colour palete, like a 3-3-2 palette (3 bits red, 3 bits green, 2 bits blue).
I have absolutely no idea what that means...
It means you make a palette that spans the full color spectrum so you can fake RGB
Code:
out &h3c8, 0
for r = 0 to 7
for g = 0 to 7
for b = 0 to 3
out &h3c9, r * (63 / 7)
out &h3c9, g * (63 / 7)
out &h3c9, b * (63 / 3)
next b
next g
next r
function pal (r, g, b)
pal = r * 32 + g * 4 + b
end function
The other way is to make an rgb array table based on nearest colors to any palette. takes a few k of memory, though, and a lot of calculation to make the table (best to save it to a file or something).
Code:
dim pal (15, 15, 15) as integer
for r = 0 to 15
for g = 0 to 15
for b = 0 to 15
curcolor = 0
maxdistance& = 999999999
for x = 0 to 255
out &h3c7, x
tr = inp(&h3c9)
tg = inp(&h3c9)
tb = inp(&h3c9)
dr = tr - (r * (63 / 15))
dg = tg - (g * (63 / 15))
db = tb - (b * (63 / 15))
distance& = dr *dr + dg * dg + db * db
if maxdistance& < distance& then
curcolor = x
maxdistance& = distance&
end if
next x
pal(r, g, b) = curcolor
next b
next g
next r
after that rgb(r, g, b) will give you the closest match for that array.
but, of course, both of these are pretty slow. Best option is to hack it with sprites or use a monochrome palette for blurring and such.
EDIT: fixed a bug. sorry.
Don't need an even full color spectrum. Even is best, though.
Let's go to the definition of blurring, shall we? Now, I'll define it as this:
Take four pixels that are adjacent to each other and make their colors more alike in RGB. That's your basic blur, I think. Now you can make variations, like using 16 pixels, or subsequently blurring 4 pixels in certain overlapping patterns...
The RGB will be produced, in above scheme, by looking at the average of all the RGBs in the 4-pixel area and the current pixel, and then taking the average (or you could set it to a certain percentage [sp??]) of that.
When you're blurring you want to find the closest match to a certain RGB color. There are at leasttwo ways to do that.
The easiest (but very slow, potentially) way is just going through each pixel in your palette each time, and finding the difference from the color you want. You want to use the square difference, like so:
Code:
'c = the color you want to match to.
smallestdiff& = (R(1) - R(1))^2 + (G(1) - G(1))^2 + (B(1) - B(1))^2
FOR i = 2 TO bla
diff& = (R(i) - R(c))^2 + (G(i) - G(c))^2 + (B(i) - B(c))^2
IF diff& > smallestdiff& THEN smallestdiff& = diff&: j = i
NEXT i
PRINT "closest match>"; j
Now, the second way to do this is to precompute all the possible color matchings and then use an array to match them up. You can do the same formula as above, changing the color "c" each time.
PS: Toonski, your code was indented so much I couldn't even realize you were saying almost the same thing until now. The only difference is you're not squaring. You really should square .. 8)
Why? Just extra calculation. We're going for relative distance when you want to calculate the nearest point, not accurate distance.
if x > y then sqr(x) > sqr(y). Plus, I can still use integers (though that doesnt really make a difference if you're using ffix or the like)
Er, it does make a difference. What would you rather prefer when matching to a pure red, something that is purple or something that is a bit more green and a bit more blue? Well. er.... bad example.. the squaring penalizes you for being too far off the mark . . .
I don't really see what your x and y comparison had anything to do with it, though. . .