Quote:
PcValue = SnesValue * 255 / 31
Indeed, that's the correct way to do it - mapping linear values from 0 to 31 to another linear space from 0 to 255.
Quote:
Then I've read some stuff about replicating the top three bits into the bottom three bits to get to the full range. Which sounds totally random and nonsensical to me. Why should you ever do this?
It's not random, it's roughly equivalent to the formula you proposed. The forumula you call
bullshit nonsensical would be that :
Code:
pc_colour = (SNES_colour << 3) | (SNES_colour >> 2)
Which is equivalent to
Code:
pc_colour = (SNES_colour * 8) + (SNES_colour / 4)
Which is equivalent to
Code:
pc_colour = SNES_colour * 33 / 4
In both cases, we're linearly mapping colours by multiplying by an integer slightly bigger than 8, because multiplying by 8 leads to the problem that whites are not pure white. Whether this integer is 255/31 (8.2258) or 33/4 (8.25) is almost insignificant, since the new value will be rounded to an integer anyway.
I've tested this on excel. Basically it either makes no difference or there's a difference of '1' which is basically a rounding error. The first column is using the fraction 255/31, the second using 33/4, in both cases rounded towards 0 (floor).
Code:
0 0 0
1 8 8
2 16 16
3 24 24
4 32 33
5 41 41
6 49 49
7 57 57
8 65 66
9 74 74
10 82 82
11 90 90
12 98 99
13 106 107
14 115 115
15 123 123
16 131 132
17 139 140
18 148 148
19 156 156
20 164 165
21 172 173
22 180 181
23 189 189
24 197 198
25 205 206
26 213 214
27 222 222
28 230 231
29 238 239
30 246 247
31 255 255
As to why ZSNES did not map colours the proper way, I have no idea but the most likely explanation is that they were just lazy