Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / How to check hardware support for stencil shadows / dbSetShadowShadingOn?

Author
Message
Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 27th Jul 2009 13:12
Hi,

I'm looking for a way to check if the running hardware supports 'dbSetShadowShadingOn', to avoid execution errors.

Here is a function called 'IsDepthFormatExisting', that should check the stencil buffer, it compiles and runs, but it raises an error:



Don't even know the correct parameters for stencil buffer ( D3DFORMAT DepthFormat, D3DFORMAT AdapterFormat ), but at least it should return 'false' and not raise an exception.

Here are the links I used:

Determining Hardware Support (Direct3D 9): http://msdn.microsoft.com/en-us/library/bb219618(VS.85).aspx

IDirect3D9::CheckDeviceFormat : http://msdn.microsoft.com/en-us/library/bb174309(VS.85).aspx

D3DFORMAT : http://msdn.microsoft.com/en-us/library/bb172558(VS.85).aspx

I must have some silly error, perhaps related to the pD3D declaration (should it be another struct?):



Please, does anyone have any idea? Thanks.
dark coder
21
Years of Service
User Offline
Joined: 6th Oct 2002
Location: Japan
Posted: 27th Jul 2009 13:27
Quote: "I must have some silly error, perhaps related to the pD3D declaration (should it be another struct?):"


You don't assign the pointer any address, thus dereferencing it is unsafe. You can get the ptr from 'dbGetDirect3D()'.

Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 27th Jul 2009 18:15 Edited at: 27th Jul 2009 18:16
Thanks Dark Coder, that was it

I knew there was something to do with that pointer, but I was only aware of dbGetDirect3DDevice(), ajem , and that one of course didn't work.

Here is how it stands then:



Now the only thing pending would be to discover the parameters(D3DFORMAT DepthFormat, D3DFORMAT AdapterFormat ) that are, in fact, checking the stencil buffer support.

Above it uses:



That is,

DepthFormat = D3DFMT_D24S8: 32-bit z-buffer bit depth using 24 bits for the depth channel and 8 bits for the stencil channel.

AdapterFormat = D3DFMT_X8R8G8B8: 32-bit RGB colour format that uses 8-bits for the (R)ed, (G)reen and (B)lue channels.

But it returns true for a compatible and also for non-compatible hardware with DGDK stencil shadows

Any further advices please? That is, does anyone know the right DepthFormat and AdapterFormat that DBPro/DGDK uses with the stencil shadows?
Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 27th Jul 2009 18:27
You could find out by running a GDK app through PIX couldnt you and checking the runfile ?

If it ain't broke.... DONT FIX IT !!!
Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 27th Jul 2009 19:34
Mista, thanks for the tip.
I've been looking into it, and it results that it makes these calls:

CheckDeviceFormat(0, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, 0x00000002, D3DRTYPE_SURFACE, D3DFMT_D24S8)

and

CheckDepthStencilMatch(0, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, D3DFMT_X8R8G8B8, D3DFMT_D24S8)

So it uses the same d3dformats as the previous sample.

I've made this final version with the msdn functions:



However it still returns that the format exists and is supported in machines with shadows crashing.

How could it be in other way if DGDK eats it as well and tries to run the program?

Or there is something else to check, or the video drivers are too much happy
Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 28th Jul 2009 03:43 Edited at: 28th Jul 2009 03:46
Hmm, thats strange, im not sure how the function that you are calling works so I cant help you with that im sorry... not done alot of directx API programming.

I do think, however that there may be a couple of things that you can try...

Doesnt GDK have inbuilt commands to check the availability of various hardware things ? such as whether antialias is supported, is TNL is supported...

give me a tic ill have a look in the headers and see if i can see anything....

here are some decs from the Basic3D header, hope something helps :



Those above listed dont have anything to do with actually checking the hardware that you are after, but perhaps there is some combination of existing GDK commands that you could use to check it ?


One last question, may be a little nooblike lol but gotta ask anyway as ive not seen it before :

your function return values :

"return SUCCEEDED( hr );"

Is there a chance that it is only returning the "succeeded" part of the HRESULT ? or does that call mean that its only going to return it if it succeeds ?
I know the macro is "#define SUCCEEDED(hr) (((HRESULT)(hr)) >= 0)" .. maybe if you "return hr" then check for success on the returned value ?

It means that you would need to return a HRESULT rather than a bool value though I think.... anyway, just some ideas that I had, I hope you get it working as its something I wouldnt mind knowing aswell

If it ain't broke.... DONT FIX IT !!!
Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 28th Jul 2009 10:03 Edited at: 28th Jul 2009 10:22
@morcilla, I was doing a bit of readin through the DirectX SDK, looking at its shader stuff actually... I just happened across a call to a function in one of the samples that did almost exactly what you were after...

This is a function called "IsDeviceAcceptable" :




You can see that it is using a similar logic to check for the success of the call, except that the format of it's check and what it is returning are different.

Where in you example you are returning a value prefixed by a macro, the above is simply returning true or false, after checking the HRESULT in its function call... hope his makes sense and helps you a little...

This particular snippet came from the "BasicHLSL" Sample in the DirectX SDK(it uses DXUT you may notice lol)

If it ain't broke.... DONT FIX IT !!!
Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 29th Jul 2009 12:00
Mista, thank you very much for trying to help.

I was playing around with the DGDK 'available' functions and, for example, the crashing hardware reported:

WBUFFER AVAILABLE = 0
ZBUFFER AVAILABLE = 1

MAXIMUM VERTEX SHADER VERSION = 3.0
MAXIMUM PIXEL SHADER VERSION = 2.0

I still think that the functions returning 'true' for the checks is a driver behaviour since latests DX SDKs, where the shader support has been dropped for versions < 2.0.
I believe this because the machine is a laptop with an intel graphics card, built before shader model 3.0 specifications...
How can it return maximum vertex shader model as 3.0?
Also, some 2.0 shaders don't run fine, producing strange results.

I don't see any problem with the use of

"return SUCCEEDED( hr );"

After all, it is a msdn function code, so I assume that it must be right.

Also, I haven't had any success with 'IsDeviceAcceptable'. Oh well, it was going to be hard to use due to that DXUT thing, but thanks again.


If there is a solution, I would appreciate anyone coming with the answer. I do not have further time to check this now.
These are the kind of things where TGC 'tech support' could lend a hand.

It is hard to produce a serious application, if you have to leave open to the user those options that can crash the software.

Login to post a reply

Server time is: 2024-10-01 08:43:25
Your offset time is: 2024-10-01 08:43:25