Tricks of the Windows Game Programming Gurus:Algorithms, Data Structures, Memory Management, and Multithreading

All ITKnowledge Source Code Search Tips Advanced Search |

| Tricks of the Windows Game Programming Gurus by Andre LaMothe Sams, Macmillan Computer Publishing ISBN: 0672313618 Pub Date: 09/27/99

Search this book:

Previous | Table of Contents | Next

#### Assembly Language

The final optimization I want to talk about is assembly language. You’ve got the killer algorithm and good data structures, but you just want a little bit more. Handcrafted assembly language doesn’t make code go 1,000 times faster like it did with 8/16-bit processors, but it can get you 2-10 times more speed, and that’s definitely worth it.

However, make sure to only convert sections of your game that need converting. Don’t mess with the menu program, because that’s a waste of time. Use a profiler or something to see where all of your game’s CPU cycles are being eaten up (probably in the graphics sections), and then target those for assembly language. I suggest Vtune by Intel for profiling.

In the old days (a few years ago), most compilers didn’t have inline assemblers, and if they did, they sucked! Today, the inline assemblers that come with the compilers from Microsoft, Borland, and Watcom are just about as good as using a standalone assembler for small jobs that are a few dozen to a couple hundred lines. Therefore, I suggest using the inline assembler if you want to do any assembly language. Here’s how you invoke the inline assembler when using Microsoft’s VC++:

    _asm

    {

    .. assembly language code here

    } // end asm

The cool thing about the inline assembler is that it allows you to use variable names that have been defined by C/C++. For example, here’s how you would write a 32-bit memory `fill` function using inline assembly language:

    void qmemset(void *memory, int value, int num_quads)

    {

    // this function uses 32 bit assembly language based

    // and the string instructions to fill a region of memory

    _asm

       {

       CLD                // clear the direction flag

       MOV EDI, memory    // move pointer into EDI

       MOV ECX, num_quads // ECX hold loop count

       MOV EAX, value     // EAX hold value

       REP STOSD          // perform fill

       } // end asm

    } // end qmemset

To use the new function, all you would do is this:

    qmemset(&buffer, 25, 1000);

And 1,000 `quads` would be filled with the value `25` starting at the address of `buffer`.

> Note: If you’re not using Microsoft VC++, take a look at your particular compiler’s Help to see the exact syntax needed for inline assembly. In most cases, the changes are nothing more than an underscore here and there.

### Making Demos

So you’ve got this killer game, and you need a demo mode. There are two main ways to implement a demo mode: You can play the game yourself and record your moves, or you can use an AI player. Recording your own gameplay turns out to be the most common choice. Writing an AI player that can play as good as a human is difficult, and it’s hard to tell the AI that it needs to play the game in a “cool” way because it needs to make a good impression on potential buyers. Let’s take a brief look at how each of these methods is implemented.

#### Prerecorded Demos

To record a demo, basically you record the states of all the input devices each cycle as you create the demo, write the data to a file, and then play back the demo as if it were the input of the game. Take a look at Figure 11.13 to see this graphically. The idea is that the game doesn’t know whether the input is from the keyboard (input device) or from a file, so it simply plays the game back.

Figure 11.13 Demo playback.

For this to work, you have to have a deterministic game: If you play the game again and do the exact same things, the game creatures will do the exact same things. This means that as well as recording the input devices, you must record the initial random number seed so that the starting state of a recording game is recorded as well as the input. This ensures that the game will play back the exact same way as you recorded it.

The best approach to recording a game is not to sample the input at timed intervals, but at each frame. Hence, if the game is played on a slower or faster computer, the playback data won’t get out of synchronization with the game. What I usually do is merge all the input devices into a single record, one for each frame, and then make a file of these records. At the beginning of the file, I place any state information or random numbers that I played the demo with so that these values can be loaded back in. Therefore, the playback file might look something like this:

    Initial State Information

    Frame 1: Input Values

    Frame 2: Input Values

    Frame 3: Input Values

    .

    .

    Frame N: Input Values

Once you have the file, simply reset the game and start back it up. Then read the file as if it were the input devices. The game doesn’t know the difference!

> Warning: The single worst mistake that you can make is sampling the input at the wrong time when you’re writing out records. You should make absolutely certain that the input you sample and record is the actual input that the game uses for that frame. A common mistake that newbies make is to sample the input for the demo mode at a point in the event loop before or after the normal input is read. Hence, they’re sampling different data! It’s possible that the player might have the fire button down in one part of the event loop and not in another, so you must sample at the same point you read the input for the game normally.

#### AI-Controlled Demos

The second method of recording a game is by writing an AI bot to play it, much like people do for Internet games like Quake. The bot plays the game while in demo mode, just like one of the AI characters in the game. The only problem with this method (other than the technical complexity) is that the bot might not necessarily show off all the cool rooms, weapons, and so on, because it doesn’t know that it’s making a demo. On the other hand, the cool thing about having a bot play is that each demo is different and the “attract mode” of the game will never get boring.

Implementing a bot to play your game is the same as with any other AI character. You basically connect it to the input port of your game and override the normal input stream, as shown in Figure 11.13. Then you write the AI algorithms for the bot and give it some main goals, like finding its way out of the maze, killing everything in sight, or whatever. Then you simply let the bot loose to demonstrate the game until the player wants to play.

Previous | Table of Contents | Next

Copyright © Macmillan Computer Publishing, Inc.

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 in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.