Category list

Determining Whether a Hardware Device Is Available

The manager class has a multitude of functions that can be used to determine the support your adapter has for a particular feature. For example, if you wanted to determine whether or not your device supported a particular format, and didn't want to enumerate all possible adapters and formats, you could use the manager class to make this determination. The following function can be used:

public static System.Boolean CheckDeviceType ( System.Int32

adapter

,
  Microsoft.DirectX.Direct3D.DeviceType

checkType

,
  Microsoft.DirectX.Direct3D.Format

displayFormat

,
  Microsoft.DirectX.Direct3D.Format

backBufferFormat

,
  System.Boolean

windowed

, System.Int32

result

)

This can be used to determine quickly whether your device supports the type of format you wish to use. The first parameter is the adapter ordinal you are checking against. The second is the type of device you are checking, but this will invariably be DeviceType.Hardware the majority of the time. Finally, you specify the back buffer and display formats, and whether or not you want to run in windowed or full screen mode. The final parameter is optional, and if used, will return the integer code (HRESULT in COM) of the function. The method will return true if this is a valid device type, and false otherwise .

DETECTING FORMAT CONVERSION

It's important to note that in windowed mode, the back buffer format does not need to match the display mode format if the hardware can support the appropriate color conversion. While the CheckDeviceType method will return appropriate results regardless of whether or not this support is available, you can also use the CheckDeviceFormat Conversion method off of the Manager class to detect this ability directly. Full-screen applications cannot do color conversion at all. You may also use Format.Unknown in windowed mode.

This is quite useful if you know beforehand the only types of formats you will support. There isn't much of a need to enumerate through every possible permutation of device types and formats if you already know what you need.

Checking Device Capabilities

For every possible thing a device can do that may or may not be capable of happening purely in hardware, there is an item called a "capability," or "Cap" for short. There is a Caps structure in the Direct3D runtime that lists every possible capability a device can have. Once a device is created, you can use the "Caps" property of the device to determine the features it supports, but if you want to know the features the device can support before you've created it, then what? Naturally, there is a method in the Manager class that can help here as well.

Now to add a little code to our existing application that will get the capabilities of each adapter in our system. We can't add the list of capabilities to the current tree view because of the sheer number of capabilities included (there are hundreds of different capabilities that can be checked). The easiest way to show this data will be to use a text box.

Go ahead and go back to design view for our windows form, and switch the tree view's dock property from "Fill" to "Left". It's still the entire size of the window though, so cut the width value in half. Now, add a text box to the window, and set its dock member to "Fill". Also make sure "Multiline" is set to true and "Scrollbars" is set to "Both" for the text box.

Now you will want to add a hook to the application so that when one of the adapters is selected, it will update the text box with the capabilities of that adapter. You should hook the "AfterSelect" event from the tree view (I will assume you already know how to hook these events). Use the following code in the event handler function:

private void treeView1_AfterSelect(object sender,System.Windows.Forms.TreeViewEventArgs e)
{
    if (e.Node.Parent == null) // root node
    {
        // Get the device caps for this node
        textBox1.Text = e.Node.Text + " Capabilities: \r\n\r\n" + Manager.GetDeviceCaps
            (e.Node.Index, DeviceType.Hardware).ToString().Replace("\n", "\r\n");
    }
}

As you can see, this is relatively simple. For the root nodes (which happen to be our adapters), after they are selected we call the Manager.GetDeviceCaps function, passing in the adapter ordinal for the node (which happens to be the same as the index). The ToString member of this structure will return an extremely large list of all capabilities of this device. Running the application now will result in something like Figure 2.2.

Figure 2.2. Device display mode and capabilities.

graphics/02fig02.jpg

Now, there are quite a few different capabilities that can be supported, as you can tell by the very large list that was generated. Anything that can be supported by a device is listed here. If you want to see if your device supports fogging, it's here. If you want to know the maximum simultaneous render targets, it's here as well. The Caps structure is broken down mainly into two groups of items. The first group is Boolean values that determine whether a particular feature is supported; for example, the SupportsAlphaCompare member would be true if the device supports alpha compare. The other class of capabilities returns actual values, such as the MaxActiveLights member, which is naturally the maximum number of active lights you can have in a scene.

USING THE CAPS TO DETERMINE FIXED-FUNCTION FEATURES

Many of the capabilities listed in the Caps structure pertain directly to the fixed function pipeline (for example, the MaxActiveLights member). If you are using the programmable pipeline, many of the capabilities will not apply to your scene. We will discuss the differences between the fixed function and programmable pipelines in later chapters.

Throughout the book, we may discuss individual capabilities as we need them.