Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In theory, to check for HW T&L in Direct3D, one calls IDirect3D9::GetDeviceCaps and checks for the HWTRANSFORMANDLIGHT flag to be set in the returned structed.

However, the documentation states:

The application should not assume the persistence of vertex processing capabilities across Direct3D device objects. The particular capabilities that a physical device exposes may depend on parameters supplied to CreateDevice. For example, the capabilities may yield different vertex processing capabilities before and after creating a Direct3D Device Object with hardware vertex processing enabled. For more information see the description of D3DCAPS9.

If I understand this correctly, GetDeviceCaps could return that HW T&L is not supported before creating a device, and return that it is supported after. But if I can create a device with HW T&L successfully, then there is no point checking for HW T&L support!

So my question is, is there any purpose to checking for HW T&L using GetDeviceCaps, or am I better off just attempting to create the device with HW T&L and seeing if it succeeds?

share|improve this question
Just create the device. It's been a couple of years since there devices incapable of hardware T&L were sold. – Marcin Seredynski Feb 13 '13 at 16:57
Modern apps to T&L themselves in shaders, anyway. Fixed-function T&L is mostly irrelevant now. – Sean Middleditch Feb 13 '13 at 21:23
up vote 3 down vote accepted

If I understand this correctly, GetDeviceCaps could return that HW T&L is not supported before creating a device, and return that it is supported after.

It's more the opposite case: if your hardware doesn't support T&L then no device creation params are going to change that. On the other hand, if your hardware does support T&L then it's possible that device creation may give you a device with which it's software-emulated, although to be honest I'm finding it difficult to think of a situation in which that may happen.

It's important to realise that much of the D3D9 documentation dates back to 2002 or thereabouts (and a good chunk of even that was recycled from the D3D8 documentation), and the state of hardware was very different back then. So the documentation should be read in the context of the hardware that was available at the time it was written; nowadays you can pretty much assume that you have hardware T&L available irrespective ((dis)honourable exception - some older Intels from 2006/2007 or so). In particular, if you're running on D3D10+ class hardware (or Windows Vista+ with Aero enabled), the presence of hardware T&L is absolutely guaranteed.

In general you can just attempt to create a device with hardware T&L; if it fails where to go from there depends on how comfortable you are with the options available to you. One approach may be to treat it as an error condition and just crash out. Another approach may be to attempt creation of a software T&L device, but beware that there are subtle differences between how each class of device handles some things (mostly vertex buffer updates) with things that work on the one failing on the other, so if you're going to do this then be sure that you test fully on both types.

share|improve this answer

Generally, one would try to create the device with hardware support and if the creation of that device failed, fall back to software.

As long as you handle the failure appropriately, there's no particular danger in "checking" for vertex processing capabilities this way and it is less error prone in weird edge cases than using the IDirect3D9::GetDeviceCaps method, for the reasons you outlined.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.