Fading/gradients with Jaguar's palette

I'm working on a "small" tool for the jaguar that's just about ready, apart from the following: I want to be able to create 16-colour gradients in paletted mode (5-6-5 RGB), from one palette entry (grad1) to another (grad2). Because I wanted an easy way for the user to pick colours, I used the Windows built-in col selector which is 32-bit, to select grad1 and grad2. I keep grad1 and grad2 32bit internally and when it's time to generate the gradients, I convert them down to 16bit. Here's the (ugly) code that does both the conversion and gradient creation (with some redundant crap removed):

(so the code calculates the steps for r,g,b from the 8bit coefficients of grad1,grad4 and then creates the gradients by adding the step values to grad1's values, and then shifts them into place and masks them).

This nearly works, but there are some errors that are really visible on pure grey gradients; the green component seems to not keep in sync with the red and green, so some ugly stuff are being shown instead of shades of gray. From some reference palettes I have, I seem to be either spot-on or +/-1 when creating my palettes.

Anyone had any experiences with this? The only thing I wanted to try was to calculate the gradients using 16bit mode (5R,6G,5B) but I don't think that would change things much. Any input is appreciated!

What I'd do is work on 8 bit values for R, G and B (24BPP) until you absolutely need to convert them to 16BPP mode then weight them accordingly (in a final pass). Are stepr, stepg, stepb floating point variables in your code?

Well, I used to write code-that-does-everything-in-one-line like " col = (Shl&(Round(r1 + stepr * l / 8) And 255, 8 + 3) And $f800) + (Shl&(Round(b1 + stepb * l / 8) And 255, 3 + 3) And $7c0) + (Round(g1 + stepg * l / 4) And $3f)"but I find out that sometimes it led to strange behavior (missing parenthesis or compiler wrong interpretation)Now I write a step each line, and then I can track the value after each computation and verify that I did everything rightjust a suggestion %)

Oops, people replied . I'm sorry but I've been busy with other parts of the tool so I didn't notice...

Now then...

QUOTE (GroovyBee @ 21 Jan 2013, 13:56)

What I'd do is work on 8 bit values for R, G and B (24BPP) until you absolutely need to convert them to 16BPP mode then weight them accordingly (in a final pass). Are stepr, stepg, stepb floating point variables in your code?

Yup that's what I do.

QUOTE (Orion_ @ 21 Jan 2013, 16:16)

maybe it's because Green is 0-63 where as Red/Blue are 0-31.For my palettes I personally keep 24bits colors and convert them on Jaguar in 16bits using a little 68k routine

Not an option here I'm afraid, a pre-computed palette is required.

QUOTE (sh3-rg @ 21 Jan 2013, 17:36)

QUOTE (Orion_ @ 21 Jan 2013, 14:16)

maybe it's because Green is 0-63 where as Red/Blue are 0-31.

I suggested this but maybe he'll listen if it's coming from someone like you rather than me

QUOTE (Orion_ @ 21 Jan 2013, 20:33)

Well, I used to write code-that-does-everything-in-one-line like " col = (Shl&(Round(r1 + stepr * l / 8) And 255, 8 + 3) And $f800) + (Shl&(Round(b1 + stepb * l / 8) And 255, 3 + 3) And $7c0) + (Round(g1 + stepg * l / 4) And $3f)"but I find out that sometimes it led to strange behavior (missing parenthesis or compiler wrong interpretation)Now I write a step each line, and then I can track the value after each computation and verify that I did everything rightjust a suggestion %)

Yeah I know, I'm against franken-code like this, at the beginning it was a really simple line, but I kept adding stuff to it to see if it worked (as a proof-of-concept). I'll probably revisit that chunk of code tomorrow and make it less horrible!

Thanks for the tips, all (also on IRC)! Finally, for reference, here's a sample output for the r,g,b values using my routine (left) and the reference palette (right). I'll have another look tomorrow.

I don't have GFA32, so I tested it with gool old QBASIC. Note that FIX(x) always rounds down, not to the nearest integer (I tried adding .5 to round to the nearest integer, but it no longer matches the original gradient, though it's probably more accurate that way).

EDIT: oops, looks like what I thought was the original gradient is actually your version. Back to square one then...

EDIT 2 : If you look at the differences between successive colors, there's something strange in the original palette:

* the blue channel uses more than two values (-2, -1, 0) and it doesn't look like there's a recurring patternIIRC that can't happen if the interpolation is linear, even with rounding. So either they were doing some really strange rounding, or they didn't use a linear interpolation (maybe it's gamma-corrected or picked manually?)