Using the Force Feedback Editor

Most input devices do just what their name implies—they provide an application with some type of user input. The user experience is one of sitting in place playing a game. However, as computer graphics and sounds have helped gamers become more immersed in their games, some vendors thought it would be a good idea to add some sense of feel to the input device. After all, a pilot actually feels the effect of the air rushing against the skin of the plane and the engine pulsing with power. That's the reasoning behind force feedback—it provides a joystick with instructions that enable it to simulate the feel of the yoke on a real plane. The user experience becomes more realistic because now sights, sounds, and even sensations that are modeled after the real-world experience (or someone's interpretation of that experience) surround the user.

The Force Feedback Editor creates standard resource interchange file format (RIFF) files that contain instructions to create a feel within a joystick, yoke, gamepad, or other input device designed to provide tactile output. You can start the application and even create files with it even if you don't have a force feedback device attached to the system. However, if you want to test the files, you'll need an input device with force feedback capability. Generally, it's better if you use the same type of device that the game user will employ to play the game because different devices will react differently to the force feedback instructions. The sensation of touch is also highly subjective, which means you should have several developers test the file. Figure 15.11 shows the initial Force Feedback Editor window.

OBBHii^^H

OBBHii^^H

Figure 15.11: The Force Feedback Editor helps you create tactile feedback for users of your application. Note

This section isn't implying that the only use of force feedback is game design, but that's the most common way that force feedback is used today. Force feedback is also useful in any simulation. For example, a driving school simulator could employ force feedback within the car steering wheel to reproduce the effects of the road. In some cases, force feedback would be useful (and was even used before it appeared on personal computers), but these simulations rely on complex and proprietary machines. For example, pilots commonly train in simulators that offer a variety of tactile feedback. It's unlikely that these huge training systems will be replaced with a personal computer any time soon. Consequently, the main focus of force feedback development today is the game. You can create force feedback files of almost any length using the Force Feedback Editor. The application begins by showing you about 10 seconds worth of force feedback. Some sequences, such as machine gun fire, might require less time, while others, such as a flight sequence, might require more. In general, tactile feedback sequences are repeated throughout the application as needed. In some cases, such as road effects for a car, the same sequence is repeated over and over again. You can control the time interval displayed on screen by changing the position of the Time Scale slider at the bottom of the display.

The application provides the full list of effects, all of which are accessible from the Force Feedback Editor toolbar. You can also select an effect from the Effect 0 Insert menu. The effects are separated into three groups as described in the following list:

General A general effect is one that normally applies over the range of the effect sequence. General effects include constant force and ramped effects. A constant force effect changes the amount of force required to perform a task and maintains that level of force throughout the effect. A ramp effect either starts at a high level and decreases or starts at a low level and increases.

Wave Wave effects are short and choppy. Imagine a bumpy road for a driving simulation or the effect of machine gun fire. The effect of each wave effect is a tad difficult to describe in words—it's something you actually have to feel. Wave effects come in several varieties, including square, sine, triangle, sawtooth up, and sawtooth down. The sine wave effect tends to be rolling, while the square wave is bumpy and the triangle wave is sharp. Of course, your perception will likely vary from mine.

Condition Some tactile feedback falls into well-known sensations based on the user's interaction with their environment. For example, most people know the feeling of bouncing up and down on something like a trampoline quite well from childhood. This is the spring effect. Likewise, inertia has well-known effects. For example, you feel inertia when going around a corner in a car.

Let's look at this tool in more practical terms. Say you wanted to create an effect that felt like a car going around a corner a little too quickly. Figure 15.12 shows that you might combine a triangle effect, an inertia effect, and two ramps. You'll find this example in the \Chapter 15\ForceFeedback folder of the CD.

As you can see, each effect is placed within a particular time sequence. You can move the effects around and change their length. Of course, this only defines when the effect will happen and how long it will happen. True tactile feedback requires more input than time and duration, and this input is often of a complex nature.

> Mi «

Q a> U K

Hit -

m ——----

innteTOI

It » T f 1 y 7

TiAaagWU»-

»

Figure 15.12: Creating an effect sequence means combining different effects over time.

Each effect also comes with a set of properties you can adjust. We're not going to visit every effect and its associated properties—that's a topic for another book. However, we can look at one effect. Right-click RampUp1 and choose Properties from the context menu. Figure 15.13 shows the tabs for this effect. You might be surprised at just how many things you can change about a simple ramp, but they all make a difference in how the effect feels to the end user.

receives.

igure 15.13: Even simple ramp effects have several properties that modify the tactile feedback the user receives.

The Ramp tab controls how the effect varies over time. In this case, we're telling the ramp effect to begin at a low level and then increase to the maximum effect level over time. The envelope varies the manner in which the effect changes. The ramp begins as a straight line, but you can modify the effect so it uses a logarithmic, sine, or other envelope. The Axes tab determines which axes of the input device are affected by the ramp. The Timing tab tells how long the effect lasts and determines if there's a delay in starting it. Finally, the General tab contains a field for changing the name of the effect on screen. As you can see, there are many ways to change what the user feels even within a single effect.

This section hasn't really explored the Force Feedback Editor completely, but you should have a better idea of how it can change the user's application experience. As mentioned earlier, even though force feedback is currently the domain of game players, it does have many practical applications outside that arena. Given the rate of computer hardware development, it may not be too long before all kinds of input devices employ some form of tactile feedback. For example, imagine a garment design application where the designer could actually feel the fabric as they designed the garment. The same thought holds true for many other scientific, engineering, and art applications.

DirectX, the Managed Environment, and Performance

The question of DirectX compatibility and availability has consumed more than a few message threads in the various Microsoft newsgroups. The DirectX API is substantial, and Microsoft designed it long before the managed environment was even a concept, much less an implementation as it is today. Anything this complex and designed so far outside of the conventions of the managed environment is bound to cause some level of concern and controversy.

As you've learned throughout the three DirectX chapters so far, the support you can expect to receive from the DirectX COM interface is less than complete. We had to create the DirectXHelper.DLL to overcome certain problems with DirectX COM support. What you might not know is that parts of the DirectX COM support were added for Visual Basic developers and never fully integrated into DirectX. For example, the initial DirectX libraries created an object using standard function calls—not a special call that's part of the DirectX interfaces. Using DirectX as we have means adding a kludge to a kludge—a poor idea at best.

We've gotten around most of the problems in using DirectX in the managed environment. You've seen a number of example applications that use DirectX, and you'll see more as the book runs to completion. However, there's a question of performance to answer. Adding a kludge to a kludge can make a platform unstable. You might run across problems we haven't discussed in this chapter because of the way that DirectX is put together. However, adding even one kludge to a system will result in a performance hit. Adding multiple kludges together to create a coherent system makes the performance problem even worse.

The jury is still out on just how bad the performance problems are when using DirectX in a managed environment. A few hard-core developers are saying that DirectX is completely unworkable in the managed environment, but you've already seen that that viewpoint is a little extreme. However, it's very likely that complex applications might prove too much for the managed environment until DirectX 9 appears on the scene. Even a moderately complex application will suffer some level of performance degradation.

The real issue is one of deciding whether the developer productivity and other gains offered by the managed environment outweigh the performance and reliability concerns of using DirectX 7 or DirectX 8.1 in the managed environment. For a simple application, the answer is relatively easy—use the managed because it has too much to offer to ignore. When working with a moderately complex application, the answer might be harder to come by, but most developers will probably choose the managed environment when performance isn't the main issue. Complex applications will probably require old techniques and the unmanaged environment for right now, but be prepared to switch when DirectX 9 appears.

Was this article helpful?

0 0

Post a comment