No DX9 16bit Graphic modes.

BlitzMax Forums/BlitzMax Programming/No DX9 16bit Graphic modes.

Richard Betson(Posted 2011) [#1]
I may have missed something but I get no 16 bit color modes available on two different systems in DX9. Using this code will only list 32bit modes.

Print "Available graphics modes:"

For mode:TGraphicsMode=EachIn GraphicsModes()

	Print mode.width+","+mode.height+","+mode.depth+","+mode.hertz

Next



One systems an older XP with NVidia g4 mx 440 and a Win 7 with a NVidia Gforce 6150 SE. Is there a NVidia problem?

Thanks,


col(Posted 2011) [#2]
Hiya,

Its not a problem with the Gfx card at all.
BRL have made only 32bit modes available in DX9.

I'm guessing this is just because to make things easier with the Max2D textures and colors etc. but I stand to be corrected.

Last edited 2011


Richard Betson(Posted 2011) [#3]
That explains a lot. ;)

Thanks,


kfprimm(Posted 2011) [#4]
I've already run into a similar issue when working with the D3D9 driver concerning the lack of depth and stencil buffering. The issue exists because only 32-bit formats are enumerated as evidence at line 311 of d3d9graphics.bmx (BRL.DXGraphics):
Local n=_d3d.GetAdapterModeCount( D3DADAPTER_DEFAULT,D3DFMT_X8R8G8B8 )

Throughout the module, the only format ever used is D3DFMT_X8R8G8B8.

Here are a list of all formats. D3DFMT_X1R5G5B5 or D3DFMT_R5G6B5 are probably the best choices for 16-bit.

As a note, here's a fix that'll add depth and stencil buffering. A similar solution could be created to allow 16-bit backbuffer formats.
https://github.com/kfprimm/maxb3d/wiki/BRL.DXGraphics-and-BRL.D3D9Max2D-Tweak


kfprimm(Posted 2011) [#5]
Here's a quick solution but untested (nor compiled) because I'm on my Linux box and don't have a Windows machine close by.

In TD3D9GraphicsDriver.Create, replace the graphics mode enumeration code with this,


In OpenD3DDevice, modify it with this,

I plan on testing this later.


col(Posted 2011) [#6]
I think you'll find there will be more needed than just setting the display resolution and format to 16bit modes.

The whole of Max2D is built and coded with 32bit graphics in mind, which includes the OpenGL side too. You may end up with difficult to find problems and possible gfx bugs/gfx anomalies with images and textures etc further down the line.

And don't forget about loading images that arent in the format you've proposed ? There are many options for 16bit other 5bits for R, G and B and 1 bit alpha. All images loaded that are 16 and 32bit will need converting to this format to display correctly.

If you look through the source you find thats exactly what BRL do when loading images into 32Bit. They convert the image to a 'BRL standard' format.

Already a bug is that the Direct3D interface doesnt even close unless an attempt to create a Direct3Device fails. Maybe thats the root cause that people have been having in regard to switching resolutions ??? Maybe not, I've not tested it.

Anyway, theres so much more than meets the eye with the DirectX setup that BRL have used. Dare I say - It almost seems rushed!

But again - I stand to be corrected.

Also, for those developing using Direct3D directly, use the PIX software than comes in the DirectX SDK - Its an awesome piece of software.

Last edited 2011


kfprimm(Posted 2011) [#7]
BlitzMax/mod/brl.mod/dxgraphics.mod/d3d9graphics.bmx


Anybody wanna test this out? I can enumerate 32 and 16 bit modes and the firepaint example works with both.

EDIT: Found out it would always select 16bits in windowed mode. Fixed .
EDIT: Applied col's version fix.

Last edited 2011


col(Posted 2011) [#8]
Works ok here.
I tried most of the samples too, forcing them to use this driver and 16bit, they work ok too.

So, I stand corrected :o)

Sony Vaio VGN-FW31M


[EDIT]
Just for information :-

Direct3D is being created with the wrong parameter.
Line 347-

_d3d=Direct3DCreate9( $900 )

The $900 parameter is incorrect.
The $900 is used in the c++ header files to include the D3D9 interfaces.

If you use any DirectX monitoring software, it will complain about a conflict of versions.

The correct value is a value defined in the SDK ( D3D_SDK_VERSION which equals 32 )
so setting this to -

_d3d=Direct3DCreate9( 32 )


will allow you to use monitoring and debug software on your exe.

Last edited 2011


kfprimm(Posted 2011) [#9]
Updated with that! Awesome, thanks.


Richard Betson(Posted 2011) [#10]
WOW!!

Thanks kfprimm and col. This seems to work fine so far. I even get all the 16bit modes that are available with GraphicModes() and GraphicModeExists(). I have a few beta testers and several computers here I'll try it out on and let ya know.

Need to archive this.

Great work,


joncom2000(Posted 2011) [#11]
In my directx sdk the value of D3D_SDK_VERSION=32 but to call directx9 directly it is defined as DIRECT3D_VERSION=0x0900 this is ofc because D3D_SDK_VERSION changes as you get newer sdk's so the code isnt wrong to use the original value to specify directx 9


col(Posted 2011) [#12]
@joncom2000

When you create a Direct3D9 interface, you're not supposed to use the DIRECT3D_VERSION constant. You are supposed to use D3D_SDK_VERSION constant.

If you look in the SDK documentation, this is clearly stated,
I've never seen any code that uses the DIRECT3D_VERSION constant when using creating Direct3D9 interface.

In the SDK header file, the DIRECT3D_VERSION constant is only ever checked and used whether to include the contents of that header file or not, ie to include the code to expose the whole of Direct3D9.

What do you mean by
to call directx9 directly

?? Using the .dll instead of .lib ?

Last edited 2011


joncom2000(Posted 2011) [#13]
I dont disagree that we should really be using D3D_SDK_VERSION constant, but we are not actually building with the official dx sdk or even a full conversion of it. I suspect there's a few other constants missing since the dx files with bmax arent complete and probably some might be wrong.

But why is this constant defined "Const DIRECT3D_VERSION9=$900" in the pub.d3d9 module code and then the create graphics for the driver has it hardcoded as $900. Infact that constant isnt even used anywhere that I can find.


col(Posted 2011) [#14]
Hiya,

but we are not actually building with the official dx sdk or even a full conversion of it

Yes, you are right, but we are accessing the full complete release version of it ( ie the DLL ), so it should be respected that it needs compliance to work correctly.

But why is this constant defined "Const DIRECT3D_VERSION9=$900" in the pub.d3d9 module code and then the create graphics for the driver has it hardcoded as $900

Only BRL would know the real answer to that question.

I've made a daring statement in the past saying that the D3D9 module seemed... well... rushed.
This is just one example that backs up my statement. Over time, many people have had varying problems with it, and some of the main issues have been fixed either by BRL or the community.

If you compare the DX7 module source with DX9 module source, you'll notice there is a lot more error checking going on in the DX7 module. It just reads to be so much more complete and robust.

Changing the source of the topic slightly ... I've even seen mistakes with redundant textures and redundant shader calculations used in the Unreal3 editor whilst looking through the examples!! So I guess we're all prone to being just regular human beings after all, and we can all make mistakes, leaving things in or taking them out.

:o)


Richard Betson(Posted 2011) [#15]
I just wanted to let you know that so far this modification seems to be working on dozens of systems with no complaints. In fact, some older systems love the 16bit color depth as far as application performance.

Edit -- Also works with oddmod.

Thanks again,

Last edited 2011