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).
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.
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.
A deferred rendering rig demonstrating multiple lights (as illustrated by the respectively coloured spheres) and normal mapping wrote in XNA:
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).
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.
A renderer for the Quake III model format.
The Epic Games Unreal Editor (UnrealEd) exports its own native ASCII-based format. This is a loader and renderer for the format.
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).
This is an implementation of the basic shadow mapping algorithm wrote in XNA with a small 2x2 filter applied:
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.
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.
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:
Showing a corridor:
Now with textures:
Added some coloured ceilings, similar in style to Wolf-3D (1992):
Funny colour gradient for the ceiling to give a sunset look:
Testing some floor/ceiling textures (1):
Testing some floor/ceiling textures (2):
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.
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.
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 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.
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!
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