Getting pixel color

[fzammetti]

[refractor]

[damian]

A bit unrelated, but who actually invented 565 color? Is the extra green bit actually ever useful? Or is it just a way to round each pixel to a nice 16-bit integer? If so, how come there's no 655 or 556 color?

[refractor]

It's there to maximise the usage of 16-bits, really. The human eye is more sensitive to green than blue and red, so it makes sense to use the extra bit for more green hues.

However, a lot of display hardware will use an equal number of bits per colour anyway so it doesn't actually gain much (or anything) on devices like Pocket PCs (especially when the screens on devices like the earlier iPaqs are 12-bit in a 4bpp format).

[damian]

So it's not a bad programming practice to lose that green bit in calculations?

[refractor]

It's not a bad practice IMHO. Just be sure and make it always 0 or always 1. I've seen a lot of code that doesn't mask it properly and that can leave the bit "unstable" (again, not that it will actually matter or even be noticable on a lot of devices, but it's careless).

[fzammetti]

Thanks for the explanation ref, I now understand perfectly.

However, it leaves an important question in my mind: how can I gain access to the real RGB values of a surface? It seems obvious now that you can't get that once things are blitted to the screen, or the back buffer, but I assume there must be a way if you just have a surface with an image on it, right?

For things like fire effects and lens effects and the like, that is obviously required to properly do the interpolation required for those effects. Is there a way to get access to a pixel that returns a 24-bit value on a surface? Then I should just have to mask out each byte to get my RGB values, right?

Or am I missing the obvious again somewhere and screwing this all up?

[refractor]

I'm guessing here, again (I've not played with pocketfrog), but if the surfaces are 16bpp then your 24-bit data is lost (as you said). The only way you're going to get it back is to not lose it in the first place (i.e. work in 24-bit in the code and down-convert onto the screen buffer)... but...

Why do you particularly want to use 24-bit? Why not just work in 16bpp to begin with (using 5 bits per colour rather than 8 )?

[fzammetti]

Well, I guess that my understanding of some basic concepts here is lacking...

When I have my images in Paint Shop Pro or Photoshop or whatever, my colors are specified as RGB values where R, G and B can each have a value of 0-255. Ok, this is all obvious. That of course is 8 bits per color channel, yielding 24-bit color. Ok, now stop saying "duh, what a moron!" and let me continue...

If I use 16-bit color as you say, does this mean that, assuming 565 format where red gets 5 bits, green 7 abd blue 5, that my red channel cannot have a value greater than 31. green no greater than 63 and blue no greater than 31? This is the part I obviously don't get because if that was the case, nothing would work right!

The ironic thing is that all my images are paletized to 256 colors, but the colors themselves are still specified as 24-bit colors I think.

So obviously my brain ain't working quite right here...

[refractor]

[fzammetti]

[Pam]

[fzammetti]

[Pam]

[refractor]