Look at the first method you declared, the IsDeviceAcceptable method. While the sample framework is busy enumerating the devices on the system, it calls this method for every combination it finds. Notice how the method returns a bool value? This is your opportunity to tell the sample framework whether you consider this device acceptable for your needs. Before you look at the code in that first method, however, notice the second method that's been declared, ModifyDeviceSettings. This method is called by the sample framework immediately before the device is created, allowing you to tweak any options you want. Be careful with the options you choose because you could cause the device creation to fail.
Now, back to that first method: first take a look at the parameters that it accepts. First, it takes a type called Caps, which is short for capabilities. This structure has an amazing amount of information about the particular device that will help you decide whether this is the type of device you want to use. The next two parameters are formats that are specific to the device: one for the back buffer and the other the device's format.
Construction Cue
The back buffer is where the actual rendered data (the pixels) is stored before that data is sent to the video card to be processed and put onscreen. The back buffer formats determine how many colors can be displayed. Most of the formats follow a particular naming convention, each character followed by a number, such as A8R8G8B8. The component specified by the character has a number of bits equal to the number. In A8R8G8B8, the format can contain 32 bits of information for color, with 8 each for alpha, red, green, and blue. The most common components are
A Alpha
R Red
G Green
B Blue
X Unused
You can look in the DirectX SDK documentation for more information on formats.
Because it's also important to know whether this device can render to a window, that is the last parameter to this method. Although the majority of games run in full-screen mode, it can be difficult to write and debug a game running in full-screen mode. During debugging, this application renders in windowed mode rather than full-screen mode.
Construction Cue
Windowed mode is how most of the applications you run are opened. Many of them have a border and the control menu, the minimize and maximize buttons, and a close button in the upper-right corner. In full-screen mode, the application covers the entire screen and in most cases does not have a border. You can change the desktop resolution if the full-screen mode is using a different screen size from your currently running desktop.
You'll notice that the default behavior is to accept the device, but before it is accepted, two specific checks happen. The first check ensures that the device passed in can perform alpha blending (the user interface for the game will require this), and if it cannot, it returns false to signify that this device is not acceptable. Next, the capabilities are checked to see whether there is support for active lights. Scenes with no lighting look flat and fake, so you always want at least a single light.
There's also code that actually modifies the device before creation, and even though you won't be creating the device in this chapter, you'll want to know what this code is for. Devices can do the processing required to render vertices in various ways, by either performing the calculations in hardware, performing them in software, or doing a mixture of both. If the processing happens entirely in hardware, another mode, called a pure hardware device, allows potentially even greater performance. This code checks whether you are currently going to create a hardware processing device; if you are and the pure device is available, it switches to using that instead. The only time you cannot create a pure device (if it is available) is if you are planning to call one of the many get methods or properties on a device. Because you won't be doing that in any of the applications in this book, you're free to use this more powerful device.
There is one last thing to do before you're ready to go on. The sample framework has some unsafe code in it, so you need to update your project to handle it.
Enumerating All Device Options
Now you're ready to have the framework start enumerating the devices on your system. First, declare a constructor for the game engine class, and pass in the sample framework's instance you've created from main. See Listing 3.3.
Listing 3.3. Adding a Constructor
private Framework sampleFramework = null; // Framework for samples
/// Create a new instance of the class
public GameEngine(Framework f)
{
// Store framework
sampleFramework = f;
}
The constructor doesn't do anything other than store the sample framework instance because that is required for almost everything that happens within the game. One of the first things the sample framework does after you invoke it is try to enumerate all the devices on your system. In your project file, you'll see a file dxmutenum.cs in the Framework folder you created earlier. This file contains all the necessary code to enumerate the devices on your system. Because it is important that you understand the how and why of the device enumeration, open that file now.
One of the first things you should notice is that the Enumeration class itself cannot be created, and every member variable and method is declared as static. Because it is (at least currently) extremely unlikely that your graphics hardware would change while your application is running (and the computer is on), it is reasonable to have the enumeration code run only once at the beginning of the application.
The bulk of the enumeration works starts from the Enumerate method, which is called by the sample framework before device creation. Notice that the only parameter this method accepts is the interface you've implemented in the game engine class so far. This interface is stored because later, as the device combinations are enumerated, the IsDeviceAcceptable method is called to determine whether the device should be added to the list of valid devices.
So how are the devices actually enumerated? The bulk of the functionality resides in the Manager class from Managed DirectX. If you're familiar with the unmanaged DirectX Application Programming Interface (API), this class mirrors the IDirect3D9 Component Object Model (COM) interface. Notice the first loop in the Enumerate method in Listing 3.4.
Listing 3.4. Enumerating Devices
// Look through every adapter on the system
for each(AdapterInformation ai in Manager.Adapters)
{
EnumAdapterInformation adapterInfo = new EnumAdapterInformation();
// Store some information
adapterInfo.AdapterOrdinal = (uint)ai.Adapter; // Ordinal
adapterInfo.AdapterInformation = ai.Information; // Information
// Get list of all display modes on this adapter.
// Also build a temporary list of all display adapter formats.
adapterFormatList.Clear();
// Now check to see which formats are supported
for(int i = 0; i < allowedFormats.Length; i++)
{
// Check each of the supported display modes for this format
for each(DisplayMode dm in ai.SupportedDisplayModes[allowedFormats[i]])
{
if ( (dm.Width < minimumWidth) ||
(dm.Height < minimumHeight) ||
(dm.Width > maximumWidth) ||
(dm.Height > maximumHeight) ||
(dm.RefreshRate < minimumRefresh) ||
(dm.RefreshRate > maximumRefresh) )
{
continue; // This format isn't valid
}
// Add this to the list
adapterInfo.displayModeList.Add(dm);
// Add this to the format list if it doesn't already exist
if (!adapterFormatList.Contains(dm.Format))
{
adapterFormatList.Add(dm.Format);
}
}
}
// Get the adapter display mode
DisplayMode currentAdapterMode = ai.CurrentDisplayMode;
// Check to see if this format is in the list
if (!adapterFormatList.Contains(currentAdapterMode.Format))
{
adapterFormatList.Add(currentAdapterMode.Format);
}
// Sort the display mode list
adapterInfo.displayModeList.Sort(sorter);
// Get information for each device with this adapter
EnumerateDevices(adapterInfo, adapterFormatList);
// If there was at least one device on the adapter and it's compatible,
// add it to the list
if (adapterInfo.deviceInfoList.Count > 0)
{
adapterInformationList.Add(adapterInfo);
}
}
The Adapters property on the Manager class is a collection that contains information about every "adapter" on your system. The term adapter is somewhat of a misnomer, but the basic definition is anything a monitor can connect to. For example, let's say you have an ATI Radeon 9800 XT graphics card. There is only a single graphics card here, but it is possible to hook up two different monitors to it (via the video graphics adapter [VGA] port and the Digital Visual Interface [DVI] port on the back). With the two monitors hooked up, this single card would have two adapters, and thus two different devices.
Construction Cue
|
