Overview
- An overview of all my work
Preamble
I've been programming for a long time, I may have not been very good for much of that, but it was a long time nevertheless.
During this time I've worked on a number of projects, some of which I'll present to the world here. These are available from my Subversion server, though access is not currently available until I decide if it's a good idea or not to:
- a) make all my tidbits of code open source.
- b) distribute stuff that have minor copyright infringing bits in them (think sprites etc)
Also, please bear with this standard legal bases-covering:
All executable materials provided on this website are ©1998-2005 Jamie Thompson, as are the majority of the media assets. There may be media assets included in some of the downloads which were taken in whole or in part from publicly-availible sources on the internet. If you are the copyright holder and wish access to be removed, please let me know and I will remove the works from this page, but to the best of the author's knowledge they were freely available at the original time of download. Any source code made availible, unless explicitly stated otherwise by an enclosed license, is licensed only to the user downloading the file, and only for the purposes of review, and may not be distributed in either original or compiled form without express permission of the author.
Now, I doubt anyone will even be interested in any of my stuff, but now that we have that out of the way, onwards...
School-era projects
Project RPG, a.k.a. Zelda++
I began a project long ago to develop a Zelda-esque game, and as it developed I discovered I needed content to test the code I was developing. I decided to use the maps from the NES Zelda until the time came when the game code was nearly finished, however even this was far too ambitious a learning project and I was forced to abandon it due to the code base becoming too difficult to work with. I was still struggling with the principles of OOP, and decided that I would begin work on a generic 2D game engine as an exercise in good OOP. Please bear in mind when looking at the time scales that I was a) still at school and thus had other work to do, b) had little to virtually no internet access, c) had no reference materials nor guidance from teachers. :)
This project reached a *limited* level of success, and you can view the project in various stages as it was left by clicking here (1997/12/10 - qbasic original concept), here (1999/03/24 - C/Win32/DirectX version), and here (2000/01/31 - C++/Win32/DirectX version). I've left these files in the state they were in since they were abandoned, (just bear that in mind when examining the enclosed contents).
Sixth form-era projects
The Game Engine - Direct2X
The version of Zelda++ shown is one where the game engine functionality is almost completely separated from the game logic itself; it is far from neat however as it was not designed this way, and in fact is an awful set of untidy hacks, but it works.
I proceeded to rewrite a better game engine, designed properly this time, and the end result was the originally-named "Game Engine MKII". This engine had several notable features (these are just the ones I remember off the top of my head):
- 4 virtual controllers with up to 32 buttons mapped to any number and combination of physical inputs (think both keyboard and joystick buttons on one virtual controller along with analogue mouse axes)
- Time-indexed animated sprites
- AVI playback with sound
- OGG Vorbis, WAV, and MIDI playback with play, pause, and stop controls
- Bitmap fonts
- Automatic pixel format conversions between arbitrary channel depths when required
Nothing to exactly set the world on fire, but it was a start. After my experiences with the pixel format conversions I began to experiment with the engine using floating point colours to a) preserve the precision when blending, and b) generalise the conversion algorithms i.e. float(value / source_maximum) * new_maximum works irrespective of the ranges of the two maximum values. As you would expect this was horribly slow, and despite some optimisation I decided to revert back to the fixed integer versions.
Oh yes, as for the name, I discovered in my research the CDX library, and thought is was a good name, short and descriptive (cDirectX = CDX), and I wanted something similar. Going by the naming scheme utilised by Microsoft for DirectX (where X is placeholder for the actual component) I settled on Direct2X. Again, not original by any means, but it abbreviated nicely to D2X, which will do if trademark issues should arise.
My next avenue of experimentation was with plugins, my initial experiments being the graphics subsystem for the D2X engine. The plan was to have a software renderer for reference and then produce both DirectDraw/3D and OpengL plugins to hardware accelerate things. Still reeling from the strange bottlencks I was experiencing with the main engine, I was also hit by the disgustingly slow performance of OpenGL's glDrawPixels(), and having little desire at the time to learn 3D programming unaided decided to to try something else.
ChronOS
As a side project from my main engine experiments I decided to learn some low-level skills such as basic x86 assembly by writing a primitive operatng system. Whilst I could have jumped right in using an existing bootloader such as grub or lilo and bugun directly on a kernel, I decided that somewhat defeated the educational purpose of the exercise, and set about developing a bootloader that was able to fit in a single 512 byte floppy disk sector. This was very eye-opening both in terms of actual assembly as well as in experience of working with a low-level (and in a debugger-less) environment. The bootloader when finished was able to load an arbitrary-sized binary image into memory, and was very robust as it could also handle the image being 100% fragmented on the disk. Admittedly it did use the BIOS routines for controlling the floppy disk motor, but I was quite proud regardless.
When I begun work on the actual kernel I cobbled together both a skeletal 32-bit protected mode glorified string-printer, as well as a simple 16-bit real mode typewriter program (which my niece loved to play with and I knew she couldn't break anything :) ). My plan was to get a win32 version of gcc cross-compiling to produce elf executables, but alas building my own toolchain was beyond me at that stage, and I was forced to abandon the line of experimentation until such time as I had a functional POSIX development environment and some free time.
LanWak
When I purchased my major PC hardware upgrades in early 2000, I came into the posession of multiple network cards featuring wake-on-lan abilities (which were reasonably expensive and/or uncommon back then), the only freeware utility I could find for utilising this feature was a horribly bloated AMD utility which required multiple dialog boxes just to wake up one machine. I did some investigation and found the specifications for AMD's "Magic Packets", and built a simple program which takes a MAC address as an argument and sends a magic packet targeted to it. I planned to extend the program to read in the list of MAC addresses from a file, but I never got around to it. Small, simple, effective. Wish more of my stuff was :).
University-era projects
Console Critters
In the second semester of my university course we were given our first C++ assignment, which was to make a Windows-console-based fruit machine. We were given the option of using other output APIs like DirectX or OpenGL, but no extra credit was availible (probably to dissuade people from gettign out of their depth). Whilst I was capable of something a bit prettier I decided to treat the textmode restriction as a obstacle to work around, and to this end I developed a set of double-buffered output classes and a scriptable OOP GUI library. These enabled me to have animated reels, interactive GUI buttons and I also added simple Win32 sound effects (DirectSound would've been far too much overhead for what was needed).
Asteroids
In the third semester we we given an assignment to produce a navigatable 3D environment containing some simple asteroids, implemented using OpenGL. As before, I put my experience to good use and took the oppertunity to experiment with wrapping the Win32 message loop in classes, ultimately handing in this final version. Other points of note, rather than converting 3D Studio MAX models into vertice lists and compiling them in as recommended, I wote a primitive ASE loader. I say loader and not parser, as, well, its a very hacked-together job that only understands the first model, the first material etc. as always thoguh, it works, so its all good.
The BatEngine
After my experiences with OpenGL I decided to have another bash at this library idea. One of my friends (Mat), was showing great ability with OpenGL, and we decided to work together on a bomberman clone called "JonnyMan" (it's a long story). I was to design the engine, he was going to design the graphics, and we were to go from there. My usual timescales kicked in and the core engine took me 2 weeks to finish the way I wanted (and enough for him to begin his bit), by which point he had lost a fair amount of interest and the fourth semester of university had begun.
SSPITL07
My university decided to try something new in my fourth semester, they merged two modules (System Specification and Programming In The Large, hence SSPITL) into one huge double unit. They then organised an intensive lecture program as well as weekly tasks with corresponding progress meetings. Each week we were to work in pairs following extreme programmign principles to develop a simple text editor, STED (similar to a *very* stripped down "VI" or "Edlin").
Unfortunatly the majority of the memebers of my 18-strong team were unable to code competently, and some couldn't even code at all, which beggars the question of how they passed the fruit machine assignment... Still, these were my comrades in this project, and their success or failure would also be my success or failure, so I figured I'd best make it a success. To this end I helped to support the weaker members, collaberated in organising additional mid-week meetings to ensure everyone would meet their targets, helped make up the shortfall if someone was struggling, and in general made sure no-one felt useless. We we one of the most successful groups, and I recieved a special commendation for my efforts, here is our final program.
JonnyMan
Now that the workload of SSPITL was behind us, I again approached Mat again to see if he wanted to develop JonnyMan as a group third year project, he declined this on the very reasonable grounds that we were all unsure of the university's requirements for group final year projects. I decided to pursue the project regardless, abet in a scaled back 2D form. However, once again the workload of the fifth semester destroyed any notions I had of working on the project before February.
The server for 'Draughts of Desire'
Our primary coding project for this semester was a group project of a game server and clients, each being developed by separate team members. I chose the server as it was the most independent component, and went a bit overboard and developed both cross-platform (Linux and Win32) iostream classes for sockets and cross-platform (Linux and Win32) multi-threading wrappers. I also experimented with OOP state machines where the state is the instance of the object, all of which were needless given the requirements, but enlightening nevertheless. The game server is availible here and features:
- a non-persistent user database which tracks scores
- registration
- authentication
- an unlimited chat lobby
- and of course multiple concurrent games of English draughts :)
Mat was the only one of my team members to complete his client (availible here, and although it is unable to participate in a game of draughts, it is fully able to register new users, login, and chat in the lobby.
JonnyMan - Part 2
It was now my final semester and I had both JonnyMan (now titled "Chaos Arena" for my supervisor) as well as my simulation project to complete. I then had a brainwave, if I was to take my existing batengine groundwork that I had produced, I could use the engine for both projects as it would be all my own work. Mat could now develop his 3D graphics module for our simulation project whilst I developed my own 2D DirectDraw graphics module for JonnyMan. To ensure the academic safety of this line of action I developed all of the engine code aside from the 3D graphics module, none of which was used in my JonnyMan submission.
To assist with the teamworking aspect of the project I instigated CVS version control of the project, and the benefits this provided were almost instantaneous, and our productivity went through the roof. The pressures I was under led me to compromise several implementation decisions in the engine however, awful error handling and lack of support for alternate formats were among the worst offenders. Not every decision was a comprimise though, in my 2D graphics component I was able to experiment with design patterns and implemented variations of both the bridge and factory patterns for the "graphical elements" I used as my 2D rendering primitives.
Pucking Hell
The simulation assignment we were assigned was an air hockey simulation with an AI opponent, as stated previously I was in charge of developing the engine, Mat would develop the 3D graphics module, and another would develop the physics and game assets. Suffice to say things didn't turn out as planned and I needed functional game logic in order to work on the AI component of the game; once again I assumed the burden of developing additional components to ensure the project met the deadline.
We decided to add some differentiating factors into the project to help it stand out during the demonstration, these included:
- the use of the analogue stick on USB-connected N64 controllers for puck control
- the ability to pause the game
- textual feedback from the AI opponent
- a textual debug console/log
- a proper ASE loading/parsing courtesy of my graphics team member
The physics I hacked together implement basic radial collision detection (all game objects are circular in the Y plane), simple reflection, friction, and impulse from collisions. The collision detection as you would expect is fairly idiot-proof, but the collision response leaves quite a lot to be desired as it does not perform any integration so with a high enough time delta or velocity collisions are missed. Another severe problem linked to this is when objects become stuck within one another the objects sometimes either pass though each other or get stuck inside one another, this is because the collision is only picked up when the objects intersect, and when the result of the reflection still intersects the "gneeeeeer" (the noise the multiple repeated collisions make) problem becomes apparent. Mat and our other team member manged to produce some very interesting physics dynamics in a test case, but we were unable to extend this (99% accurate) simulation of multiple bodies.
