Integer buffers had one byte, 8 bits, per colour channel, for 24 bits for RGB and 32 bits for RGBA. This could represent values from black to white. Blending between values could prove inaccurate, particularly in low ranges, resulting in posterisation, or prove tricky to balance the highs and lows without something get washed out.
Floating point buffers can represent much broader colour/intensity ranges. The end result might see an image with ranges from 0 to 65500 I think, including smaller deltas between values than 1. You could thus render a bunch of light sources that accumulate beyond the 255 upper limit of 24 bit integer colour. As a final step, this floating point buffer needs to be mapped onto the 24 bit integer display. Let's say the darkest value in our rendered buffer is 318, and the brightest is 5166, we'd map that so 318 is (0) and 5166 is (255), generally on a gamma curve (2.2?)
The conversion from fp buffers to int display buffers had different curves on the two platforms, with, IIRC, Xenos having a peculiar knee in a strange approximation.
Also, didn't fp16 on XB360 require too many tiles, and so it mostly used its custom fp10 format, IIRC?
Floating point buffers can represent much broader colour/intensity ranges. The end result might see an image with ranges from 0 to 65500 I think, including smaller deltas between values than 1. You could thus render a bunch of light sources that accumulate beyond the 255 upper limit of 24 bit integer colour. As a final step, this floating point buffer needs to be mapped onto the 24 bit integer display. Let's say the darkest value in our rendered buffer is 318, and the brightest is 5166, we'd map that so 318 is (0) and 5166 is (255), generally on a gamma curve (2.2?)
The conversion from fp buffers to int display buffers had different curves on the two platforms, with, IIRC, Xenos having a peculiar knee in a strange approximation.
Also, didn't fp16 on XB360 require too many tiles, and so it mostly used its custom fp10 format, IIRC?
