Am Wednesday 15 July 2009 15:59:46 schrieb Brian Paul: > Is there any objection to changing exactRGBA to be more lenient? I'd > be just as happy to do that.
No objection from me, as you can imagine. > I can imagine cases in which it would be important to the user to be > able to write a precise RGBA value into the framebuffer. For an > 8-bit/channel framebuffer, glColor4ub() is the natural solution (and > this works fine today). For a deeper framebuffer, glColor4us() would > be next. So I can understand the motivation of the spec. I understand the motivation, too, but it's unfortunate that this part of the spec made its way in as is. It would be much more reasonable to have a requirement like the following: If you have an M bit framebuffer and you want to write an exact M-bit unsigned integer value, you get the desired result if you first periodically extend those M bits into a 32 bit (16 bit) value, and then feed that to glColor4ui (glColor4us). To explain what I mean by "periodically extend", consider the following example. Suppose we have an 11 bit framebuffer, and an input variable value contains the unsigned 11 bit value that we want to write as a greyscale color. Here's what you should do: uint32_t extended = (value << 21) | (value << 10) | (value >> 1); glColor4ui(extended, extended, extended, extended); So the bit pattern of the input value is simply repeated until we have to cut it off. Mathematically, this gives you exactly what you want, assuming that I made no silly mistakes (the reason behind that is that it is precisely what you get when performing the appropriate divisons in binary). In practice, it is still not entirely unproblematic - for example, normal floats do not actually have enough precision, which means we'd have to store color as double - but it's *much* better than the "take the uppermost bits" language that made it into the spec. In any case, the above is sane advice for application writers, as it will work both on OpenGL implementations that somehow special case for the exactRGBA language *and* on OpenGL implementations that simply follow the int->float- >int conversion rules like Mesa does. cu, Nicolai ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
