🔒 Locked

DX8: display formats, back buffer formats, render targets?

Started by Boris Karloff Sep 9, 2003 at 9:21 AM 9 replies 4k views

Original Post

Sep 9, 2003 at 9:21 AM

I''m completely flabbergasted as to setting up DX Graphics and picking the proper D3DFORMAT. The DX SDK tells of display mode formats and back buffer formats. Where do I set the display format? AFAIK, the only format you get to set when creating the device is the back buffer format, in the present parameters. And logic dictates to me that this is the same thing as the display format. But a function like IDirect3D8::CheckDeviceType needs -two- formats: A back buffer format and a display format. So apparently they are two different things. So where do you set the display format? In what situations it different than the backbuffer format? And if they''re always the same... Why the two different arguments for CheckDeviceType? Also, the SDK speaks of render targets without properly explaining what they are. I assume they are surfaces that can be rendered to? Like the back buffer? If that is true, then what about this statement in the SDK help: "Render target formats are restricted to D3DFMT_X1R5G5B5, D3DFMT_R5G6B5, D3DFMT_X8R8G8B8, and D3DFMT_A8R8G8B8." So does that mean you can only set the back buffer to one of those four formats? Is is impossible to do Alpha blending in 16-bit mode then? And what are all those other formats (like R5G5B5 or A1R5G5B5) for, if you can''t use them as back buffers? Questions, questions! In short... What, exactly, falls under the category ''render targets''? Where do you set the display format and when would it be different than the back buffer format? And if they''re the same, why does CheckDeviceType ask for both the display -and- the back buffer format?

KershAtWork

Sep 9, 2003 at 11:39 AM

Display modes are usually the same as the backbuffer modes and are usually set to be the same. It not a requirement to have the back buffer format be the same as the display mode as the graphics card will do the necessary conversion.

So the function CheckDeviceType''s only purpose is to see if the device can use that mode with the type of device requested (HAL, SW, REF). So if you are requesting a HAL device to work with a windowed application, I recommend that your backbuffer format is the same is your display format, but again this is not a requirement).

A rendertarget is exactly what you describe, sort of. It is a buffer in memory that you can present to. You can write to most textures, but you cannot present to that texture (swap buffers) unless they have been created with a render target usage. The purpose of this terminology is just so the graphics card can understand that you want to make frequent updates to the surface and will place the memory in the correct place.

Hope this helps,
/jk

Boris Karloff

Sep 9, 2003 at 4:26 PM

quote:
Original post by KershAtWork
Display modes are usually the same as the backbuffer modes and are usually set to be the same.

-Where- are they set to be the same?

quote:
Original post by KershAtWork
It not a requirement to have the back buffer format be the same as the display mode as the graphics card will do the necessary conversion.

So how would I set a different display mode? present-parameters only specify the back buffer format. Where does the display format get set?

Thanks for the help... It seems like I''m getting there... But nobody has yet been able to tell me why I would want to set the display format to a mode different than the back buffer''s mode, and I still don''t know -how- to set it to something different. All I get to set is the back buffer mode!

KershAtWork

Sep 9, 2003 at 4:37 PM

You only set the display format if you are creating a full screen "exclusive" application. In that case, the display mode is set to the backbuffer format.

In the case where you have a windowed application, than you can can''t set the display mode, but you can set the backbuffer format to a different format than the current display mode.

This makes sense because of this: imagine that you shipped your windowed application to use 16 bit color and all your textures were 16 bit color. If the target user of your application is using a 24/32 bit display mode, than your application cannot run. Rather the video driver will convert as necessary. When running a windowed application, you do not have the privilidage to change the display mode since you are not taking exclusive control of the display device.

If at all possible, in a windowed application, you will find the current display mode and set the backbuffer to that format. Hope this helps,
/jk

Boris Karloff

Sep 9, 2003 at 4:48 PM

quote:
Original post by KershAtWork
You only set the display format if you are creating a full screen "exclusive" application. In that case, the display mode is set to the backbuffer format.

Okay then. So let me see if I get this... When windowed, you can''t set the display mode (obviously), but you can set the backbuffer, which gets converted. When full screen, you can set both, but they''re -always- the same (since dispmode gets set to bb format), right?

So when full screen, the display mode can -only- be A8R8G8B8, X8R8G8B8, R5G6G5 or X1R5G5B5, right? Because those are the only valid BB formats?

Am I right? Thanks for the help!

Muhammad Haggag

Sep 10, 2003 at 12:10 AM

quote:
Original post by Boris Karloff
Okay then. So let me see if I get this... When windowed, you can't set the display mode (obviously), but you can set the backbuffer, which gets converted. When full screen, you can set both, but they're -always- the same (since dispmode gets set to bb format), right?

Yes. So CheckDeviceType takes a DisplayFormat to ensure that - in the case when a windowed application's going to use a back-buffer format other than the desktop format - the hardware can do the color conversion. If it fails on you, you have to choose another back-buffer format (or resort to the desktop format).

For full-screen: The docs for CheckDeviceType say that DisplayFormat and BackBufferFormat *have to* be the same for full-screen.

quote:
So when full screen, the display mode can -only- be A8R8G8B8, X8R8G8B8, R5G6G5 or X1R5G5B5, right? Because those are the only valid BB formats?

Yes and No. The display format can't have alpha, yet the back-buffer format can. In the DX9 docs, the "D3DFORMAT" page:

Format      Back-buffer Display 
A2R10G10B10 x             x (full-screen mode only) 
A8R8G8B8    x  
X8R8G8B8    x             x 
A1R5G5B5    x  
X1R5G5B5    x             x 
R5G6B5      x             x

Now, while we're on the topic: What about floating-point textures? I thought we could render to these?

[edited by - Coder on September 10, 2003 1:12:53 AM]

Boris Karloff

Sep 10, 2003 at 2:17 AM

quote:
Original post by Coder
Yes. So CheckDeviceType takes a DisplayFormat to ensure that - in the case when a windowed application''s going to use a back-buffer format other than the desktop format - the hardware can do the color conversion. If it fails on you, you have to choose another back-buffer format (or resort to the desktop format).

For full-screen: The docs for CheckDeviceType say that DisplayFormat and BackBufferFormat *have to* be the same for full-screen.

Great, but....

quote:
Original post by Coder
Yes and No. The display format can''t have alpha, yet the back-buffer format can.

Uh... Okay.. I get it all up to one point...

-Where- do you set the display format? Suppose I want to use a A8R8G8B8 backbuffer... And I want to set the display to X8R8G8B8...

I''d set present_parameters.BackBufferFormat to A8R8G8B8... But what would I do with the X8R8G8B8 value? Where does that go? There''s no value for it in present_parameters, so when does the display get to know that it should use X8R8G8B8?

Muhammad Haggag

Sep 10, 2003 at 12:26 PM

quote:
-Where- do you set the display format? Suppose I want to use a A8R8G8B8 backbuffer... And I want to set the display to X8R8G8B8...

I''d set present_parameters.BackBufferFormat to A8R8G8B8... But what would I do with the X8R8G8B8 value? Where does that go? There''s no value for it in present_parameters, so when does the display get to know that it should use X8R8G8B8?

Full-screen:
The display format is set as specified by the back-buffer format. In full-screen (exclusive d3d mode), d3d sets the display format to be the same as the back-buffer format.

Windowed:
You don''t specify the display format. That''s what the user does himself via "Display Properties->Settings".
What you *can* do in windowed mode is specify the back-buffer format. Thus, you need to make sure that the back-buffer format you want is *compatible* with the current display format (i.e. the hardware can do color conversion between the two).

Boris Karloff

Sep 10, 2003 at 5:47 PM

quote:
Original post by Coder
Full-screen:
The display format is set as specified by the back-buffer format. In full-screen (exclusive d3d mode), d3d sets the display format to be the same as the back-buffer format.

Erm... So what if I specify A8R8G8B8 to be the back buffer format? The display format can''t contain alpha, so it can''t always be the same as the back buffer format.

Muhammad Haggag

Sep 10, 2003 at 11:26 PM

quote:
Original post by Boris Karloff
quote:
Original post by Coder
Full-screen:
The display format is set as specified by the back-buffer format. In full-screen (exclusive d3d mode), d3d sets the display format to be the same as the back-buffer format.

Erm... So what if I specify A8R8G8B8 to be the back buffer format? The display format can't contain alpha, so it can't always be the same as the back buffer format.

Doh! Sorry for the confusion:
D3D sets the display format to be the same as the back-buffer format without the alpha.
i.e. back-buffer = D3DFMT_A8R8G8B8 -> display = D3DFMT_X8R8G8B8

quote:
From the CheckDeviceType documentation, the "Remarks" section
Full-screen applications should not specify a DisplayFormat that contains an alpha channel. This will result in a failed call. Note that an alpha channel can be present in the back buffer but the two display formats must be identical in all other respects. For example, if DisplayFormat = D3DFMT_X1R5G5B5, valid values for BackBufferFormat include D3DFMT_X1R5G5B5 and D3DFMT_A1R5G5B5 but exclude D3DFMT_R5G6B5.

[snip]

Using IDirect3D9::CheckDeviceType to test for compatibility between a back buffer that differs from the display format will return appropriate values. This means that the call will reflect device capabilities. If the device cannot render to the requested back-buffer format, the call will still return D3DERR_NOTAVAILABLE. If the device can render to the format, but cannot perform the color-converting presentation, the return value will also be D3DERR_NOTAVAILABLE. Applications can discover hardware support for the presentation itself by calling IDirect3D9::CheckDeviceFormatConversion. No software emulation for the color-converting presentation itself will be offered.

[edited by - Coder on September 10, 2003 12:28:01 AM]

Boris Karloff

Sep 11, 2003 at 3:02 AM

Ah! Finally! Excellent, thanks very much for explaining that..

The DX9 documentation looks a lot more informative than the DX8.1 documentation... It doesn''t this issue at all. Looks like it might be wise to switch to the new SDK sometime soon...

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.