Going back to the 32 bit thing. Those 8 extra bits are used to store info known as "alpha channel". This channel, unlike the RGB ones, is not visible, it serves to specify how opaque pixels are, a great tool for creating things like decals, special effects, etc. Since the data already comes linked to the image, you dont need to spend a whole new pass in order to retrieve this information from the RAM.
A game like DooM3 is using more than 20 texture passes right now, wich means the game will be almost unplayable on older GeForces and feature-disabled on 3dfx and/or ATi cards.
This passes explanation had to be done in order to explain precision. Imagine youre making 20 passes over a pixel. Why? it doesnt matter now, but Carmacks doing it. Now, the only thing you can make to a pixel is changing its color. You have the input color, wich is based on the texture youre using for that polygon. This data is commonly refered as RGB values, and they are often valued as 3 numbers ranging from 0 to 255 (the Red, Green and Blue components). However, in OpenGL, these 256 variations for each tone are expressed in a real number located between 0 and 1 (This was done for greater speed on calculations).
The math involved on pixel lighting and stuff is very complex to act as an example. To show the precision problem, I will use a simple equation.
For some reason I want to reduce in half the brightness of a pixel several times. Each time I do it is a pass. We have 1 as the first value, and this will be the result after 5 passes.
1 : 1 / 2 = 0.5
2 : 0.5 / 2 = 0.25
3 : 0.25 / 2 = 0.125
4 : 0.125 / 2 = 0.0625
5 : 0.0625 / 2 = 0.03125
0.03125 would be the real result of the calculation. However, these RGB values dont have that much precision. Imagine that the system just processes 2 digits after the 0 :
1 : 1 / 2 = 0.5
2 : 0.5 / 2 = 0.25
3 : 0.25 / 2 = 0.12
4 : 0.12 / 2 = 0.06
5 : 0.06 / 2 = 0.03
0.03 is very distant from 0.03125, and that error will be visible in the screen. Since there are many numbers close to "1" that will finish receiving a result of "0.03" many pixels that should look like a gradient of shades will have the same color. This is called "banding" cause the light intensity on the surfaces changes after a couple of pixels, making concentric "rings" of different intensity. This wont be too noticeable on DooM3, Carmacks making everything he can to diminish the effect, altough this would be awfully noticeable when several lights are placed almost in the same coords (for more info about this check Carmacks .plan file).
In conclusion, what good would 64 bit precision do? With these extra bits, developers are able to store the rest of the digits involved in the operation. This is called "mantissa" (this is how ancient romans called fractional portions of a number). This little inconvenience may sound problematic, but the whole new world that dynamic lighting provides to developers, modders and gamers will be so dramatic that the problem will not be a priority until several years.
Facebook
Twitter