Delphi Graphics and Game Programming Exposed! with DirectX For versions 5.0-7.0:Input Techniques                       Search Tips   Advanced Search        Title Author Publisher ISBN    Please Select ----------- Artificial Intel Business & Mgmt Components Content Mgmt Certification Databases Enterprise Mgmt Fun/Games Groupware Hardware IBM Redbooks Intranet Dev Middleware Multimedia Networks OS Productivity Apps Programming Langs Security Soft Engineering UI Web Services Webmaster Y2K ----------- New Arrivals









Delphi Graphics and Game Programming Exposed with DirectX 7.0

by John Ayres

Wordware Publishing, Inc.

ISBN: 1556226373   Pub Date: 12/01/99














Search this book:
 



Previous Table of Contents Next Note: DirectInput does allow the developer to redefine a relative axis to report absolute data and vice versa. The employment and implications of this technique are dependent on the context of the application itself. Immediate and Buffered Data Since DirectInput communicates directly with device hardware, it does not return the state of axis movement or button presses with Windows messages. Instead, there are two flexible methods by which the application can retrieve the state of an input device: immediate and buffered. Buffered data retrieval simulates the mechanism by which Windows reports input. Individual input events are stored in a buffer, which takes the form of an array of data structures containing the various axis movement values or button clicks. When you create a DirectInputDevice object for a particular input device, there is an additional step required in order to initialize the device to store information in this buffer. Immediate data retrieval does not report a stream of singular events, but returns the current state of the device at the time of the function call. This will be reported in an initialized data structure dependent upon the specific device type, and can include information on the entire device or only for a specific object on that device, such as a button. There is no additional setup required to retrieve immediate data from a device. Either of these data retrieval methods are perfectly acceptable depending on the requirements of the individual application. Indeed, both could be used simultaneously. However, it is generally most useful to utilize buffered data retrieval for relative data measurements and immediate data retrieval for absolute data measurements. We will see examples of both later in the chapter. Polling and Event Notification The “when” of retrieving input data may be as important as the “how.” In what seems to be a recurring theme throughout this book, DirectInput provides two choices: polling and event notification. Polling involves checking the state of the input device at the time that the input is needed. Typically, this is performed in the game loop. The state of the device may be checked only once, or perhaps multiple times, and is usually returned in the form of immediate data. Since the device is only checked at specific intervals, it is possible for the user to manipulate the device between checks, thus resulting in lost input. Polling may seem like a throwback to the days of DOS game programming. Indeed, it is similar, but polling for new input data is incredibly easy to implement, and in most cases is adequate for precise input measurement. Event notification, on the other hand, is very similar to event-driven programming. This is a mechanism by which DirectInput will notify the application when new input data is available, and is best paired with buffered data retrieval. While this method of retrieving input can be very powerful, it is much more difficult to implement and involves the use of threads, Win32 event objects, and critical sections. We will see examples of both later in the chapter. Cooperative Levels As discussed in the DirectDraw tutorial, a cooperative level determines how the application works with other applications. As with other DirectX components, DirectInput gives the developer a choice as to how the application will share input devices with other applications, in terms of who can gain access to the device and if input can be retrieved based on application focus. The first measurement of cooperative level determines when your application has access to data from the device, known as foreground or background access. Foreground access means that your application will have access to input data only when its main window has focus. Background access allows your application to retrieve input data whether it has focus or not; input data is available at all times, even if the application is minimized. Foreground mode is the most common for games and other applications. Nevertheless, you may need to use background mode if the application requires access to the device when a dialog box is open. The second measurement of cooperative level is based on exclusivity, which determines if only a single application has access to a device. Applications that acquire a device in non-exclusive mode can retrieve input from that device unless another application acquires it exclusively. When a device is acquired exclusively, only the acquiring application can receive input from that device. In non-exclusive mode, other applications can acquire the device in non-exclusive or exclusive mode. In exclusive mode, other applications can only retrieve the device in non-exclusive mode. Thus, only one application at a time can have exclusive access to a device. For some devices, such as force feedback, this is a necessity, as two applications sending force feedback effects simultaneously could confuse the user and possibly damage the hardware. When specifying a cooperative level, the application must indicate either foreground or background in addition to either exclusive or non-exclusive access. The following table summarizes the two cooperative level measurements and their implications for the current application and others in the system. Table 7-1: DirectInput cooperative levels Measurement Implications Validity Non-Exclusive/BackgroundNon-Exclusive/ForegroundExclusive/BackgroundExclusive/Foreground Other applications can acquire the device exclusively or non-exclusively; input data is available at all timesOther applications can acquire the device exclusively or non-exclusively; input data is available only when application has focusOther applications can acquire the device non-exclusively; input data is available at all timesOther applications can acquire the device non-exclusively; input data is available only when application has focus All devices except force feedbackAll devices except force feedbackAll devices except keyboardsAll devices except keyboards Bear in mind that Windows requires exclusive access to the keyboard at all times, so that functions such as Alt+Tab and Ctrl+Alt+Delete are always available. Thus, an application can only obtain non-exclusive access to the keyboard. Conversely, Windows can only use the mouse in an exclusive mode, and thus loses access to the mouse when another application acquires it exclusively. This means that when an application acquires the mouse in an exclusive mode, the mouse cursor will disappear and Windows will no longer generate mouse messages. There is a small performance gain when acquiring the mouse in exclusive mode, since mouse messages are not being generated. However, there is no particular performance advantage to exclusive over non-exclusive cooperative levels for other devices. Previous Table of Contents Next Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.