Tue Aug 11 2009

Here are some of the fun personal projects I've undertaken over the years.

They were written in a variety of languages: C++, C#, VB6 using various APIs (OpenGL, XNA, etc).

Doom Engine WAD Reader (C#)

An old favourite of mine and many others, the Doom engine was heralded as a pivotal moment in software. It was always proven a fascination to me and a very enjoyable technology to work against.

This application looks into the game's archives and allows the viewing or playing of the various data files held within.

Doom Engine WAD Reader 002

Doom Engine WAD Reader 002

Doom Engine WAD Reader 002

Quake III Renderer (C++ & OpenGL)

Given id Software’s relatively open nature, the Quake series of engines were ideal to learn from to see exactly how a game engine works. All of the file formats are easy to work with, which lends themselves very well to self-education. With a simple rundown of the headers for the file formats, it’s essentially quite easy to get the gist of how the file formats work.

Quake 3 Renderer


  • Geometry is culled using PVS and Frustum Culling
  • Lightmaps
  • Meshes

Deferred Renderer (C# & XNA)

A deferred rendering rig demonstrating multiple lights (as illustrated by the respectively coloured spheres) and normal mapping wrote in XNA:

DeferredShading 2009-06-29 16-35-25-50

DeferredShading 2009-06-29 16-33-19-02

DeferredShading 2009-06-29 16-33-12-83

DeferredShading 2009-06-26 22-04-24-78

Bomberman Prototype (C++ & OpenGL)

This was a bomberman prototype that I wrote in C++ and OpenGL to demonstrate basic model loading and animation concepts for my third Computer Graphics assignment in University. It utilized the MD2 file format and the model in use was from a custom model pack for the advanced Doom ports.

In this demo, you could run around, drop bombs which would explode after a short time and if you were very unlucky, they could hit your player and he would do his well known Doom space sarine "death animation".

Also featured were particle effects for each explosion and basic shadow mapping (as illustrated by the shadow map in the bottom right of the screen).

CGAssignment03 2009-05-04 03-59-11-65

Model Loaders

Model Loaders » MD2 Loader and Renderer (C++ & OpenGL)

This is my MD2 loader showing the difference between surface normals distributed on a per-face basis resulting in the lighting taking on a facetted look (left), and those same per-face surface normals averaged per-vertex to allow for smooth lighting (right).


A renderer for the Quake II model format.

  • Animation
  • Per-vertex normal calculation
  • Linear Keyframe Interpolation
  • Automatic Bounding Volumes Calculation (Spherical and Box)

Model Loaders » MD3 Renderer (C++ & OpenGL)

A renderer for the Quake III model format.

MD3 Renderer

Model Loaders » T3D Renderer (C++ & OpenGL)

The Epic Games Unreal Editor (UnrealEd) exports its own native ASCII-based format. This is a loader and renderer for the format.

T3D Renderer

Model Loaders » 3DS Loader and Renderer (C++ & OpenGL)

This is my 3DS loader showing the difference between surface normals distributed on a per-face basis resulting in the lighting taking on a faceted look (left), and those same per-face surface normals averaged per-vertex to allow for smooth lighting (right).

3DS Loader and Renderer

Shadow Mapping

Shadow Mapping » Basic Shadow Mapping (C# & XNA)

This is an implementation of the basic shadow mapping algorithm wrote in XNA with a small 2x2 filter applied:

XNA Basic Shadow Mapping

Shadow Mapping » Parallel Split Shadow Mapping (C++ & OpenGL)

Parallel Split Shadow Mapping (PSSM) is an extension of the basic shadow mapping algorithm that splits the view frustum into several distinct pieces and as a result, multiple shadow maps representing these splits are rendered to.

In the image below, it can be seen that there are three splits, represented by the red, green and blue tint as applied to each fragment in the scene to demonstrate the algorithm.

These shadow maps represent the areas near to the camera, furthest from the camera and anywhere inbetween (depending on the amount of shadow maps; usually two or more, but in my case, three) and the appropriate shadow map is sampled when it comes to rendering the final scene base on the distance from the camera.

CGLDissertation 2009-12-01 14-14-29-18

Ray Caster

Partially Hardware Accelerated Version (C# & XNA)

The reason I call this "partially hardware accelerated" is because actual work of calculating the intersections is performed by the CPU, where as drawing the output is performed by the GPU by way of appropriately textured lines.

In order to speed up the process even more, the next step would be to offload all calculations and rendering on to the GPU.

RC 2009-11-29 15-15-22-26

RC 2009-11-29 15-14-57-82

Software Rendering Version (C++ & WinGDI)

The first ray caster I wrote was in C++ and I made a port for Pocket PCs and desktop PCs.

Showing a basic indent into the wall:

Ray Casting

Showing a corridor:

Ray Casting

Now with textures:

Ray Casting

Added some coloured ceilings, similar in style to Wolf-3D (1992):

Ray Casting

Funny colour gradient for the ceiling to give a sunset look:

Ray Casting

Testing some floor/ceiling textures (1):

Ray Casting

Testing some floor/ceiling textures (2):

Ray Casting

Ray Tracing (C# & XNA)

RayTracing 2009-11-22 16-32-05-87

RayTracing 2009-11-22 20-44-19-56

RayTracing 2009-11-22 20-50-26-31


Terrains » General (C++ & OpenGL)

Soon after I had per-vertex normals calculated for the heightmap based terrain, I decided to stick a few lights on it.


A basic height based texturing scheme, where height points are assigned a snow texture and lower points are assigned a grass texture.

terrain - heightbased texturing

As inspired by Red Alert 3's drop selector, I decided to create my own version "selection projection" which works in pretty much the exact same way. Wherever the mouse is on the screen, by way of unprojecting the 2D window coordinates back to 3D coordinates, I can decided where on the screen to project the decal.

CGLDoomRTS 2009-03-10 02-33-39-32

Terrains » Chunk Based Culling (C++ & OpenGL)

Terrain Chunk Based Culling

Terrain Chunk Based Culling is a method for splitting a terrain into a preset number of chunks that are tested against the view frustum to see if they are visible and renders those chunks if necessary.

While this method does increase performance dramatically (From roughly 4fps for a brute force render to 240fps) a 1025×1025 terrain split into 32×32 chunks however needs to perform a total of 1024 frustum checks. This in itself wasted too much performance. A hierarchical culling algorithm such as a quadtree should be incorporated to cull out large amounts of geometry with only several checks.

Doom Map Viewer (C++ & WinGDI)

Doom Map Viewer is the forerunner to a top-down 2D geometry editor wrote in C++ / Win32 API. It currently displays the maps and allows navigation of the map, zoom feature, etc.

It comes equipped with an image viewer supporting all known Doom formats such as textures, sprites and patches for Doom WADs, as well as a sound player for PC Speaker and Digital Audio effects.

Doom Map Viewer

WinProcInfo (C++, August 2004)

WinProcInfo was a utility for providing information about the user’s processor and general system information. I had never before used C++, Object Orientated (OO) software development, or assembly. It was decided that the development of WinProcInfo would be how I would learn the aforementioned skills.

The biggest downfall of the application that disallowed it any chance of competing with the similar applications out in the wild was my lack of ability to create a device driver that would allow reading of the Model Specific Registers (MSRs) that provide detailed processor information, such as multiplier, temperature, etc.

While my ability to learn C++, OO and basic Assembly on the fly was achievable, writing a device driver to handle the above was unachievable at the time.

I had to recompile the project and take these screenshots on my Windows 10 / Ryzen 5 3600 system 😜 - A lot there is incorrect a mere 17 years later!

WinProcInfo - Processor Tab

WinProcInfo - Cache Tab

WinProcInfo - System Information Tab

OPN64 (Originally OPN-462) (Visual Basic 6, April 2003)


OPN-462 / OPN64 Althon XP PR Calculator

The idea for OPN-462, which later became known as OPN64 was conceived in April 2003 as a just-turned-17 year old novices first attempt at programming. The idea behind OPN64 was to provide detailed information about an AMD based processor going by the three Ordering Part Number (OPN) codes on or around the processor’s core.

OPN64 eventually appeared in several computer magazines around the world as freeware and was featured for download on many major sites

GatsbyNetlifyReactTypeScriptTailwind CSS
© Copyright 2008-2022 Terry Butler