Download

Applied Research Project (PDF, 1.93 MB)

Abstract

This project examines whether concepts of place can be usefully applied in game AI, specifically in the context of authoring agent reactions. It reviews current spatial approaches to world representation in games and literature on place from other disciplines. A conceptual model of place for use in game AI is then proposed, influenced by the theories of implacement and affordances. A place agnostic test case is presented, together with an analysis of two parallel implementations of it; a control implementation and an implementation derived from the proposed model of place. The implementations are then analyzed in objective terms, revealing that the place-based implementation performs worse but supports authoring better. The recommendation of this report is to use place-based representations judiciously, bearing in mind their additional overheads as well as their authoring benefits.

Critical Evaluation (abridged)

I am generally satisfied with the outcome of this project although I would have preferred (if time had allowed) to employ a more thorough methodology. As it was, I felt that the scope of the project was too limited, given the scope of the topic. I am pleased that a model of place was synthesized, but disappointed that the scope of the project prevented me from exercising it fully. If I could do it again I would focus more on layering behaviours rather than agent reactions.

There are many sources of information on concepts of place, across a wide range of disciplines, and their study has been very interesting. One point of difficulty was the high level of noise to signal found in the more philosophical writings, which might make this material inaccessible to game AI practitioners. In this respect I feel the industry could benefit from more literature reviews and summaries of thought in this area, and perhaps more multidisciplinary collaboration in the study of place. I am pleased with the literature review section of the project, which I feel provides a useful summary of thought in this area in fields which might not usually be considered by game AI practitioners.

There is definitely a movement in the game AI field towards more complex, semantic representations of spaces (driven, I believe, by the increasing complexity of agent behaviour) and concepts of place have been proposed as the way to achieve this. From my experiences throughout this project, I tend to agree. Implacement is the foundation of our experience of the world around us, and games have always striven to create the feeling of implacement in virtual environments. As graphics technology improves, virtual worlds have become more and more realistic, yet virtual agents often appear to behave unnaturally; unbelievably. I suspect that the reason this is so jarring to a human observer is because it makes it apparent that the agent itself is not implaced in its environment, a similar phenomenon to the ‘uncanny valley’ in robotics (Mori, 1970). I believe that applying concepts of place to agent architectures, for the purpose of implacing agents in their environments, is the most natural approach to overcoming this problem.

Overall I have found this to be a very worthwhile project. I feel well placed to apply the knowledge gained during the project to my game programming practice.

Through this process I was able to gain insight into the challenges facing both middleware providers and integrators.

Build Phase

I chose to design and implement an input abstraction layer called HInput. The primary purpose of HInput is to decouple game/application code from specific input implementations. For example, rather than checking whether a gamepad button is down, or a key was pressed, we just query whether a named input was satisfied without needing to know how exactly it was implemented. This extra layer of abstraction gives us the flexibility to:

1. Change input schemes without code changes or recompilation.
2. Dynamically switch between input schemes at runtime (e.g. we might choose to load a new scheme if we detect that a gamepad was connected). We can mix and match schemes, and different player can use different schemes. All this is completely transparent to the game code.
3. Using input metadata, it is possible to allow dynamic configuration of the system at runtime (which is how the HInput Editor works).

HInput also has various layers of complexity in its interface:

1. The simplest way of interacting with the system is through the Editor application (written in C#).
2. The InputManager singleton [HInput::GetManager()] provides everything you need to use an input configuration to provide input to your game.
3. Advanced users can write custom Inputs, InputDeviceServices, and plugins that can be loaded dynamically at runtime, as well as custom GUIs using the InputMetaData stored in the system.

Full source code and compiled distributions of HInput, complete with documentation, example projects and editor application and plugins for keyboard and gamepad are available from Sourceforge. For an overview of the system, please read Getting Started with HInput.

Leverage Phase

In the leverage phase I chose to build a tongue-in-cheek action RPG style demo based on the Gamebryo ‘Kinslayer’ sanple, called ‘Kinslayer-Ville’.

Conversations are all voiced at runtime using Microsoft SAPI. There is also voice recognition to choose conversation options. The Environmentz day/night cycle skydome is supplemented by CIELO clouds. Inventory is with Happy Sacks. LibCT provides the conversations and QuickQuest provides the quest log. Input is through my own HInput input abstraction layer. The opening cinematic is powered by Cinesigner, while FMOD Ex provides 3D positional sound.

It provides a basic interface for TTS, and a dynamic ‘command and control’ grammar for SR (as opposed to the ‘dictation’ grammar which is easier to get working but fairly useless for games). You can specify a word or phrase at runtime and this code will create a grammar rule to listen for it.

The download includes source code and a sample Visual Studio 2008 project.

Download Source (9KB)

Develop Magazine, June 2010, p. 64

Before

After

Key Improvements

• Fixed numerous deliberate bugs including buffer overruns.
• General graphical improvements.
• Gameplay improvements (enemy behaviour, player control, scoring).
• Implemented support for DirectInput and XInput. Gamepad allows analogue control of rotation and thrust.
• Implemented a gun base class and three guns; machine gun, bomb (falls under gravity) and splitter gun. Machine gun is weak but fast, splitter is devastating at mid range but not so good at short or long range, bomb will take out anything it touches but is hard to use.
• Used XAudio2 (encapsulated in a singleton manager) to implement music and sfx. Base game state automatically changes music. Each gun has a firing sfx and there is an explosion sound for enemy/player destruction. There is also an engine noise which changes pitch and volume with the throttle (right trigger on gamepad). There is a built in interpolation so that it works with the digital keyboard input too.
• Implemented 3 different types of enemies, with differing sizes, colors and health.

Download

Download executable (7.8MB)

• Finite state machines
• Steering (seek, flee, path follow)
• A* graph search for pathfinding
• Goal Oriented Action Planning, using the same A* graph search code used for pathfinding

The work was graded A- with these comments from marking tutor (and noted game AI practitioner) Adam Russell:

Highly challenging extension topic (planning). Great documentation, with UML diagrams and discussion of reference texts. Full coverage of requirements, in a manager showing great evidence of orthogonality, abstraction and asynchronicity. Steering is solid…, pathfinding is really the highlight though as an abstract graph search powers both GOAP plans and an asynchronous pathfinder! Very very nice.

Download

Executable demo -  AIDemo.zip (47.4KB)

-

I was responsible for designing and implementing the weapon system (including stasis and kinesis), dynamic (‘fear’ based) music management system, data-driven player control schemes and one of the minor bosses, as well as other game programming tasks. I programmed in C++ within a mature codebase.

My lead programmer was kind enough to write me this LinkedIn recommendation:

“Henry joined my programming team as a placement student at the start of our one year project, and returned to university after the project had completed, giving him the experience of a full project life cycle. Henry integrated with the team fantastically, and very rapidly became an invaluable member of the programming team. Henry has an excellent work ethic, he plans his work thoroughly and embraced the code design process we use within the team. The standard of Henry’s code is excellent, and he works extremely quickly and efficiently. I was able to assign very complex systems for Henry to design and implement with confidence. I would not hesitate to recommend Henry to any employer, and was sad to see him leave the team to return to his university course.”

September 1, 2009
Gareth Clarke, Lead Programmer , Eurocom

Other students or junior programmers may find my article about the lessons learned on placement useful.

Players are shown 40 items of waste and must chose the correct disposal container for each one. Players gain a point for a correct answer and loose a point for each wrong answer. However players cannot progress until the correct conatiner for the waste is found. A high scores table is presented at the end of the game.

The benefits of the electronic game over the paper game are:

• Easier to copy and distribute
• No need for a supervisor who knows the answers to be present while the game is played
• No possibility of wrong answers accidentally being allowed
• Score mechanism encourages competitive play

It was developed in Game Maker and took about 5 hours.

Download Executable

Health Waste.zip (3.76 MB)

The prototype phase gave us a good idea of how the games would work in practice. The runner up (by Chellaston School) was a scrolling platformer called ‘Eco Warrior’, in which two teams of two competed against each other above and below ground to collect tokens and powerups. As such it would have been a much easier game to implement, but it was felt that it lacked depth and had not been pitched particularly well. Therefore Swanwick Hall’s ‘Celebrity Game’ was chosen for full development, despite the prototype itself being less polished than its competitor.

The game was to run on a Windows platform, but it would have to be shown and played on the Derby city centre big screen (rather large but also rather low resolution). It had to support four players so we decided that Xbox360 controllers were the way forward rather than crowding the keyboard.

This post-mortem is from my point of view as Project Manager and Programmer.

What went right

1. Development Process
   From the start we employed an iterative development process. In the prototype phase we required the teams to produce something complete at the end of each day. In main production we set three milestones over the two week period with clearly defined requirements.

   At the start of production the main difficulty was that the game design was not nailed down, so we had to be very careful not to spend all our time designing and no time implementing. We did this by giving one team member responsibility for the design elements while the others implemented common systems which we knew would be required whatever happened. The design changed rapidly at first but by the second milestone it was completely nailed down.

   Because of the very tight timescale I had to make some decisions about what made it into the final game. While not always popular, I think the desired effect was achieved. For example, I declared the game mechanics unchangeable after the second milestone, allowing only presentation work. I also rejected a number of design proposals from management which we could not have implemented in the time allowed.

   By doing this I made sure we had enough time at the end of the project to complete the essential visual polish (e.g. title screens, menus, tutorial, credits, etc.) without which even the best game would have seemed poorly made.

   Our technical manager, Adam Russell, commented that the trajectory of the project was similar to that of a much larger one if it were compressed into two weeks.
   
   

2. Considering the Platform
   We paid close attention to the target platform – the Derby big screen. We were given technical specifications by the BBC but took the precaution of visiting the screen twice for testing purposes during development. This enabled us to tweak elements of the game (e.g. font size) and identify some technical issues, namely our lack of appropriate connectors and the significant latency between the screen and the control room that made it nearly impossible to play the game in real time on the screen. We were then able to solve these issues well in advance of the launch day.

   The platform also dictated the audience. The game would have to be ‘pick-up-and-play’ which caused us many problems bearing in mind that the winning game was selected due to its depth of gameplay. We constantly had to balance these two goals during development.
   
   

3. Choice of Tools
   The original plan had been to develop the prototypes in Game Maker and then the final version with XNA. However, once the winner was chosen it became apparent that we would not have time to implement it fully in XNA so we chose to continue using Game Maker.

   I believe this choice was the right one, although there were pros and cons. On the positive side, we ended up with a much better game. Had we used XNA we would have had to essentially re-write at least half of Game Maker before we could start actually designing the game. We simply did not have that kind of time and it is likely that, even if we had, the result would have been buggy and still visually no better than Game Maker output.

   However, it was not all plain sailing. Game Maker was never designed for team development. It is possible to import scripts and whole project files but this was only really useful for complete subsystems. Especially towards the end of the project we found that project-wide changes were necessary. However, we learned a lot about how to use Game Maker collaboratively:

1. • We used Subversion for source control, although this had to be over the whole project file (which grew to about 12MB by the end) resulting in long commit times.
   • After the first week we used a physical ‘build-token’ (a Lucozade bottle) to show who was currently making modifications to the active build. After the changes were committed the token was passed to the next team member who needed it, essentially locking the project file.
   • Wherever possible we developed subsystems independently before importing them into the project (e.g. the game timer, the player and shop state systems, the particle effect systems, the gamepad wrapper).

There was also some initial opposition within the team to the idea of using Game Maker for development, but this snobbery mostly disappeared by the second week. However, the team consistently underestimated the API and in some cases wrote features that were already available.

1. Game Design
   As mentioned above, we started main production without a clear idea of how the game would actually work. The prototype had a number of design flaws and the final game turned out to be quite different.

   The original pitch was for a game about four celebrities who each had to buy four items from a mall. If they bought the most expensive items they got a golden ticket and entered a maze to go to an awards ceremony. At certain points there were paparazzi who would photograph them and slow them down. Therefore there were elements of racing, item collection, and puzzle solving involved.

   In the prototype phase the main question which kept popping up was ‘how do I win’? The mechanic was so complex that in many cases the victory condition was undefined. At this stage it was also taking about 15 minutes to explain how the game worked.

   However, we had a breakthrough after the first milestone. We realised that the unifying principle was fame. By ditching item collection entirely and basing victory on fame we made the game a lot simpler to understand and more fun to play. We also hit on the idea of representing current fame by the size of the player’s head (instead of a separate fame-o-meter), saving valuable screen real estate. After this breakthrough we were quickly able to come up with a simple system of player states (good/bad/neutral) and transitions and soon afterwards nailed down the gameplay.

   The only remaining problem was picked up in playtesting – namely how to tell who is currently in the lead (as only the leader is able to throw other players out of the limo – the player in the limo at the end of the game is the winner). At the time we agreed on a racing game style place number indicator, but after implementing this we realised that there could be a usability problem if the player in first place did not win at the end of the game (because they were not in the limo). We didn’t want to lose the limo as running after it had proved to be a fun mechanic in playtesting. We therefore hit on the idea of using a crown to denote the current leader. Only if a player wore the crown could they displace another player from the limo.

   The game design could have gone very badly wrong, but in the end I think the final product is readily comprehensible, has some depth and more importantly is fun to play.
   
   

2. Art
   We were very pleased with the character art and environment art produced by our team of artists (two of whom were unpaid volunteers). In particular, the inspired character art and animation of Ash Barnard was right on target in terms of the feel we were aiming for. All the art produced by the team fits in well with the farcical theme of the game and significantly adds to the game experience.

   Collaboration between the artists and programmers was good, for example on issues such as alpha channels, visual style, tile-set implementation, etc. The programmers made sure the artists knew the technical requirements of the platform. The artists took direction well and provided the art in a format we could use.

What went wrong

1. Team Selection
   The team size and composition was based on incorrect assumptions, namely that we would be developing the game in XNA. Because I had serious concerns about our ability to do this within two weeks, I pushed for more programmers than artists initially. However, once we decided to use Game Maker we no longer needed as many programmers and found ourselves lacking in artists (having only one). We therefore reached the second milestone without very much in the way of environment art, which caused a lot of concern. Once we were aware of the problem we petitioned Andreas, the studio manager, for an extra artist. We were also lucky enough to have two unpaid volunteer artists working with us in the final week of the project who contributed greatly to the environmental art.

   In general I was very happy with the quality of the team. However, we did have one team member who turned out to be a subscriber to what Julian Gold calls the ‘Hacker’s Charter’. Despite being arguably the best programmer and a very intelligent and likeable individual, he suffered from…
   
   

“…the tendency of team members (programmers in particular) to ‘go off on one’ and spend disproportionately large amounts of time on non-critical tasks”.
[Gold, J. 2004 – Object-oriented Game Development, Addison Wesley, Harlow]

Sadly this habit (especially undesirable in a two week project) meant that a lot of my time was spent curbing his worst excesses (e.g. advanced AI, unnecessary movement modes, premature optimization) and I had to ‘stamp’ on him quite hard on more than one occasion when he disagreed with decisions I had to make for the sake of pragmatism.

1. Arguably the Choice of Winner
   We could have saved ourselves a lot of time and effort by backing the easier and more well prototyped of the two designs. If this had been a purely commercial project then we would have done so, but we had to bear in mind that there were also academic goals for our client and in the end it was felt that the winning school should be rewarded for their superior pitch. It was also felt that the team (composed entirely of undergraduate students) would benefit more from the more complex and challenging option. In the end, however, the choice of project was vindicated, but I am sure we could have made just as good a job of the other design and had more time to make it really sparkle.
   
   
2. Perhaps Too Many Cooks Management-wise
   Within the studio itself we had several layers of management. First me, as project manager, then the studio manager, then two academics in the technical and art management roles, as well as a number of other academics involved in the design and playtesting process whose opinions carried far more weight than the average playtester due to their positions.

   Things worked out well in the end but at times there were so many people giving (conflicting) input to the project that it was hard to know what to do.
   
   

3. Unfixed Bugs
   Because of the very short timescale there were some known issues which we had to decide not to fix. One of my more unpopular decisions was stopping bug fixing on the ‘double bad pose’ bug, where the negative pose animation always plays twice instead of once. However, as I had already lost one team member for the entire morning trying to track it down, and it did not seriously affect gameplay, I decided it was not worth wasting any more time on. There are one or two other obscure bugs that occur under certain rather rare conditions which I also decided we did not have any more time to spend on fixing.
   
   
4. Communication with our Client
   There were layers of management within our client which made things more difficult. For example, our client department had no connection to the big screen department who had to approve content and supervise our testing visits, who in turn had no technical staff on-site. It was also unclear how much priority was being given to the project, as in the end it was only displayed on the big screen for 30 minutes during the day.

Conclusion

The team is rather proud of the finished game, and the client is very happy. The game met all the requirements laid out by the client and was considered fun and ‘awesome’ by the players on the day. It also has some depth to it without confusing the casual player too much (everyone who played it got to grips with it fully by their second turn).

I think we worked well as a team, learned some important lessons, and turned out a great product considering we only had two weeks.

The University has issued a press release about the project.

The Project

Our client, BBC Blast, ran a competition for local school children to design and pitch game concepts. The first stage of the project was to develop prototypes of the two best entries using Game Maker, over three days.

Once the prototypes were completed, the winner was selected and their game was developed for a further two weeks.

The finished product was shown on the Derby city centre big screen on 25th June 2008 and will be published via the BBC Blast website, and the studio’s own website.

My Role(s)

I was hired as the Project Manager, reporting to the Studio Manager, Technical Manager and Art Manager. In the prototype phase (3 days) I managed two teams, each consisting of two programmers and one artist. I also wrote some code to support both teams, such as a class to manage an XInput extension and some vector manuipulation functions (dot product, magnitude etc) which were requested by the teams.

In the final phase (2 weeks) my role changed to include more programming, as well as leading the enlarged team and managing the project.

The final product was a great success (described as ‘awesome’ by a number of players) and more importantly the client was very happy.

My contract was also extended to help in providing three game development workshops for young people during the BBC Blast on Tour (Derby) event.

My Credits

Project Manager
Programmer
Music

Gameplay Video

Additional Info

As well as my own postmortem on the project, one of the other team members has written about the project.

Click for Postmortem…

Overview

This is an extract from the notes given to industry guests attending and assessing the final presentation of our work:

The students have been allocated into programming teams (‘studios’), given a flaky brief (space-trading game) and provided with industry standard tools (Gamebryo, Subversion). The focus of the module has been to give the students a team industry experience preparing them for life during their placement.

They have experienced a number of typical studio problems including being given particular technology to integrate (Crazy Eddie’s GUI System), one ‘studio’ going out of business and they have recently pulled an ‘all-nighter’ to prepare their game for E3 – it falls early this year :)

What went right

1. From the start we did not underestimate the difficulty of the task – this ‘constructive pessimism’ served us well in hitting milestones. We had regular meetings and insisted on full participation in the project from all team members (knowing from experience that this is a common problem with student projects).We used Assembla, an online project management system, to assign tasks, track bugs and maintain a wiki of useful information. We communicated well throughout the project. We kept in contact through meetings, email, phone and Assembla. We got into the habit of putting full comments on our Subversion commits which made it easy to track what was changing.
2. We wrote systems to be as generic as possible, which was useful in the final stages when we had to add a lot of content in a hurry because few code changes were needed. The basic architecture was a GameObject class with derived Ship and Planet classes. Other objects were composed with the Ships to represent their internals (i.e. engine, weapon bay, cargo hold and resources). This encapsulation was useful. For example, the CargoBay was re-used for the TradingPost class later on).We also wrote a scene graph manager to enable us to ‘warp’ to other galaxies. Each scene graph stored a pointer to its root node and an instance of the Ship and Planet Manager classes.
3. We completely abstracted the game input by implementing InputProvider classes with a common interface to convert input (e.g. from the Xbox360 controller) into a set of defined GameInputs – namely roll, pitch, yaw, throttle and stop. This helped us when we had to make radical changes to the gamepad input code later on, by confining the code that had to be changed to the InputFromGamepad class.It also allowed us to easily implement AI behaviours. Starting with simple wing levelling behaviour, a hierarchy of input providers was built to provide steering towards an object, throttle control, formation flying, and, ultimately, trader or pirate behaviour for NPC ships – all using only the basic GameInputs mentioned above.This AI behaviour was also used to provide a ‘fly-to-target’ autopilot feature for the player’s ship.This architecture would also make it easier to implement a networked play mode, and indeed to extend the AI framework with more advanced behaviours.
4. We decided early in the project to load in all our data via XML. Team member Jamie integrated TinyXML and wrote most of the loading/saving code. This proved to be a very good decision as it gave us complete flexibility to change the design and content of the six solar-systems, from how many ships there were and what they looked like, to the speed at which planets orbited the sun, without any code changes. It also allows player customisation and gives scope for a level design tool.
5. We used FMOD to add music, sound effects and voice cues late in development. It proved powerful and very easy to work with. By using sound to provide feedback we were able to avoid a lot of GUI programming as well as create a more immersive experience. FMOD provided all the sound channels we needed and more, as well as the ability to change frequency and volume on specific channels (which we named using an enum), allowing the variable pitch engine noise and changing music depending on mode (battle/trade/normal).

What went wrong

1. At the beginning of the project we essentially wasted two or three weeks getting to grips with Gamebryo, mainly due to our attempts to extend the engine’s classes for our own game objects. It was not until we abandoned this idea and built our game engine separately (with handles into the graphics engine instead of being part of it) that we made any progress.
2. We should have spent more time reading the Gamebryo documentation. In particular we did not really get to grips with the memory management system until near the end of the project and we struggled with when to use smart pointers.
3. We probably suffered from a lack of design and overall vision initially – being programmers we tended to put programming first (especially as we knew we were not being assessed on our art or design skills). However, at the alpha presentation we felt that our game did not have the necessary wow factor (although arguably the most solidly built). Between the alpha and final builds we spent all our time on visual and gameplay polishing.
4. It was always an ambitious project, and our desire to do it well and produce a great game unfortunately led to us not spending enough time on some of our other coursework, and left no time for personal projects.
5. In the early stages we did not spend enough time working in a group environment, tending instead to code as and when we could. As time went on this improved and we found it very helpful to be working in the same physical location at the same time.

My Contributions

• Management
  • Conducting meetings
  • Keeping documentation
  • Maintaining project schedule
• C++ code
  • Scene graph manager
  • Game object managers
  • Input / AI / Autopilot / Targeting
  • Gameplay tweaking
  • Engine sounds, music, ship voice

Conclusion

We all learned a lot from the project about working in a team environment, and about debugging!

Development Videos

Lead programmer Bret has some videos of the game at various stages during the all nighter:

Alpha Build
Alpha Build Second Video
Development Video 3

Links

Assembla – Free project hosting
Crazy Eddie’s GUI System
Emergent’s Gamebryo
FMOD – Music and Sound Effects System
University of Derby

My demo starts by running a scripted demonstration of the various features supported, culminating in a Martian disco! After the script runs, buttons are revealed to allow the demo to be used as a sandbox. 2d and 3d effects can be turned on/off by the user. The user can also choose to run the script again.

The demo features an animated Marvin the Martian, loaded from MD2 format. In addition to rendering the demo features both 3D effects (such as spike, pulse, dissolve and character animation) and 2D image post-processing filter effects (such as gamma correction, brightness, bloom and blur). The effects are implemented as loosely coupled objects which decorate either a game object or a rasterizer.

Update (12 March 2009) – I have now fixed a few problems with the renderer. Specifically:

• It now interpolates properly between animation keyframes.
• The orbit camera now works.

Download

Executable – CPPSoftwareRenderer.zip (1.37MB)
Readme – Readme.pdf (87KB)

Features of the Software Renderer
• Vector and Matrix classes – implemented as fully functional data types with overloaded operators, copy constructors and accessors. Support add, subtract, scalar divide and multiply, cross and dot products, transpose etc. Also provide static matrix generation methods e.g. identity matrix, rotations, translations, scaling.

• Camera – The camera is able to change position.

• Rendering pipeline – The rendering pipeline is comprised in MyApp::Render(). In order for effects to be applied in the correct sequence (some need to be applied post-transform, pre-render) the pipeline has three stages. Render() is called after movement effects have been applied (DoMovement()). It distinguishes between the various render modes in use (e.g. there is no need to light the model if we are only drawing wireframe or outputting a texture for debugging). The pipeline then splits into TransformObject() and DrawObject(). The former deals with normal and lighting calculations, transforms to camera space, culling and sorting polys (if appropriate). The 3D effects manager is then called before DrawObject(), which handles perspective and screen transforms and renders the model. After this the pipeline deals with 2D post-processing effects and filters, before flushing the pixel buffer to the GDI+ bitmap, drawing text and framerate, and drawing the bitmap to the window.

• Rasterizer – As mentioned above, my rasterizer makes use of a pixel buffer for drawing. It supports rendering in the following modes:
o Wireframe
o Flat shaded (GDI+)
o Flat shaded (manual)
o Gouraud shaded
o Textured
o Textured and lit
o Textured, lit and gouraud shaded
o Texture debug

In addition it supports a number of 2D filters, namely:
o Inverse (negative)
o Grayscale
o Colorisation
o Brightness adjustment
o Gamma adjustment
o Blur
o Line scan
o Bloom
o Jitter

I have combined a number of these filters in my demo to create effects (e.g. a ‘retro’ filter comprising greyscale, color (sepia tone) and jitter).

• Z–Buffering – The rasterizer supports Z buffering through the ZBuffer class, allowing per-pixel sorting.

• Polygon culling and sorting – Depending on draw mode, various methods are used, such as: polygon sorting with std::sort and a predicate function; backface culling; whole polygon culling outside view port; line culling in wireframe mode. Clipping is not supported.

• Lighting Support – Lights are implemented as a base class (Light) and three derived classes (LightAmbient, LightDirectional and LightPoint). These are tested and functional and the scene contains one, two and one of each, respectively. MyApp contains arrays of each type of light, making it simple to add and remove lights as required, although it might be nicer to have a light manager to handle this.

• 3D Effects – My renderer includes an extensible effects framework using the decorator pattern. It was initially meant to handle 3D effects on objects, but I found it very handy for creating effects to apply to the rasterizer and the camera.

The abstract base class, Effect, provides an interface for effects, which decorate an Object. Derived effects simply implement the Update() and Undo() methods in addition to any code of their own.

In practice I found it very easy to create new effects using this framework, even filter effects, for which I simply used a dummy object and passed in a rasterizer. With hindsight it might have been better to further abstract the base class and build on three derived classes – EffectObject, EffectRasterizer and EffectCamera, rather than having a redundant object pointer.

o Effect Manager – The effect manager comprises a linked list of Effect*. With polymorphism, effects of any type can be passed in, and the manager then Update()s these every frame, deleting them when they have finished. In this way, effects can be created and then forgotten about.

o Spin – Applies a rotation about a specified axis for a duration.

o Spike – Smoothly transforms verts outwards into spikes and back again over a time period using Object::Spike. Customizable offset and magnitude.

o Pulse – Smoothly transforms verts outwards and inwards in a sinusoidal pattern. Customizable frequency and amplitude.

o Rainbow – Modifies the reflectance co-efficients of an object over time in a randomly fluctuating pattern to give a rainbow effect.

o Dissolve – Uses a predicate std::sort to order polygons by average Y value, then over a duration culls them from top to bottom, giving a disintegration effect.

o Animation – Applies an animation to a model over a period. When object is loaded the key animation frames are stored in an array of the KeyFrame class. Object::LoadFrame() simply adjusts the Object::_vertices pointer to point to the relevant KeyFrame::_vertices array.

• 2D post processing effects
o Color filter
o Grayscale
o Gamma
o Brightness
o Bloom
o Blur
o Lines
o Jitter
o Inverse

The Scene

• Direct camera manipulation
• Several objects being transformed in different ways
• Light sources
• User options

Optimization and performance
I kept track of the optimisations I performed on a spreadsheet.

• Pixel buffer – The primary optimisation made, which resulted in a framerate increase of 56fps in textured mode, was doing all drawing to a pixel buffer and then flushing this to the GDI+ bitmap once per frame, intead of using Image::SetPixel(). A side effect of this was that it made post-processing much easier and faster, as this was done directly on the buffer.

• Float to int conversion – Profiling revealed the biggest bottleneck was float to int conversions using __ftol(). I replaced this with some third party code (referenced in my code – float_cast.h) which resulted in an improvement of about 5fps in some cases. Time was also saved in some of the image filters.

“The total Lift force is the integral of vertical pressure forces over the entire wetted surface area of the wing.”

This got me wondering about how to calculate the definite integral of a function programatically, so I wrote this program which aproximates the area under a curve to a given degree of accuracy by breaking the area up into a number of trapezoids.

Download

Source: integral.cpp (3.0 KB)

Update

This post is now [3 July 2008] the most popular on the whole blog. If you find it helpful (or not) please leave a comment. Thanks.