ICT507 Assignment 2 Joshua Stewart
ICT507 - Assignment 2
Application Documentation
Game Design Document
Lecturer: David Bennett
Tutor: Chris McCormick
Created by: Joshua Stewart
30375952
Page 1
ICT507 Assignment 2 Joshua Stewart
Table of Contents
Table of Contents ................................................................................................................ 2
Features ........................................................................................................................... 3
Build ................................................................................................................................ 4
User Controls .............................................................................................................. 4
Requirements ...................................................................................................................... 5
Summary ......................................................................................................................... 5
Design ................................................................................................................................. 7
Class Diagram ................................................................................................................. 7
XML Schema Design ...................................................................................................... 8
Detailed Design ............................................................................................................... 9
Frustum Culling .......................................................................................................... 9
Height Mapped Terrain ............................................................................................. 10
XML Driven Level Data ........................................................................................... 10
Milkshape 3D Model Loading .................................................................................. 11
OOBB – Collision Detection .................................................................................... 11
Scaling / Collision OOBB Implementation .............................................................. 11
Collision Response.................................................................................................... 12
Transparent Power-ups ............................................................................................. 13
Implementation ................................................................................................................. 14
Version Control ............................................................................................................. 14
Schedule ........................................................................................................................ 14
Feature List (Wish list) ............................................................................................. 14
Commit Log / Development Progress....................................................................... 15
Development Tools / Debugging .................................................................................. 15
Testing............................................................................................................................... 17
Performance Testing ..................................................................................................... 17
Frustum Culling ........................................................................................................ 17
2D Text Console – Limiting the performance hit ..................................................... 18
Lighting Performance ............................................................................................... 18
Accumulation Buffer Impact .................................................................................... 19
Lab Test .................................................................................................................... 19
Issues ............................................................................................................................. 21
Current Bugs ................................................................................................................. 22
Self Assessment ................................................................................................................ 23
Future Direction ............................................................................................................ 23
rd
3 Party code .................................................................................................................... 24
References ......................................................................................................................... 25
Appendix A ....................................................................................................................... 26
Page 2
ICT507 Assignment 2 Joshua Stewart
Application Documentation
Features
New in Assignment 2
Height-mapped Terrain Class
Lights & Light Manager Classes
Frustum Culling Optimisations
Player Model
Sphere/Plane Classes
Timer Class / Timer driven (FPS independent) animation & game loop control
Player moves around the world along terrain. Player is affected by gravity when
in the air.
Item Class provides player collectible items (transparent power-ups)
New Developer Mode and Optimize toggle key options
Improved since Assignment 1
OOBB Collision Detection (minor bug fixes)
Fixed bugs with collision response
Camera & Player Classes (re-factored)
User Input Handler Class
Vector Math Class (minor bug fixes)
Hierarchical XML Driven Level Data. Extended use in a number of new classes
such as Lights and Items.
Milkshape3D Model Loading (supports collision meshes, textures & material
properties). Collision structures now use new Sphere and Plane classes.
TGA Texture Loader (reused for terrain maps)
2D Text Console System (greatly improved / optimized)
Page 3
ICT507 Assignment 2 Joshua Stewart
Build
To build from source, open the ass2build.vcproj file and select build all.
There needs to a directory called Data in the same directory as the executable. The
executable also requires the glut32.dll and expat.dll files to be present.
The executable requires a level.xml file to be present. The Data directory contains
Milkshape3D models (*.ms3d) and TGA texture images.
User Controls
F Fly mode toggle
R Run mode toggle
O Optimization toggle
D Developer mode toggle
Mouse Look Look around with the mouse.
Right Mouse Button To move in a direction, look in that direction and press the
right mouse button
? Display help screen
Esc Exit the game (with exit credits)
Page 4
ICT507 Assignment 2 Joshua Stewart
Requirements
Summary
Below is a list of the requirements submitted by myself which are slightly different to the
requirements in the original assignment. These were approved by David Bennett as a
substitute to the original requirements. In addition a number of the group based
requirements have also been satisfied.
Requirements (individual & group-based) Satisfied?
Add lighting to the world. Use ambient lighting to light the world (outside). Create at Yes
least 2 objects (street light, etc) that have spotlights attached to them.
The main character must either be a 3d model (third person) or have part of a 3d model Yes
(arms + gun, etc for first person). You can use the md2 model loader provided or any
other model loader to achieve this.
The main character must be able to move through the world using proper physics. It Yes
must have a velocity and use a timer to move the character realistically.
The main character must support 2 movement speeds (run and walk). If the main Yes
character is a vehicle then it must have at least 2 speeds (not including stationary).
Frustum culling optimizations, including measurement and evaluation using FPS Yes
counter.
Optimized collision detection routines using spatially sorted linked lists, including No
measurement and evaluation using FPS counter.
Height map terrain loaded from a 2D image file and converted into polygons at Yes
runtime.
Terrain will be textured.
The player will move over terrain.
Static world objects will sit on terrain (ideally the terrain height will determine static
objects Y position in the world, allowing height map changes to not affect the worlds
object placement)
Game objects will be stored in an STL linked list. Yes
The main character should collide and react appropriately to all objects and the edges Yes. Does not
of the world. Use any of the collision detection routines. collide with
edge of world
Add additional structures, trees, etc to provide a more complete world. Yes
Your program must be documented and thoroughly tested. In addition to the Design Yes
document you should provide an architectural description of the program and its
components using UML or something suitable. You must devise appropriate test cases
and document the results.
Complete an assessment of your own work. Provide suggestions for how the world Yes
could be improved, what problems were encountered and how you overcame them,
and answer the following questions:
How is code reuse taken care of?
Can the assets/objects/items be reused easily? How would this reuse
happen?
Requirements (Group-based) Satisfied?
You must provide a world class that is responsible for loading and rendering the Yes
world, characters, as well as updating AI, etc.
Page 5
ICT507 Assignment 2 Joshua Stewart
The game world, and buildings must be loaded from file. This means that the Yes
description of the object, its vertices, filename, initial position in world, etc must be
stored in a file. When the game is run, the game engine should load all objects from
this file and place them into the appropriate data structures.
Provide a facility for the user playing the game to take screenshots of the game No
internally and stores them in an image file (jpg, gif, etc). (hint: see glReadPixels)
Provide on screen info that shows the players position and other pertinent information Yes
about the player. The user of the game should be able to toggle the display of this
information using a keyboard key. The display can be text on the screen or something
more elaborate like a modal graphical display.
Page 6
ICT507 Assignment 2 Joshua Stewart
Design
Class Diagram
Supporting
classes SXP Singletons
Sphere
1 Terrain
Vector Level
Plane
2DText
Timer
m User Interface
GameObj Handler
1
Camera
Model Player
1
Light Manager
Item m
Light
MilkshapeModel
The main render loop handles the updating of singletons, game/render loop control, some
textual display and setting up the window and GLUT callbacks.
Page 7
ICT507 Assignment 2 Joshua Stewart
XML Schema Design
CLevel
CGameObj
CPlayer
CLight
The CLevel and CGameObj classes both inherit from the SXP PersistObj class. Classes
such as CItem, CLight and CPlayer inherit from CGameObj and therefore inherit its
XML functionality. CLight and CPlayer extend the number of elements in the
GameObject element group to include elements that are required to create an instance of
that class.
The CLevel & CGameObj functions define several methods and declare a number of
variables. The CLight and CPlayer classes extend these methods by first calling the
applicable CGameObj method, then adding extra functionality to read in the extra
elements.
Page 8
ICT507 Assignment 2 Joshua Stewart
Detailed Design
Frustum Culling
As each object in the world is loaded, a culling sphere is generated which surrounds all of
the vertices of the object and is positioned in the center of the object.
The culling sphere unlike the bounding boxes of the model, are not created by the artist in
the modeling program, but instead automatically at load time and stored with the object.
In the render loop, the 6 planes of the frustum are extracted from the combined model
view and projection matrices using the methods outlined in Gribbs & Hartmanns paper
on frustum culling. These planes are stored in the level class.
Page 9
ICT507 Assignment 2 Joshua Stewart
During rendering the level class processes all game objects from the linked list of game
objects. It does a check to first see if an object is meant to be tested for culling (lights for
example should not be culled as this stops the lights from being rendered, which is a bad
idea in a small scene).
Secondly each of the remaining objects culling sphere is tested to see if it is enclosed by
or intersects the planes of the frustum. If it does then it is rendered, otherwise it is not
rendered.
Testing was conducted to measure the performance increase from this optimization and
the method and results are in the Testing section.
Height Mapped Terrain
A heightmap file is specified as an element of the Levels XML file, along with the
terrain’s texture, and dimensions.
The TGA heightmap is loaded and a dynamic array structure is created to store the height
values as floats. The height at each XZ position in the terrain in the world is determined
by the shade of grey in the heightmap image (darker is lower, and lighter is higher).
The heightmap image was created specifically for this assignment using both Adobe
Photoshop CS2 and Paintshop Pro 8. Each provided a number of gradient tools, color
level adjustment and warping effects that gave the desired result seen in the application.
It is important that there is a smooth transition between areas of the heightmap image
colors, otherwise sharp drops and rises will appear in the terrain.
Although the heightmap image is 1048x1048, to increase performance, only a sample of
the image data is used to construct the vertices use to render the terrain. Every 16 pixels
is sampled and used to determine the height of the terrain at that point. This creates a
quad mesh of 16x16 quads that are joined together to form a terrain.
As the player moves along the terrain, the original 1048x1048 array of heightmap values
are read, to get the players Y position at that point in the XZ plane. Additionally as
objects (except lights) are added to the scene (such as buildings), they also access this
structure to determine their Y position, ignoring any Y position assigned to it via the
XML element pos.y
This allows objects to the positioned on the terrain, even if it changes at some point.
XML Driven Level Data
The CLevel class and CGameObj class both inherit from the SXP::IPersistObj class.
This provides a method to communicate data from the XML parser. The CLevel class has
a number of simple XML tag objects that read in and assign values from the XML file
Page 10
ICT507 Assignment 2 Joshua Stewart
that are used to create the level. The CLevel::BeginElement method examines the id
attribute to determine which type of GameObj to create, then creates a new object for
each listed game object in the XML file (including lights, players, powerups and static
objects). Parser output is then redirected to the new object so that the new game object
can access the parser to extract its own tag data from the XML.
Each CGameObj has a number of data tags that are used to position and scale the object
in the world, as well as a filename for the model associated with that game object. The
model file itself has the collision box information and texture paths for that model.
Lights and Players extend the GameObj XML elements to include elements that are
applicable for these objects. These two classes reuse the GameObj methods to read in the
stand elements such as position and model, and then proceeds to look for other elements
related to the particular type of object.
Milkshape 3D Model Loading
A sample MS3D model loader was used from a NEHE tutorial. It was integrated and
extended to include processing of specially named collision meshes. These are flagged
when the model is loaded and are generally not rendered (unless they are used for
debugging the collision system). The model class also performs operations on the
collision meshes at load time, to optimize collision testing, by pre-calculating the
collision planes of each collision mesh in every model. This is also where culling spheres
are generated for the model geometry, to be used later with frustum culling checks.
Models can contain a number of meshes. The models material properties, textures,
normals, vertex arrays and texture coordinates are all read from the Milkshape3D model
file.
OOBB – Collision Detection
This is done by pre-calculating the 6 planes of the bounding boxes when the model is
loading. The player position is translated into the local coordinate space of the object
being checked. Then the player’s position is checked against the plane equations of the 6
sides of each bounding box, to see if the point lies inside the box.
Scaling / Collision OOBB Implementation
To check collisions for each bounding box (OOBB), apply the inverse of the transform
applied to the object to move it into world space to begin with.
This is usually done by storing the transformation matrix with the object, including
rotation, translation and scaling. However to simplify things, objects in the world wont be
scaled or rotated at this point.
Page 11
ICT507 Assignment 2 Joshua Stewart
Therefore for every object in the world, translate the player position into that objects
local space. This will allow for objects to move around the world, and still collide with
the player.
For static objects, collision checks might be faster if the objects have precalculated
collision planes base on their world position.
Without scaling or rotation available (at this point) models will need to be reworked in
milkshape modeler, which is not ideal. This will be fixed when I integrate a Matrix class.
Example
Local space
World space
* T =
* T
=
Collision detection is at the mesh level.
Each object has many meshes. Meshes are specially tagged in the Milkshape3D model
editor as collision meshes. These meshes are flagged when the model is loaded into the
application. They are generally not rendered in the world, but are used as a basis to build
information for collision detection.
After a model is loaded for a game object, collision data is pre calculated from each of
the collision meshes in the model. The 6 plane equations of the sides of the collision box
are calculated, and stored with the model. These are accessed later and points are checked
to see if they sit inside the box.
Collision Response
Collision response is still not as nice as I would like it. The camera can look through the
“walls” sometimes and the system bounces the camera in and out of the collision mesh. I
did have it so that the players last position was restored when a collision occurred,
however this had the undesirable affect of stopping movement and the player needed to
Page 12
ICT507 Assignment 2 Joshua Stewart
turn +/- 90 degrees in order to move away from the collision box (and couldn’t push/slide
their way along the collision box)
Transparent Power-ups
These are created using the new Item class, derived from CGameObj. This object is
collectible by the player, at which point it is removed from the level.
The transparency was achieved by making use of the emissive material property in
Milkshape3D and then ensuring this is set when rendering the object. This object has a
single material associated with the model, however as TGA does not support an alpha
channel, there cannot be transparent textures in the application.
Page 13
ICT507 Assignment 2 Joshua Stewart
Implementation
Version Control
Subversion (SVN) was selected as the desired version control system, as I am already
familiar with CVS and wanted to experiment with this new system as it has some
attractive features.
It was my intention to get a feel for using this tool prior to getting into any group
assignments so that future groups I work with will be able to begin using the tool to
increase group cohesiveness.
Instead of wasting time hosting my own SVN server, I selected a 3rd party SVN hosting
provider based in Queensland called www.cvsdude.com.
Future group work I plan to upgrade my plan here to include other useful group
collaboration facilities including mailing lists and bug tracking.
I used the TortoiseSVN subversion client available from http://tortoisesvn.tigris.org/
Schedule
Feature List (Wish list)
The following is a wish / feature list for assignment 2. This was planned shortly after
Assignment 1 was submitted. The purpose if this is to create some reach / stretch goals
for the assignment as well as identify the key requirement areas.
The list is then ranked in order of importance with consideration given to
Items that depend on other items
Items that form a part of a key requirement
Items that are essential and items that are just nice to have.
The list below is what the schedule would be if there was unlimited time. This is the
original list before development commenced.
Items completed at the time the assignment was handed in are highlighted in yellow.
1. Adjust Credits (warm up)
2. Screenshots (directory / filename from the XML file). Auto increment screenshot
number. (warm up)
3. Timer driven animation/updates (including timer driven text lifetime)
4. FPS counter (required to perform testing of new optimizations)
5. Heightmapped terrain loaded with level
6. Frustum culling
7. Lighting + Light Management
Page 14
ICT507 Assignment 2 Joshua Stewart
a. Spot Lights
8. Optimize collision detection using spatial sorting of the static geometry.
9. World model geometry
10. Player models (arms etc)
11. Transformations of world objects stored in a Transformation Matrix (to allow
rotations and scaling as well as translations between local and world coordinates)
12. Game play programming
13. Re-factor existing camera system to make it more player driven.
14. Gravity and Forces
15. Ground collision
16. Determine slope of terrain to affect speed of player
17. 2D GUI elements (sliders, health, icons)
18. Skybox
19. Particles (snow)
20. Display Lists
21. Fix preCalcPlanes method in model loader to allow rotations around the x/z
22. Sounds / Music class (using FMOD)
23. Additional Models / Textures / Sounds
24. Review / Adjust Game Design document
25. Engine Design documentation / UML / Testing
Primary items are 3,4,5,6,7,8,9,12,1,24,25
Additional work included:
Re-factored / optimized 2D Text system
Gravity (downward force over time) is applied to player if they are above the
height of the terrain. There is no acceleration factored in.
The objects of the world are positioned to sit with their origins at the same height
as the terrain.
Commit Log / Development Progress
Development occurred over a 4 week period. At the time of writing the source tree was
up to revision 22.
Please see Appendix A for a listing of the repository log comments detailing
development progress of the application.
Development Tools / Debugging
A number of tools were added to assist with debugging, measurement and placement of
objects in the world.
For measurement a frames per second counter and frustum culling counter was added to
the top of the screen as text using the 2D text system mentioned earlier.
Page 15
ICT507 Assignment 2 Joshua Stewart
For object placement, the players position and look vector are displayed in the top right
under the FPS.
This allows the developer to note down positions in the world where they might like to
place geometry or lights and also allows the developer to position themselves in the
world and face the direction they want a spot light to focus, then note down that vector
for use later when adding spot lights to the scene.
The developer can also enable fly mode and run to quickly fly to positions on the map,
without being constricted to the terrain.
Visual cues have been added to assist with debugging and development, including
bounding boxes, culling spheres and light markers with labels are drawn into the scene.
Below shows a number of the tools available in Developer Mode, this is accessed by
toggling the ‘D’ key. The light lines surrounding the blacksmith model represents the
automatically calculate bounding sphere used in frustum culling.
Page 16
ICT507 Assignment 2 Joshua Stewart
Testing
Performance Testing
Frustum Culling
Measurement of the effectiveness of the frustum culling optimization was performed
using a sample level consisting of over 230 objects. A large number of tree models where
added to the XML level file and loaded in.
The results are shown below in the follow screenshots. It clearly shows the frame rate
drop to 1.8fps when rendering 230+ tree models. The frame rate increases significantly
(44fps) as the camera is moved to the right and the bulk of the objects are culled away.
Note that the objects are still present in the STL linked list of Game Objects in the Level
class. This demonstrates the obvious bottleneck between the CPU and graphics hardware,
even with a relatively high performance system.
Culling summary indicating
number of objects culled and
total objects 200+ trees
Page 17
ICT507 Assignment 2 Joshua Stewart
Player view is panned in this
direction so tree objects are culled
Note the dramatic increase of FPS
as the bulk of the geometry is culled
2D Text Console – Limiting the performance hit
The 2D text console performance was horribly slow when text was spammed into it.
This prompted a number of optimizations to be added to this system to improve
performance.
As new text lines are added to the bottom of the text console, text lines above have their
opacity and lifetime reduced. This means that if text is being spammed into the console
the top text is faded and dies quicker.
If text items are scrolled off the screen they are removed from the list in the next update,
along with any text items that have their lifetime expired or opacity reaches 0.
This all means that performance is impacted to a point, but the performance hit is capped.
Try hitting the ‘j’, ‘r’, ’f’ or ‘?’ keys to spam text for an example.
Testing showed that the text system was negatively impacting the frame rate by a
maximum of 18fps with the new optimizations.
Lighting Performance
The CLight class is derived from CGameObj and as such has access to the XML
functionality. This has been extended in CLight to include a number of new data
elements.
Page 18
ICT507 Assignment 2 Joshua Stewart
A toggle key was added to disabled/enabled lighting in the scene. Testing showed that
there does not seem to be any measurable impact on performance with or without lighting
enabled in the scene.
Accumulation Buffer Impact
I was able to test out motion blurring affects applied to the whole scene using the
accumulation buffer. This decreased the performance of the application by a factor
between 5 and 10. At home I could run with 10fps with full motion blur enabled,
however during the lab tests I received a 0.7fps.
This was way too slow and this code was saved to a branch in the repository, but was not
included in the final build tree.
Lab Test
Testing was performed in the labs to ensure that the application would run on crappy
systems as well.
The performance of frustum culling and general game loop overhead was compared for
both release and debug builds to see if this had a major impact on performance.
DEBUG
All Sky (no geometry, all game objects culled) 71fps
All geometry culled, still rendering some terrain 55fps (shown below)
Page 19
ICT507 Assignment 2 Joshua Stewart
No culled geometry, ambient lighting enabled, 21fps (shown below)
RELEASE
All Sky (no geometry, all game objects culled) 95fps (increase of 24 fps)
No culled geometry, ambient lighting enabled, 21fps (same as debug build)
Page 20
ICT507 Assignment 2 Joshua Stewart
This testing indicates that there may be some improvements in the general overhead of
processing the game loop / processing objects in the linked list / culling tests etc.
However these gains are quickly squashed when OpenGL actually has to do something.
Issues
Exception Handling / Destructors
Catching exceptions raised in the CLight consutrctor is difficult as the CLight inherits
from CObject and therefore it tries to delete the pModel, which isn’t initialised for the
CLight. This may be fixed by having an abstract base class for GameObjects that does
not contain a model. This would require that a static game object subclass be derived for
the majority of the world geometry, however this would require too much rework at this
point. CGameObject shouldn’t contain pModel.
There were general problems with getting the correct destructors called for object down
the inheritance tree. Need some basics on RTTI or possibly some background on solving
this problem with static casting which should be able to go up and down the inheritance
tree. However I imagine that some enum or similar will need to be used to identify
different types quickly at runtime (before casting), although this is less elegant.
Player Model
There were difficulties with getting the player legs/torso to be separately rotated in sync
with player/camera movement. This problem is due, I think, because not much thought
was given to the control system prior to development.
Page 21
ICT507 Assignment 2 Joshua Stewart
Object Position on Terrain
As objects are added to the scene, their determine their Y position in the world from the
height of the terrain at their particular XZ position. This allows smaller objects to the
positioned on the terrain, even if it changes at some point. However large building using
this method on a sloped terrain, will find that the center of the building will be positioned
correctly but each end will sit above or below the slope of the terrain.
Example
Current Bugs
Text Exception
There is a bug seen during the end credits where if there is a help menu still displayed,
and the credits start to roll, then an exception is caused when the text->render & update
functions are trying to access previously freed memory space on the heap for a particular
text item.
It was reproduced by adding a heap of text to the window. Then collecting a powerup,
then immediately hit escape to exit.
This calls CLevel::deleteMe() which seemed to be causing a problem with the next
text->update() method call, for an unknown reason. Adding exception handlers around
the textItems.erase(i) call, does not seem to catch the exception.
As a work around I have disabled the Level::deleteMe() method in the
CLevel::~CLevel().
Page 22
ICT507 Assignment 2 Joshua Stewart
Self Assessment
Code reuse was evident in the fact that the interfaces to objects in and much of the
assignment code was left un-touched (except for improvements or bug fixes). New
objects were created by simply extending from the CGameObj class and redefining the
behaviours for that particular object.
I expect that the design could do a better job of separating the concerns and that any
future works with this code base should require that all systems be redesigned to use
common design patterns in an effort to increase cohesion & flexibility and lower
coupling between modules.
The current design is flexible to an extent, however object factories and generic interfaces
for things such as image loaders / model formats may be desirable.
Code reuse is taken care of by encapsulating data and methods into classes. Classes are
relatively low coupled, although this increase from assignment 1.
Singletons eliminate use of globals, however they are used in many areas of the system,
increasing coupling (making it harder to separately use modules in other projects).
All assets can be reused easily. The same objects can be placed in the world multiple
times, simply by adding more entries to the level.xml file.
The models at the moment need to be scale and rotated before being placed in the world.
This is not good for the art pipeline. Keeping track of matrix transformations applied to
every object is required, so that collision detection will work ok. At the moment, only
translations are taken into account.
Future Direction
There are a number of areas I see that need to be progressed with future development of
the code base.
It became clear that more time will need to be spent on design in future projects to avoid
re-factoring / hacks towards the end of the project. Although there was design done at the
start of the project, a better understanding of design patterns and game engines in general
is needed to avoid some common pitfalls later in the project (which we now have).
It will be essential to develop a solid framework of libraries, tools and classes prior to any
future development. Additionally some basic processes will need to be developed if I
hope to work in a group project / collaborate over the internet.
Refactor the OO design to make use of design patterns to increase cohesion, lower
coupling and increase flexibility
Hierarchical spatial sorting of world objects to speed up culling and collision tests
Page 23
ICT507 Assignment 2 Joshua Stewart
Integration of Fmod
Interactive 2D GUI system (for icons/gui elements/menus)
o Game menu’s / options
Matrix transformations / 4x4 Matrix class to allow objects to be rotated, scaled,
translated in world space, but still retain ability to do OOBB collision checking.
Animated Milkshape3D models using bones.
Terrain lighting & texture blending for different terrain heights or slopes.
Using terrain to affect players speed, more physics based collision response and
player movement (such as limited air control)
Rework camera system to allow 3rd person camera
Dynamic elements in the scene (animated objects, projectiles, particles)
Gameplay
Network play
World editor
3rd Party code
In assignment 2, no new libraries or 3rd party code is utilized. The items listed below
were integrated in Assignment 1.
SXP
A lightweight C++ library for object serialization in XML
MS3D Loader from nehe tutorial 31 by Brett Porter.
(http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=31)
Extended to include collision meshes and collision detection / culling
optimizations
ltga – TGA library by Lev Povalahev, a lot better than the nehe one which doesn’t like
the TGA’s paintshop created!
Thanks to Jon Cahill for providing some of the static models and Ray Depew for
allowing me to use his skier Milkshape3D character models.
Page 24
ICT507 Assignment 2 Joshua Stewart
References
Plane Equation
http://www.geocities.com/SiliconValley/2151/math3d.html
Frustum Culling
Gribb, Hartmann, June 2001, “Fast Extraction of Viewing Frustum Planes from the
World-View-Projection Matrix”, PDF from Internet. Accessed September 2005.
http://www.flipcode.com/articles/article_frustumculling.shtml
http://www.codesampler.com/oglsrc/oglsrc_12.htm#ogl_frustum_culling
Height mapping
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=34
Timers
http://www.lighthouse3d.com/opengl/glut/index.php?fps
Libraries / Tools
SXP (A lightweight C++ library for object serialization in XML)
http://sxp.sourceforge.net/
LTGA – by Lev Povalahev
http://www.levp.de/3d/index.html
Page 25
ICT507 Assignment 2 Joshua Stewart
Appendix A
SVN revision logs during development.
Revision: 1
Date: 8:59:41 PM, Monday, 17 October 2005
Message:
Assignment 2 - checked in from assignment 1
----
Revision: 2
Date: 3:29:52 AM, Sunday, 23 October 2005
Message:
nightly check-in
basic terrain rendering
----
Revision: 3
Date: 11:15:57 PM, Sunday, 23 October 2005
Message:
nightly check-in
refining terrain rendering
----
Revision: 4
Date: 9:02:32 PM, Monday, 24 October 2005
Message:
uni work (24th Oct 05) tutorial
changes to 2D Text Console system.
still broken
----
Revision: 5
Date: 1:00:20 AM, Friday, 28 October 2005
Message:
nightly check-in
refining timer class
----
Revision: 6
Date: 5:51:34 PM, Saturday, 29 October 2005
Message:
text console and timer class working well
----
Revision: 7
Date: 12:56:54 AM, Sunday, 30 October 2005
Message:
fixed 2d text console bug with opacity decreasing too fast regardless of lifetime value.
more functionality in player class, less in camera class. player now controls the camera more.
adjusted collision response for player so you cant slide through collision boxes now
Page 26
ICT507 Assignment 2 Joshua Stewart
adjusted game loop
added CPlane class
fixed bugs with equality in vector class
decoupled camera from user input
refactored model class collsion data and methods to use the new plane class
also some general clean up.
----
Revision: 8
Date: 4:20:50 AM, Sunday, 30 October 2005
Message:
experimenting with SVN branches for separating prototype code
----
Revision: 9
Date: 4:22:16 AM, Sunday, 30 October 2005
Message:
Main.cpp with motion blur effect
----
Revision: 10
Date: 11:28:10 AM, Sunday, 30 October 2005
Message:
small adjustments to speed up the motion blur
----
Revision: 11
Date: 7:33:44 PM, Sunday, 30 October 2005
Message:
Added Sphere class
Added bounding sphere info to Models
Added frustum plane extraction to level
Added sphere in frustum culling optimisations
Added DATA directory into the repository
----
Revision: 12
Date: 1:22:51 AM, Monday, 31 October 2005
Message:
added light and light manager classes\n
changed various areas to get lighting to work\n
heightmap used for player Y position\n
fixed bug in frustum culling - wasnt translating the sphere center position into world coordinates.\n
more hacks now due to OO design oversights\n
----
Revision: 13
Date: 1:36:28 AM, Wednesday, 2 November 2005
Message:
Added some more lights - exception handling for CGameObj destructor is broken when trying to delete
CLights.
Added documentation directory and start of docs.
Page 27
ICT507 Assignment 2 Joshua Stewart
Removed bounding / culling box rendering.
Added optimisation toggle key and code to UI.
Light Manager now sets ambient lighting.
Text console tweaking.
Terrain positioning uses XML data properly.
----
Revision: 14
Date: 1:41:42 AM, Wednesday, 2 November 2005
Message:
removed MSVS.NET files that will cause problems if multiple developers are updating their views. Not
needed for build.
----
Revision: 15
Date: 12:18:10 AM, Thursday, 3 November 2005
Message:
Stopped lights and player from being included in the frustum culling. Add CGameObj virtual method
isCulled() that needs to be implemented by each subclass.
Added markers for Lights in the scene.
----
Revision: 16
Date: 12:38:04 AM, Friday, 4 November 2005
Message:
added better snow texture, sloped terrain, streetlamp model
Added spot light support
----
Revision: 17
Date: 12:47:28 AM, Saturday, 5 November 2005
Message:
extended the CPlayer class to include more XML tags. Changed the CLevel so that player is loaded from
XML.
----
Revision: 18
Date: 8:45:07 PM, Sunday, 6 November 2005
Message:
Lights (spot and regular) are now created dynamically from XML file (including example in level.xml.
Beginnings of adding player model loading / display.
New player model and textures added.
New snow ground and rock textures added.
----
Revision: 19
Date: 1:03:44 AM, Monday, 7 November 2005
Message:
Player model working. Objects now pulled down to the ground height.
----
Page 28
ICT507 Assignment 2 Joshua Stewart
Revision: 20
Date: 1:39:44 AM, Wednesday, 9 November 2005
Message:
Added developer mode toggle to UI to toggle developer info such as culling spheres, bounding boxes and
textual information.
Fixed a number of bugs found during testing (frustum planes extraction, model loading)
Added light markers and unique labels.
Changed player movement and updates so that the player is affected by gravity when in the air.
Changes to XML following terrain/model/light changes, as well as beginning of level design and extensive
testing (including some load testing)
Number of new terrain maps, some model changes.
Some design document changes to incorporate testing results/progress. Checked in some new documents in
preparation for delivery.
----
Revision: 21
Date: 2:13:48 PM, Wednesday, 9 November 2005
Message:
Added item class for the power-ups (derived from CGameObj) which has redefined collision handling.
Added some models for power-ups.
Made Credits and Help Menu to use new shadowed console text so it is clearly displayed
----
Revision: 22
Author: murdoch
Date: 3:54:36 PM, Wednesday, 9 November 2005
Message:
fixed bugs in frustum culling and optimised
----
Revision: 23
Author: murdoch
Date: 3:12:23 AM, Thursday, 10 November 2005
Message:
Final build!
Code clean up before submission.
bug fixes / hacks for the text exception bug which is documented in the assignment documentation.
----
Page 29