• Advertisement
Sign in to follow this  

DXGI_FORMAT_R16G16B16A16_FLOAT SWAP CHAIN

This topic is 1243 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was having a problem, I could see the gradient from black to white, more near the blacks

So I changed the swap chain to a 16 bit float but now everything is more white

what can I do?

 

DXGI_FORMAT_R8G8B8A8_UNORM

uqdQ3mJ.png

 

DXGI_FORMAT_R16G16B16A16_FLOAT

YPJBnf4.png

Edited by lomateron

Share this post


Link to post
Share on other sites
Advertisement
That's too little information to diagnose the problem. There are a few number of things that can go wrong:

sRGB was enabled
Your pixel shader is emitting values outside the range [0;1] thus was getting clamped
You're uploading data from CPU and now you forgot to account the change in bpp size

Share this post


Link to post
Share on other sites

I just change the format of the swap change and that happens

sRGB was enabled? how?

Your pixel shader is emitting values outside the range [0;1] thus was getting clamped?

but the pixel shader value always gets clamped in the end in those two formats,no?

You're uploading data from CPU and now you forgot to account the change in bpp size ?

no, all the colors you see in the image are created in the shaders

Share this post


Link to post
Share on other sites

Just posting some information -

 

Interesting observation, lomateron. It apparently has nothing to do with shaders as I can get the same type of change rendering just the backbuffer cleared to the same color for both R16xx && R8xx as you have observed.
 
Note that the R8xxUNORM is a bit pattern format, whereas the R16xxFLOAT is, well, floating point.
 
I'm not claiming to understand why it occurs - just noting that the docs for ClearRenderTargetView (which takes a 4 float array for the color) states:
 

Applications that wish to clear a render target to a specific integer value bit pattern should render a screen-aligned quad instead of using this method. The reason for this is because this method accepts as input a floating point value, which may not have the same bit pattern as the original integer.


That implies that the bit pattern for integer formats created from the floating clear color may not produce the same color.

 

Just FYI: clearing the backbuffer with clear color = (0.0f, 0.125f, 0.3f, 1.0f), doing a screen print, opening Paint, ctrl-V and sampling the color yields:

 

R16G16B16A16_FLOAT
with clear color 0.0f, 0.125f, 0.3f, 1.0f
Hue 133
Sat 240
Lum 70

Red 0
Green 99
Blue 149

DXGI_FORMAT_B8G8R8A8_UNORM and DXGI_FORMAT_R8G8B8A8_UNORM
same clear color

Hue 143
Sat 240
Lum 36

Red 0
Green 32
Blue 76 (blue 77 with DXGI_FORMAT_R8G8B8A8_UNORM)

Edited by Buckeye

Share this post


Link to post
Share on other sites

That implies that the bit pattern for integer formats created from the floating clear color may not produce the same color.
 
Just FYI: clearing the backbuffer with clear color = (0.0f, 0.125f, 0.3f, 1.0f), doing a screen print, opening Paint, ctrl-V and sampling the color yields:
 
R16G16B16A16_FLOAT
with clear color 0.0f, 0.125f, 0.3f, 1.0f
Hue 133
Sat 240
Lum 70

Red 0
Green 99
Blue 149

DXGI_FORMAT_B8G8R8A8_UNORM and DXGI_FORMAT_R8G8B8A8_UNORM
same clear color

Hue 143
Sat 240
Lum 36

Red 0
Green 32
Blue 76 (blue 77 with DXGI_FORMAT_R8G8B8A8_UNORM)

Green => 255 * 0.125 ^ (1/2.2) = 99.09
Blue => 255 * 0.3 ^ (1/2.2) = 147.52

Which is really close to the 99 and 149 values you got. I'm simplifying as gamma = 2.2; though sRGB is actually a piecewise linear function.
This is a linear vs sRGB problem.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement