Basic DX questions

Quote:

1) I’m not sure why I must check that D3DDEVCAPS_HWTRANSFORMANDLIGHT is supported, as surely this can be taken for granted if a card to be to a certain DirectX version? For example, if I was using the 9.0c features, isn’t there a way to just check to see if the card is up to that standard, which in turn implies that many common features such as D3DDEVCAPS_HWTRANSFORMANDLIGHT are already supported by the GPU?

DirectX 9 is quite old, and there are some quite old cards which have no hardware t&l, nor shaders. It's mostly for backward compatibility.

Quote:

2) I can’t understand why a pure device would be better in the long run, my book says it may be faster, but certain get methods would be disabled. Why would you ever use a pure device if you can’t ask for certain information from the card?

What kind of information do you need from the card? There are some things you can retrieve using a pure device (occlusion queries, texture data, etc) so a pure device works fine in most cases...

Quote:

3) If I’m interested in using DirectX 9.0c, why do I need to use the D3DCAPS9 structure at all as CAPS is used to find out if things are supported above a DirectX version?

Because DirectX 9 was designed that way, luckily the later versions got rid of all the caps (although some are back in D3D11).

Quote:

4) When creating the IDirect3D9::CreateDevice object, why would the hFocusWindow parameter be anything different than the display window?

Hm.. if you had a "normal" windowed application and your 3D rendering went to some child window of that main window, you might want to provide the HWND of the main window rather than the one where rendering occurs, since D3D uses it to know when you lose focus and such...

Quote:

5) When checking for IDirect3DDevice9::TestCooperativeLevel, can an application ever do anything that would cause D3DERR_DRIVERINTERNALERROR to be returned?

Not normally no...

1) I am not aware of any minimum spec for directX9.0c. I guess that was the point of DX10 is that with 10 you can guarantee a certain minimum set of abilities. My approach with DX9 was to buy a really crappy $400 old laptop and call that my minimu spec. I don't do anything in DX9 that won't work on that laptop. If any of my customers have an older PC than that then I am really sorry for them on multiple levels.

2) You should be able to search for pure device, but one thing it does I beleive is to not check for redundant state changes so when you have tuned up your engine and have eliminated all redundant state chnages you can switch to pure device and get a small performance boost.

3) I think the CAPS structure is usefull to big huge comapnies with lots of engine guy's that can build and support a many-headed graphics engine to handle a bevy of different abilities. if you are just one guy I suggest you either program to a minimum set as outlined in #1, or demand a certain mimimun video card and program to that. Just my opinion I am sure others would think differently.

4) don;t know, maybee if you have multiple monitors???

5) don't know...

Hope that helps...

Quote:

Original post by NewBreed 1) I’m not sure why I must check that D3DDEVCAPS_HWTRANSFORMANDLIGHT is supported, as surely this can be taken for granted if a card to be to a certain DirectX version? For example, if I was using the 9.0c features, isn’t there a way to just check to see if the card is up to that standard, which in turn implies that many common features such as D3DDEVCAPS_HWTRANSFORMANDLIGHT are already supported by the GPU?

Nope, sorry. D3D9 is sort of a mess when it comes to this...there are some baseline features that are guaranteed, but many things you'll have to query for. HW T&L is one of them unfortunately, since many Intel integrated chips use software vertex processing. However I believe a few of these integrated chips (newer ones maybe?) actually report that they support HW T&L, but then do all the vertex processing on the CPU anyway.

FYI, D3D10 is MUCH better in this regard.

Quote:

Original post by NewBreed 2) I can’t understand why a pure device would be better in the long run, my book says it may be faster, but certain get methods would be disabled. Why would you ever use a pure device if you can’t ask for certain information from the card?

Since any requests to change state come from the app, it's not too unreasonable to assume that the app knows the current state of the device. All you need to do is cache your device state somewhere and update it every time you change it, and you'd have no need to ask the device for its state.

For just learning or for apps where bleeding-edge performance isn't a concern...yeah it makes more sense to take the small performance hit over creating a whole device state-caching class. But remember D3D9 is used by AAA games too, and those guys will take any performance gain they can get.

Quote:

Original post by NewBreed 3) If I’m interested in using DirectX 9.0c, why do I need to use the D3DCAPS9 structure at all as CAPS is used to find out if things are supported above a DirectX version?

Those caps tell you about a device's support for optional features. If you're not using any of those optional features you don't need to bother, but you'll probably learn very quickly that these optional features are very very useful.

Quote:

Original post by NewBreed 4) When creating the IDirect3D9::CreateDevice object, why would the hFocusWindow parameter be anything different than the display window?

D3D is designed be used for things like embedded controls in GUI apps, in which case you may not want D3D messing with your window.

Quote:

Original post by NewBreed 5) When checking for IDirect3DDevice9::TestCooperativeLevel, can an application ever do anything that would cause D3DERR_DRIVERINTERNALERROR to be returned?

I'm sure it's possible, but I can't give specifics because it completely depends on what driver you're using and how buggy it is.

1 & 3) Direct3D9 supports cards all the way back to D3D7. You can use your old ATI Rage XPert98 card with D3D9. Such a card doesn't support HWTRANSFORMANDLIGHT, and will have low or false values for many of the caps. Basically GeForce1, 2, and 4MX cards (and equivalent ATI cards) were the first that could perform vertex processing in hardware, and didn't yet have shader support. Cards before these should use a device in software processing mode, and the HWT&L caps bit will be off. On the specified cards and later, the caps bit will be on, letting you know you can ask for hardware vertex transform, or software, or mixed. Sometimes hardware processing is available, but unwanted. Some HWT&L cards didn't support point sprites. If you want point sprite support for particles, you have two choices. Use software processing, or use mixed processing, switching between hardware and software when drawing your particles. If you're using pixel shaders, you're fairly safe in assuming HWT&L is present, so you can assume you can make a hardware device. On the other hand, a card might have HWT&L and shader 1.1, but you want vs.2.0 support. If so, you can use software processing to emulate the vertex shader.

2) Why use a pure device? Why not? If you don't need to read those values back from the GPU, then why not take the free speed boost?

5) According to the docs on TestCooperativeLevel, yes.

Thats excellent - thanks everybody for your help, much appreciated. [smile]

Thanks again,
NB.