(03-09-2014, 11:53 PM)AnyOldName3 Wrote: Well I'm glad the devs aren't the kind of people who having already tested the actual hardware with all possible inputs would just put all of these in a lookup table.
Sometimes the actual hardware itself uses lookup tables, you know
Just a quick update on the topic, I've today extended my testing code to also retrieve the upper 3 bits of the color combiner result, and it's actually fairly easy to see a pattern then.
a=0,b=127 case:
The "additive" constant has a jump at c=0x21,0x61,0xa0 and 0xe0. The corresponding output values (10 bit + 1 sign bit) are 65,192,319 and 446. It's easy to see that the distance between each of these is 127, and that 65 is the smallest integer greater than 128/2. Or seen differently, the last value for c which yields "expected" outputs is 0x20, for which we get the output 64, which is 128/2.
a=0,b=255 case:
The "additive" constant has a jump at c=0x21,0x61,0xa0 and 0xe0. The corresponding output values (10 bit + 1 sign bit) are 131,386,641 and 896. It's easy to see that the distance between each of these is 255, and that 131 is... well, not quite the smallest integer greater than 255/2. However, the last value for c which yields "expected" outputs is 0x20, for which we get the output 128, which is 256/2.
These are just the two special cases I looked at so far. Either way, it's a huge step forward compared to yesterday, where I couldn't even find any reasonable pattern for the a=0,b=255 case. Let's see how easily I can extend the pattern to arbitrary values
