Simple DirectX demo

Another coursework. Just playing around and getting familiar with DirectX. Modified an example framework to show Planar shadows, Stencil reflections, with use of shaders (Vertex and Pixel shader) and .X model loading. Just simple transformation of the loaded model as well. The shader used was a standard Phong shader. Was pretty fun!!!

Keys for the demo :
W/S/A/D : Camera movement (front, back, left, right)
R/F : Camera up/down
K/L/N/M : Transform car model (up,down,left,right)
C : Reset Car position
V : Reset Camera position

Download the executables and source here :

Executable

Source Code

Oh and a sneak preview 😛

Note : If you are using Firefox you must download the Windows Media Plugin for Firefox here to be able to watch videos properly.

[local /wp-content/uploads/2010/05/DirectX-Demo-2010-05-17-18-31-30-49.wmv]

Share

DirectX Audio Game

One of the courseworks during university is to create an audio only game – targetted at hearing impaired gamers. I think this is indeed a very interesting task. I have created text only game but not audio only game!

Building from a basic framework supplied by the course lecturer, Mr. Allan Milne, I’ve created a simple zombie game. Getting the balance right was hard indeed as the game is written for 2 channel stereo audio output. After a lot of fine tuning and debugging I think that the game is roughly playable 🙂

The title of the game is “Zombie Rescue”. It is basically an audio only first person shooter type game. There is one main character that can move freely in a 2D plane. There are also enemies and objects that the player is able to interact with.

Plot :

There was a viral outbreak at the underground lab that you were working. As a result, all of your colleagues had turned into zombies. You were lucky enough to escape before the military completely sealed off the underground compound. You have been working hard and have discovered a serum that might cure your colleagues. This however means you must venture into the dark underground compound to search for med kits that will work with your serum to cure your zombie colleagues. You have a 1 minute time limit to attempt to cure them all before the military will lock the vault door. Luckily, the zombies appear to be chained to the ground, so they will not give chase. Finally, you must do all this in the dark as any light might potentially kill your colleagues in their zombie form.

The use of DirectSound’s IDirectSound3DListener interface has indeed made the task simpler. With methods like SetPosition and SetOrientation it made the task of creating a virtual “camera” for the player in game manageable. The task of positioning 3D sound in the game is also very straightforward and simple. In a short time, I managed to create a simple soundscape to represent the game world.

There are a few restrictions I had to impose to the game. I had limited the player’s rotation to the XZ plane; therefore it rotates only about the y-axis. This means he is unable to look up and down. I have also disabled movement for the zombies and position them at random positions with random orientation limited to four directions – North, East, South and West. Other limitations also include limiting the number of zombies and med kits. I find that too many variables made the game harder to play. As I add more sounds, they tend to overlap each other and this made it difficult to “feel” the actual position of the player in the game.

I had made extensive use of audio clues in the game so that the player do not feel too detached from the game. The main challenge here is balance. I had to decide to balance between adding more features to the game versus playability. In the end, I managed to work out a decent outcome that borders in between both.

I have also attempted to use the Sound Cone technique and apply it to the zombie. The idea is to project the sound source in a certain orientation and angle so it’s more realistic. I have thoroughly explored the IDirectSound3DListener8 interface’s Sound projection cone methods. However, due to the lack of time I couldn’t manage to include this feature in the final version of the game. Without visual confirmation linking it to the Field of View detection technique that I have implemented for the zombies, it’s very hard to get things right. Sometimes the sound doesn’t sound “right” during game play hence it confuses the player.

However, I generally feel that it is possible to design an audio only FPS game and make it work. Perhaps it would take a slightly longer time. I have tried playing my game with my eyes closed and most of the time I am pretty satisfied with the outcome. There are certain times where things seemed a bit odd but this is due to the Random Number Generator outcome that positions the zombies too close to each other. I strongly feel that by adding multi channel audio support will greatly improve the game playability.

Anyway, I’ve spoken too much 😛 Below are links to the executables and source code :

DirectX Audio Game Code

DirectX Zombie Audio Game Executables

Share

Honours Year Project – GI implemented using OpenGL

I’ve implemented simple Global Illumination (GI) on a heightmap based terrain written using C/C++ programming language and also OpenGL API.

Here’s a copy of my project abstract :

Using Global Illumination (GI) as an advanced lighting method for terrain generation can be challenging and difficult to implement efficiently. Terrain generation normally involves large complex surfaces consisting of thousands, if not millions of vertices which could really be demanding of hardware if a high level of realism is expected.

This honours project will be based upon using a graphics API to try and implement cheap and efficient GI in a computer generated terrain. OpenGL was chosen as the API as it is a robust open sourced cross platform API. Heightmaps were chosen instead of using procedural terrain generation as the complexity of using the latter method was well beyond the timeframe allowed for this research. The final solution is based on the Spherical Harmonics (SH) Lighting method. This technique is used based on the need of having dynamic light accounted into the final shading step and also taking into account the advantage of computing only low frequency lighting which is a feature in typical landscapes.

The application features a dynamically generated landscape read from a heightmap file with SH lighting methods of various complexity. The shadowed and inter-reflected lighting is quickly pre-computed using a special, heightmap-optimised ray tracer during initial pre-processing step. Final results presents a fully-lit, dynamically shadowed and textured terrain with addition of indirect lighting at a constant, complexity invariant frame rate, which seems to be the ideal solution for the current requirements.

It was initially intended to make use of shader programs to handle the GI but after several attempts, it was found that the shader programs are unable to handle the texture calls and handle the complexity of the algorithm. I have since then resorted to fully code the GI algorithm using the CPU. Although I would have imagined that higher frame rates could be achieved using some of the GPU processing powers, the current frame rates are also acceptable keeping in mind the samples used. This would mean that support for older hardware is also better.

The final program itself has 11 Application Modes. Each showing steps of the algorithm “building up” to the final completed fully lit and textured version. A simple animated water plane was also implemented. This slightly affects the frame rates as the scene had to be rendered twice during run time but on my computer I am still getting an acceptable frame rate of between 28-32 fps.

The algorithm used was a hybrid of Spherical Harmonics and Ray casting.

Below is a flow chart summarising the process flow of the GI algorithm :



Here is a video of the program itself in action. It shows all the available applications modes and also the final app mode with the water plane switched on and off.

Note : If you are using Firefox you must download the Windows Media Plugin for Firefox here to be able to watch videos properly.

[local /wp-content/uploads/2010/05/terraincapture3.wmv demo]

Share

Ogre3D networked game

I’ve implemented networking to a game called “Solarbound” which was my 3rd year group project. The main framework was adopted but recoding was done to trim down and optimise the framework for use with this coursework. A lot of unnecessary features and code were removed so that it would be easier to adapt the framework to introduce a multiplayer network game mode into the framework.

The features of this game include simple enemy AI, collision detection, simple score and health system for players.

The game is based on a client-server protocol. There are two executable files generated by the framework called server.exe and client.exe which are the server and client modules of the game respectively. The server.exe file functions as the host for the game. This file must be run before trying to connect clients. A very simple GUI has been implemented for the server with options to start the server, spawn enemies and also activate and deactivate Dead Reckoning (DR) algorithm. There is also an option to activate and deactivate the simulation of packet loss to further observe the effects of DR. A very simple “God Mode” is also implemented to the server module to enable the user to freely observe the game world in real-time.

The client.exe file connects the player to the server and has options for the user to input individual player names and also to input manually the server’s Internet Protocol (IP). The client also has the option to turn on and off to observe the effects of lag or packet loss artificially simulated by the server. At the moment there is only support of a maximum of 3 players due to the models available.

The overall game play is simple with players competing to outlast and outscore other players by gunning down as many enemies as they can before dying. The players can also shoot each other and each hit will reduce the player’s life by one. The game will be over when the player’s life reaches zero.

There is only one single type of enemy and which implements a simple type of AI. The enemies will spawn at random points in the map and remain static until a player gets into their “detection zone”. They will then start to manoeuvre towards the player and try to ram into the player and self-destruct.

One interesting thing to note is that OGRE3D doesn’t like multiple instances being run. So if you run the client and server on the same computer the application will speed up drastically.

Below are some screenshots from the application. Click on each thumbnail to enlarge the picture.


The executables can be found here

The source code can be found here

Share