Bow Arrow DirectX

Need

The most thorny problem in MS-DOS game programming was hardware device support. Developers targeting PCs don't enjoy the same uniform platform that those developing for dedicated gaming consoles enjoy. The developers targeting game consoles drift to sleep each night knowing that the code they wrote that day will get a warm welcome from millions of identical machines - clones in a true sense of the word than any PC clone. The PC game developers toss and turn, dreaming about new graphics coprocessors, digital joysticks, 3D accelerators, and virtual-reality input devices. They know that their next game will be expected to support an even wider range of hardware devices than the ones they were struggling with that day. While nothing prevents individual games from taking advantage of hardware advances (and many have), it can be very difficult for the small, content-oriented game development shops to keep up. Their game no sooner hits the shelves than another wave of unsupported hardware possibilities rolls in. The lack of a consistent interface to these devices often requires developers to divert creative energy and development funds from the application itself to writing drivers that supports the new hardware features. Sadly, all this effort too often results in games that are difficult to install, frustrating customers and creating support costs that take huge bites out of the publisher's already thin profit margins.

A high-level operating system such as Windows has much to offer the game developer that can't be used to avoid many of the supports calls resulting from installation problems. For example, Plug and Play makes it simple to install the latest video board, input device, or sound card. The windows system registry can be consulted for configuration information during installation, and the Windows AutoPlay system is available to make that installation virtually automatic. Once the application is installed, it can call upon a vast repository of built-in device- independent functionality. Until now, however, using this platform has meant a severe performance penalty that was unacceptable to game developers.

All this changed when Microsoft created DirectX. DirectX offers the game developer the option of selecting a robust, well-documented platform on which to build a game or a multimedia application. DirectX opens the doors to Windows functionality without asking the developer to sacrifice performance and shifts the burden of hardware support back to the hardware manufacturers.

Overview

Here we want to explore the best API ever written for games development called DirectX. It provides hardware independence without compromising on speed and performance unlike GDI. Applications written using DirectX automatically take advantage of new hardware support without ever re-compiling.

Requirement

• VC++ 6.0 Platform - for development

• DirectX 6.0 or above

Preview

Steps To Develop This Application

1. Create a dialog-based application - 'Robin'.

2. Modify InitInstance( ) and remove the code that pops up the dialog. This is done only to get AppWizard support. The dialog classes can be removed from the project or left as it is.

3. Create a new class and derive it from 'A Generic CWnd'.

4. Create a full screen window without a title bar.

5. Obtain the IDirectDraw interface pointer using DirectDrawCreate( ).

6. Using IDirectDraw interface pointer obtain IDirectDraw2 interface pointer by calling QueryInterface( ). Next set the cooperative level and display mode suitably.

7. Using IDirectDraw2 interface pointer call CreateSurface( ) to create a primary surface and specify number of back buffers, in our case it is 1.

8. Using the surface pointer (IDirectDrawSurface returned by CreateSurface( )) call GetAttachedSurface( ) to get a surface pointer for the back buffer.

9. Create one more surface of type Off screen for the background image of our game. Load the background image you want on this surface. For this, use the ::LoadImage( ) and BitBlt( ) functions. You have to acquire the device context by calling IDirectDrawSurface::GetDC( ) to make BitBlt( ) work.

10. Other game elements like balloon, arrow, robin images are created in a similar way by first creating an off screen surface for them and later blitting the image onto the surface.

11. Override the Run( ) virtual function in the CWinApp derived class to perform custom idle processing. Whenever windows messages are not available, call a function in the CWnd derived class. This function should blit the background, sprites onto the back buffer surface and then flip it with the primary surface by calling IDirectDrawSurface::Flip( ).

12. Add various mouse handlers in the CWnd derived class which would help manipulate the coordinates of the sprites like balloon, arrow etc.

Further Improvements

1. Allow the users to select different backgrounds and robin images.

2. Add different levels of complexity for the user to play.

3. Add a stop watch. When time is over stop the game.

4. Give each balloon different points and make them move at different speeds.

5. Program should judge the players competency.

6. Provision to store high scores with names

7. Modify balloon and robin images so that they appear in 3D.

8. Add an extra frame constituting of trees. Balloons should go behind the trees confusing the shooter and making the game difficult to play.