Following is a chronological history of some of my more exciting computer science exploits, along with commentary, screenshots, full source, and downloads (when available).

Please note that my QBASIC software is still at home on disks and will be screenshotted and compiled later. Further, many of my software libraries depend on direct access to certain devices such as a video card and sound card. Windows XP restricts direct access, meaning again that (a) my software only runs on pre-XP computers :-(, and (b) I can't get a screenshot until I return home.

At this point in time, all software distributed below is open source, and you can do with it as you wish. Honestly though, most of this stuff is outdated and not suitable for use in modern programs. I hope that if any of this is used, it is used as a learning tool for how computers actually work, a very different step from the direction computer programming is headed in today's world.

I started my computer programming hobby in fifth grade, learning Microsoft® QBASIC on my family's first computer, a 486/33 SX (that's 33 MHz!). In elementary school, we used Apple IIes (for which my favorite game was Lode Runner) and Macintoshes. In sixth grade, I started a weekly publication titled CompuNews [Sample Issues] that contained developments in computing as well as QBASIC tips. So, inspired by such classics as GORRILA.BAS and NIBBLES.BAS, I jumped into the fray, my biggest accomplishments being MageWars and my own GUI subsystem:

Synopsis: A game set in the old world of knights and wizards, it's a dual to the death as two mages wield their magical powers against each other to win fame and fortune.

Why it's cool: Mode 13h 320x200x8 (palletized color), bitmap loading and animation routines, assembly routines linked to the object file for mouse input and Sound Blaster® sound effects, two players.

Synopsis: A fully complemented GUI subsystem that emulated Winodws®-ish applications. Controllable by the mouse or keyboard and having a "retro" feel, menus and dialogs could be handled with ease.

Why it's cool: Mode 13h 320x200x8 (palletized color), assembly routines for mouse input, keyboard and mouse input for selection purposes, emulation of real windows and menus, nearly maxxed out the QBASIC code limit ;-)

A while later I took a QBASIC course for K-12 students at a local Ivy Tech, but by then I was far too advanced for an introductory course. I was very honored when the teacher presented me with a copy of his latest CS book at the end of the class.

Well, QBASIC was fun, but it was time to move up in the world (after all, I was in middle school by then), so I expanded my horizons. My dad got the full Microsoft Visual Studio v1.0 from work for our 486, and so I set off learning the obvious extension of my QBASIC knowledge: Visual Basic. Although Visual Basic made Windows apps with ease, it wasn't regarded terribly well in the programming world due to its slow speed and unsuitability for real-time applications (which was my area of interest). Nevertheless, my biggest VB accomplishment was for a Spanish class, a classic game featuring Cortez's conquest of South America:

Synopsis: It's sort of like the modern game Oasis, but you control the Incans in South America and don't really explore. The population grows throughout the years, then with historic detail, Cortez brings his armies down the coast, and you must reallocate your troops at each city to meet his forces and rewrite history.

Why it's cool: An entire (turn-based) game in Visual Basic! Used bitmaps, simple animations, somewhat of a "mathematical" game, historically accurate.

It was about this time that my web design career started as well. In middle school, I became one of a team of three students in charge of developing a new website for the school. Although it wasn't really professional-quality work, it sufficed, and it introduced me to the "wonders" of Netscape Composer ;-) But more on websites later.

So I had enough of Visual Basic and decided to move on to C. This was what the professionals used back then to develop virtually every game (although for DOS), so I again followed suit, getting quite a library of books in the process and reading through them all cover-to-cover, several times each, and implementing every word of them. I also started getting into assembly programming at this time with DOS's familiar debug.exe and using NASM. I also used DJGPP (a Windows port of GCC) for quite a bit of early C programming before I got into using Microsoft Visual Studio. Here's a pretty neat example of I wrote in DJGPP:

Synopsis: This is a really short program, but it has an amazing effect -- it generates SIRDS (Single Image Random Dot Stereograms) from 4-bit color images, using the palette for different depths. Further, I extended the algorithm so that instead of generating random dots, you can input another image to have the background be a set of repeating cars for instance.

Why it's cool: Well, it generates Magic Eye® images! Not only that, it compiles under DJGPP and uses the Allegro graphics library (now THAT brings back memories!). The algorithm was from the text PC Graphics Unleashed, and it is surprisingly simple. Maybe I'll explain it here sometime. In the meantime, just check out the source.

Remember how I said I was getting into assembly? Well, I was also getting into high school, and my freshman year two other friends (names removed to protect the innocent) and I started what we believe is the first-ever official high school club that develops computer games, the Computer Game Creation Team (CGCT for short). So that year we created a monumental game that was pretty landmark-ish in my own programming career (probably because, unfortunately, I wound up doing all of the programming). This time it was using Microsoft Visual Studio v1.0, and better yet, I wrote all of the graphics routines 100% in in-line assembly for Mode 13h (320x200x8). Nevertheless, the graphics are still stunning, even by today's standards *cough*:

Synopsis: We used to joke that this game would run on anything, and indeed it does, even today! Control a ship and make it through field after field of asteroids, visiting planets and upgrading your weapons. Pretty entertaining, if I do say so myself ;-)

Why it's cool: Wow, lots of reasons here. My longest program at the time of its writing, In C and graphics in 100% inline assembly. Manually loaded PCX files, had a global 8-bit palette, had the experience of managing a large production team, PC speaker sound effects, mouse assembly routines, high scores, developed my own custom data packing system to pack all assets into one data file. Note that the digits for the points received that float up are actually copied directly from ROM, and they are distorted on modern computers because they changed the character set stored in ROM so that my 1/2 pixel scaling routine doesn't work as well. Also, egad! Windows changed around their color palette system, so unfortunately the black color isn't the same as it used to be, leaving an ugly white mask around every "transparent" object. (So yeah, you got me. I "cheated" ... but I only did it because the assembly code was much easier if I just directly drew the black colors rather than skipping transparent pixels.)

Continuing with that assembly theme, I decided that it was time to increase my skills to the max and go ahead and code an entire performance-critical library in assembly. I even had notions of making this the graphics core for an über-élite OS that I started on, made the bootstrap loader and kernel loader, but I never got past the graphics, simply because they were what interested me most. So without further ado, my VESA VBE implementation:

Synopsis: A complete programming graphics library that'll do everything you'd ever want, mostly in hand-optimized Intel 386 assembly according to the Video Electronics Standards Association (VESA) Video BIOS Extensions (VBE), which are incidentally still on modern BIOSes (you just can't access them due to WinXP). This implementation was somehow derived straight from the many VESA VBE manuals that VESA produced. Before video cards had enough memory to implement linear framebuffers, they used page buffers where you had to (inconveniently) switch between different video memory pages every 64000 bytes, which could rudely be in the middle of a scan line (note in VGA cards, for example, bit planes even existed which specified one plane per primary color!). We'll just say my library supports this "banked" option because the linear framebuffer implementation is "too easy". Also, interestingly enough, to get around the fact that processors now operated in "protected mode" to get at > 640k of RAM (and thus the BIOS interrupts couldn't be called like in real mode), I had to physically copy the ROM into memory, find the offset of the VESA VBE, then execute that code manually. Interesting way to do it.

Why it's cool: See above rant.

Synopsis: So anyhow, let's just say I wasn't really interested in developing the OS anymore, so my plans for turning this into the video core of an OS were shot. So instead, I developed it all into a presentation system, similar to MS PowerPoint (minus the WYSIWYG). I developed two entire presentations for it, presenting these at school (one on viruses and the other on psychologist Jung), making the "slides" in Paint Shop Pro. It has neat transitions, animation effects, could run external programs, all in all I was pretty impressed. Oh yeah, and just to dispel my disgust for cancelling my OS project, I prefixed each presentation with a DanOS Loading... screen, when in actuality virtually no loading wait was required.

Why it's cool: I actually did something with the graphics library I wrote.

Rolling with the punches, I purchased Microsoft Visual C++ 6.0 Learning Edition when we got a new computer (a 500 MHz from Gateway). I also preceded to learn DirectX 6.0 and do quite a lot with it. I'm going to condense this down to some program descriptions, but let's just suffice it to say I did a lot with DirectX over the course of a few years, my most notable achievement being authoring a complete DirectX wrapper library (emphasis on 2D graphics) for education (used in a high school C++ class and many of my own game projects). I also published an article on GameDev.net, a prominent game development website, on how I implemented my image panning class (Here). Needless to say, I really should have written it in a more interesting manner:

Synopsis: This is quite possibly the largest library I've written to date. It encapsulates ALL of DirectX 6.0 (minus networking and most 3D stuff) into one easy-to-use library. I'll just let you discover everything else.

Why it's cool: Largest library to date, it works, used in an Intro to C++ class. The image to the left is a CGCT demo I made that demonstrates my panning and animation classes. One of my first big projects with C++, so unfortunately it doesn't use C++ quite as well as it could. XMedia was a terrible choice of name, however, simply because DirectX had a relatively new DirectMedia component, and it would be very easy to get my library confused with theirs.

Synopsis: Written for AP History, this is a trivia game where two players face off about their Civil War history knowledge. Uses the above XMedia library.

Why it's cool: To its credit, it might actually have about a hundred questions! This is a pretty good example of XMedia's capabilities too. The font is amazingly bitmapped, but I admittedly used another guy's routine for that because the project emphasis was more on getting the questions done.

Synopsis: Short for "Parashooting Aliens", this game was the second produced by the CGCT, and it's a hellofa lot of fun. Seriously. Well, just resist the urge to shoot the motherships right off the bat, because then it isn't much fun at all. Hordes of aliens parashoot down to take over your prized pig ... try shooting only the alien, then only their parashoot. Oooh, and try the number keys 1-? for some awesome weapons and sound effects. And for some reason right-click stops the game, so don't click it!

Why it's cool: Again, it uses my XMedia programming library. But more than that, it uses a really cool system I devised for loading in batches of images at once. This game actually has a noticable delay due to loading in assets! Also, I'm using some data structures here -- linked lists to keep track of all of the aliens. Highly recommended game. It also has a menu system and all in the code but not the executable, so it's your task to get that running if you're up for a challenge.

Although it may appear that way, I didn't only program games, and I didn't only program PCs. There were also calculators to program thenadays, so for example I tinkered around with TI-BASIC for the TI-85, making things like a graphical game of Simon (TI-SIMON) and even a very slow 3-D polygonal engine with hidden surface removal (unfortunately, I didn't feel like laboriously copying the source to the computer and lost it since). However, I did tend to remain true to the PC platform. My first major MFC app was a landmark, used so that writers in my publications course (Public Information Relations Bureau) could port their articles to HTML (Source/Executable). I also competed in the hardest division for several United States American Computing Olympiad (USACO) contests (used to determine the national team for international programming competitions) and typically ranked about 40-50th from US competitors. Here's my best example of a scientific program:

Synopsis: A program I wrote for high school physics that computes the frequency spectrum the long way (Discrete Fourier Transform) from a given sound wave.

Why it's cool: Uses 100% Windows SDK, but it's a big pain to implement some elements like scroll bars. MFC's a better choice for something like this. This is a pretty cool science app too because it's one way for me to tune something like a guitar.

OK, so by now you're probably wondering whether I ever made the "jump" to 3D graphics after doing all of this 2D work, and yes, I did ;-) After starting out with some basic 3D DirectX apps that simply initialized and enumerated (but did this quite well), I actually hit on an Internet collaboration project that I did most of the work for unfortunately where we just did a really neat initialization demo (Source/Executable). You see, at about this point, my family decided to hop on the Internet bandwagon with a stunning 28.8k dial-up connection. (Yes, they did have 56.6k out then, it's just that we're kind of out there and our phone lines are only capable of 28.8k.)

So after trolling the Internet for a while and getting the scoop on a lot of virtual game dev projects going on, I finally decided to join one. I actually got into several before I joined this one, kind of scoping around to see what the difference was between a team with a good chance of success and one that would flounder immediately. Luckily, it was then that I found Wildfire Games's 0 A.D.. Led by perhaps the most capable project manager I've ever seen and with a mod title and impressive array of artists behind him, that game seemed to have a high probability of success (and still does!). I joined on when the programming division was just getting started. Unfortunately, after a while their lead programmer left, and so about a year before college started, I took the reigns and became the lead programmer of this massive project for two summers in a row (taking time off during the school year). In fact, I'm still with this team, but I just don't have nearly enough time to take another managerial role. (Being very professional, the team is also very time-consuming.)

The game has an ~500-page design document, a professional trailer, was mentioned in PC Gamer UK and lots of popular gaming websites, it has *excellent* graphics, an excellent programming staff, and under my reign we tried our best to make the technical side a reality. I hosted weekly programming meetings, started up a tasking system for assigning tasks, led graphics research, drafted minor design doc sections, communicated daily with the programming staff, helped to design the engine and overall architecture, a lot more managerial stuff, plus I wrote a prototype engine with 3D terrain and 2D units/buildings:

Synopsis: The first official DirectX prototype engine for the 0 A.D. project. It allows generation of terrain from a heightmap, appropriate lighting, plus it experimented with placing 2D images onto the 3D terrain using some graphics techniques we developed.

Why it's cool: It's all in Direct3D, and I wrote the whole thing :-) It's an actual working 3D terrain engine that has experimental realistic 2D images placed on. Plus, it has a really neat loading popup dialog like all of the latest games do. This screenshot was one of the first published by the 0 A.D team in magazines and websites. Unfortunately, I can't give away the source because I donated it to the 0 A.D. team. If they decide to go open source, I'll release this open source as well.

Late high school, I also started up my own website development business (watch out for that self-employment tax if you ever start one, a whopping 28% :-P), and I made websites and software for local companies, primarily using HTML, SSI, CSS, and Perl. A few of my best Perl scripts are still in use at the old CNHS news website. Most of my old websites were made so long ago, they've been replaced by now. Maybe I'll post some screenshots later on.

I was also an independent contractor for a local photography company, and I was hired to attempt something that to our knowledge hasn't been done before. We brought almost real-time digital photography to our local fair. In other words, the photographer would snap gigabytes of pictures for each event, and his philosophy was that everyone has kids and they'll want at least one of all the pictures he took. So instead of filtering through his picture listings and choosing the best, we offered hundreds of pictures of each event, right after the event occurred. I set up a computer system that enabled digital image processing of all of his pictures immediately once they were taken, then those pictures were scaled and cropped, then sent to three or four viewing computers where a user could sit down and view all of the proofs at the fair (and then hopefully order). The pictures were then uploaded to the photography site that night, and customers could also order on-line. This system was such a success, I heard that the photographer was invited to be the official photographer of the state fair as well.

At Purdue, I have of course written quite a bit of software for classes, but I've also continued to write software for myself as well. For Purdue's RoboCup team for instance, a friend and I wrote a good-sized image processing/recognition library. Most of my out-of-class code has been for Purdue's Haptic Interface Research Laboratory, where I am currently employed as an undergraduate research assistant. While I can't post the source code to any of my projects, I'll post some pictures to a few of my programs that have been publicly demonstrated (not that they would compile or even work on your computer without some really expensive force feedback devices). These use the PHANToM haptic device and the Delta Haptic Device, both which can for instance render an invisible 3D mesh in midair and you can actually feel it there with a probe. I was also paid last summer to basically just sit down and read through a few OpenGL books, so that enhanced my knowledge of 3D even more, which I used in a few lab projects. I also worked on a few other software projects in the lab, but the following are some of the most interesting to me:

Synopsis: Written for the PHANToM force feedback device, this demo attempts to simulate as realistically as possible one of those wooden boxes with a maze and a marble inside, except you can't see the insides. The real physical game only lets you know data through tactile and audial clues, and the same goes for this version. My goal was to make it so you could get the marble out 100% without visual cues, and I think I got it pretty close. It feels really good for a haptic demo in my opinion.

Why it's cool: It uses a really fancy 3-DOF haptic device to render lots of mathematically generated forces to your hands, simulating a marble rolling around. It works quite well, and it uses OpenGL to render the box you manipulate and the graphical depiction of the maze. Yes, the texture is stolen from NeHe's tutorial, but that's only because I just wanted a quick texture -- I promise ;-) I kind of just wrote this for fun over the summer to see what I could do.

Synopsis: This is my latest demo, written for the 6-DOF Delta Haptic Device. Using actual mathematical models derived by Physics and ME professors, we're attempting to simulate using a haptic device the contact dynamics of a multi-walled carbon nanotube "glued" onto the tip of an atomic force microscope. So essentially it's like the user of the Delta is directly controlling the tip, bringing the inconspicous forces that are present in the nanoscale (e.g. capillary forces from hydrogen bonding, orbital interactions, etc.) to the macroscale. This would be useful in sort of visualizing mathematical models to choose good nanotube properties.

Why it's cool: Now we're using a 6-DOF haptic device that even sends torque data to your hand. This project could even lead to full-scale simulation of an atomic force microscope! The graphics are pretty neat, 100% mathematically derived from scatch (i.e. the rotations, bézier curves, etc.). The nanotube is modelled as a bézier curve in fact so that it exactly prescribes to the frame pictures mentioned in a paper I read.

Woah! Well, as I finish more milestones in my programming career, I'll post them here. Just don't expect something often, or you'll be disappointed. (I'm only putting up the big projects :-))