OSS::Overview("Contributions")
OSS::Project("Adonthell")
Back in my pre-Loki days, I was an embedded systems engineer. Instead of spending my time writing code, however, I wasted away my days filling out paperwork about how the code was supposed to be written. Software engineering at its finest. Put simply, it sucked. I wanted to play with bigger projects so that I could improve my coding skills and learn a few tricks. At the point where I joined Adonthell, my skills need the help.
Adonthell is your classic example of a tile-based RPG engine. For anyone who has played tile-based RPG titles in the past (Final Fantasy 1, the Ultima series, and whatnot), you'll feel right at home with the basic mechanics of Adonthell. There are a lot of features in the engine, such as Python-based behavior scripting for NPCs, multiple layers to the map display, and a window system for dialogs. All in all, it looks like a very promising project.
My contributions weren't too spectacular, but I had a lot of fun doing them. Other than writing the audio system for Adonthell (sound effect playback and playing background music), I just did little bits with the cutscene and graphics engines, as well as writing some documentation. I was really happy about sticking sound support in the game, since the project contains a lot of high-quality original music.
You can see more information on Adonthell here:
OSS::Project("BUILD Engine")
What did Duke Nukem 3D, Shadow Warrior, Redneck Rampage, and a host of other first-person-shooter games from the mid-90s have in common? They all used the BUILD engine as their core. When customized with behavioral scripting routines that were specific to each particular game, the BUILD engine provided a tremendous amount of performance and flexibility to game developers.
The success of the engine comes largely from it's optimized assembly-based software renderer. It was incredibly fast at low screen resolutions and was only limited by video card fill rates at higher resolutions. In addition, a level-editing tool was derived from the BUILD engine code base, allowing game developers to avoid the hassle of developing additional tools.
When it was announced that Ken Silverman was going to release the source code to the BUILD Engine, I thought Ryan Gordon was going to explode. He began tearing into the codebase in an effort to port the BUILD Engine to Linux. Since I was sharing an office with him at the time, I offered to help Ryan with the port here and there. After sifting through a lot of assembly code that was optimized for 16-bit DOS segmented memory mode, I gained a renewed sense of appreciation for the world of 32-bit flat memory addressing. The world of NEAR and FAR memory pointers is not a fun one.
After a few weeks of tearing through the asm and implementing some graphics primitives (mostly algorithms pulled directly from Michael Abrash's Graphics Programming Blackbook), I stopped working on the port. It has since been completed by Ryan and many other volunteers.
You can see more information on the BUILD Engine here:
- The port's main web site
- Official BUILD Engine source code page
- The Linux port of Duke Nukem 3D that uses the ported engine
OSS:Project("FreeCNC")
Westwood Studios and I have a long-standing love/hate relationship going on. I own a ton and a half of their software, and I've always had my eye on working there. On the other hand, their HR department feels that taking two months to look at your resume is acceptable business practice. Throw in that time that Sam Lantinga and I talked our way past two locked doors to get inside Westwood to hand-deliver our resumes, and then got escorted back out of the building after the head of HR gave us hell, and you can see where the mixed feelings come from.
Still, however you slice it, Westwood makes good games. The Command and Conquer series of games have become Westwood's major gaming franchise. I would have put my money on their Dune series being the big money maker, but C&C wins out. The combination of real-time tactics and the joy of squishing small, ant-like troops with large tanks is a winning concept.
The FreeCNC project is an attempt to reverse-engineer the original C&C engine for Unix-based platforms. Like most cross-platform games, the new engine uses SDL as a wrapper to the OS-native libraries. Since a variety of documentation is available on the various file formats and compression schemes of C&C, it's actually pretty feasible to try building an open version of the engine.
When I first heard about the FreeCNC engine's development, I downloaded a copy of the project's source code and started tinkering with it. I tightened up the movie playback code a bit and added a decode-and-playback mechanism for the game's ADPCM background music. I doubt any of my code exists in it's original form in the current FreeCNC codebase, since the maintainers have rewritten those two subsystems a few times since I submitted those patches to the project. These days, I just silently cheer for the project whenever I see word of a new update having been released.
You can see more information on FreeCNC here:
OSS::Project("ZSNES")
I've always been interested in software-based hardware emulators. Now that desktop PCs are powerful enough to emulate low-end hardware at full speed, the possibilities of emulation are expanding. Plus, you learn a ton when you have to implement an entire set of opcodes in software. You can start to get a good appreciation for what all those computer engineers do for a living.
ZSNES is a GUI and emulator core that provides excellent emulation of the 65c816 CPU and SPC700 sound chipset found within the Super Nintendo video game console. Using ZSNES, you can play SNES games right on your desktop. In fact, the adventurous people in the crowd can even use a real SNES gamepad to play the emulated software.
When it was announced that ZSNES was going to become open source software, I contacted the authors of the software to discuss some details of the codebase. They explained to me that the majority of the code was x86 assembly and that the asm assumed that a linear frame buffer was going to be the target of the rendering output. So, we discussed a few different ways of leveraging the DOS and Win32 ZSNES ports for the Linux porting effort.
I did the initial pass through the ZSNES codebase and ported the DirectX portions of the Win32 port to Linux by using the SDL library. Once that was done, I stepped back and watched a few other volunteers complete the porting process. I haven't touched it since then other than to help troubleshoot some input problems.
You can see more information on ZSNES here:
- ZSNES's main web site (I am the "Prometheus" fellow listed under the Contributors section)
- ZSNES at the Linux Game Tome