95.402A Assignment #1

95.402 Winter ‘99 Assignment #1

Due: Next class Monday Sept 20, 1999 in assignment box or in demo lab.

Add sound to the existing software. Need to be able to say something like

    Sound *sound = Sound::load (fileName);
    sound->playOnce (); //Does not repeat.
    sound->playLoop (); //Repeats forever.
    sound->stop (); //If repeating.

Three approaches possible:

Use the sound functions built-in to your operating system (SIMPLEST BUT NOT EASILY EXTENDED FOR MORE ADVANCED FACILITIES).

Use 2D DirectSound as provided on NT or windows 98. Quite difficult but sample code is provided by Microsoft. (ADVANTAGE IS THAT IT CAN BE SCALED UP FOR 3D SOUND).

Use 3D DirectSound. More difficult but even more interesting since it allows sound level to change depending on the distance to the player and the direction the sound is pointing in (careful: there are no machines at School configured to run under Windows 98; so, it will require special effort to demo).

Ways to demonstrate that you have sound: (a) Once game starts up, a sound is played automatically. (b) A different sound is played (to a predesigned limit) every time you hit a certain key. (c) You think of something.

Future extensions: Choose simplest technique now and try to get to 3D sound during the rest of the course. Is additional work needed for music? Can you read sound off a CD?

Compiler resource: Ask for help via C++ compiler; should have all documentation for DirectSound.

Net resources:

http://www.microsoft.com/msj (Microsoft systems journal; use their search; download software).

http://www.gdmag.com (Game Developer Magazine; download software; one problem is

that it’s not clear what is in older articles; may have to download

just to find out).

Recommendations for the future:

Start converting the sample code you are working with into your style of formatting while trying to understand it. Switch to using GLUT instead of MFC if you prefer.

Change key handling so that booleans are set. Then, when a VK_UP key is pressed, for example, boolean goingUp which is true, remains true, until VK_UP is released. This makes for much smoother navigation.

Consider decomposing the code into two pieces: the "build-time" piece (e.g., this is the part that constructs a world, such as the terrain building code, and puts it into a file) and the "run-time" piece (this portion loads a world and runs it but CANNOT make a world).