Choosing mode with framework dialog
Hi there,
When the frame work is entering the information about the available video modes into the combo box which displays them in the ''choose device'' dialog, it assumes that the format of the mode is 16 bits and then changes this to 32 bits if the format is one of the following...
D3DFMT_R8G8B8
D3DFMT_A8R8G8B8
D3DFMT_X8R8G8B8
Firstly, one of these is 24 bits!
Secondly, the doc says...
''Render target formats are restricted to D3DFMT_X1R5G5B5, D3DFMT_R5G6B5, D3DFMT_X8R8G8B8, and D3DFMT_A8R8G8B8.''
Thus why is D3DFMT_R8G8B8 in the above list?
Cheers,
BD.
That''s a good question, I guess I''m a bit confused on the subject myself... as to what the difference is between D3DFMT_R8G8B8 and D3DFMT_X8R8G8B8. I''m guessing that they are both the same except for how data is stored and transferred to the video card? The 24bit version on the left would seem to be more efficient than its counterpart sense it doesn''t transmit an extra 8 bits per pixel. Though perhaps computer architectures are so optimized for tranferring 32bit values that this really isn''t an issue. Also, am I correct in referring to D3DFMT_R8G8B8 as a 24 bit and D3DFMT_X8R8G8B8 as a 32 bit?
Brett
Brett
There are a couple of other 32 bit formats in the doc too....
D3DFMT_A2B10G10R10
D3DFMT_G16R16
If these are no good for render targets ( I presume a back buffer counts as a render target ), then what are they for?
If they are good for render targets, then why aren't they in the above mentioned framework code?
If they are good for nothing then why are they in the doc?
Cheers,
BD.
[edited by - Barn Door on September 12, 2002 11:10:25 PM]
D3DFMT_A2B10G10R10
D3DFMT_G16R16
If these are no good for render targets ( I presume a back buffer counts as a render target ), then what are they for?
If they are good for render targets, then why aren't they in the above mentioned framework code?
If they are good for nothing then why are they in the doc?
Cheers,
BD.
[edited by - Barn Door on September 12, 2002 11:10:25 PM]
you enumare them all by hand ofcourse and see what the user chooses (thats what i do) however, its kindof important havling internal blitters for it aswell, since it might require same pixelformat later on as in textures or similair..
to get lots of blitters and such you could use hermes from gaffer.org or prophecy sdk from twilight3d.com (both are free)
Secondly i would like to point out some reasons why you wanna write your own framework:
1) Full control over all creations later on and what formats being used
2) Full control over how you manage your primary backbuffer and such, like in a program where you want ''viewports'' as different backbuffers, all this can be done via modifying the init parameters to d3d , wich is sometimes a great idea
3) You will most likely want your framework to be quite "free" so you can use it everywhere and that includes having it linked dynamically and similair.
There lots of more reasons aswell but i really cant bother writing more, and i need to get some more beer.
to get lots of blitters and such you could use hermes from gaffer.org or prophecy sdk from twilight3d.com (both are free)
Secondly i would like to point out some reasons why you wanna write your own framework:
1) Full control over all creations later on and what formats being used
2) Full control over how you manage your primary backbuffer and such, like in a program where you want ''viewports'' as different backbuffers, all this can be done via modifying the init parameters to d3d , wich is sometimes a great idea
3) You will most likely want your framework to be quite "free" so you can use it everywhere and that includes having it linked dynamically and similair.
There lots of more reasons aswell but i really cant bother writing more, and i need to get some more beer.
HAHA theres this next/prev buttons, i thought it was for pages in the thread, now i answered on 2 threads in one.. damn i need to sober up :D
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement