Here are descriptions of projects I've worked on over the past several years. I've listed year ranges to indicate when I was intent on that particular project, though I may have poked at it since then.
I've been doing some work a game lately.
Destop once wrote a Winamp plugin to play files of a specific format called DSP. This was used for a lot of audio in Metroid Prime for Gamecube. This sat around for a few years, and then I picked it up and made it more useful. Eventually it gained support for other formats used on Gamecube games, so the name was changed to in_cube.
Some things in_cube pioneered:
I have a database up to track what games are currently supported, as of this writing the number stands at 219.
There is currently an xmms port by Todd Jeffreys, bits of it were incorporated into foo_adpcm by kode54, and it was also used in xbmc for Xbox (and PC) and Micket's unofficial Oldplay for GP2X. It has also been spotted in Audacious, specifically in Audacious-Plugins-Ugly 1.3.0.
As noted, it was the first Winamp plugin to support ADX looping, and as a result it has become quite popular among those who use it for nothing but ADX, which has been used in a huge number of games. It's been picked up by some people who want looping audio in MUGEN, too.
in_cube began accreting Playstation 2 formats around version 0.20. By 0.36 it had gained Wii, DS, and Xbox formats, and the code was getting out of hand, so I created vgmstream as a fresh start. in_cube is now considered abandoned in favor of vgmstream.
The "next-generation" in_cube, vgmstream is a portable library for decoding various types of streamed audio. It is currently still considered to be in an experimental state; though the code is stable and binaries are available, there has not yet been an official release. It is developed publicly in subversion on SourceForge.net. Over 100 formats are supported, most playable nowhere else (besides the original game).
A few of the most interesting things vgmstream pioneered:
vgmstream builds with both gcc and MSVC (2008 project included), and there are Winamp, audacious, foobar2000, and command line frontends. It has been spotted in XBMC, Audio Overload (not yet in release), GameMusicGear_MX for PSP, and unofficially in VLC.
USF is a format that I developed, based on Neill Corlett's PSF. It provides a compact way of storing an N64 ROM and savestate, specifically for the purpose of playing music. I ripped the first USFs (from Super Mario 64) in 2004, and they've been coming along slowly since then. I haven't done any ripping myself in a long time, but almost from the beginning several others have been producing USFs (often better than mine).
They're pretty much useless without 64th Note.
To actually make any use of a USF rip you need a player, at the moment the only one which exists is the original one I developed, which is a Winamp plugin. The vast majority of the code is not mine, though I've improved and refined it significantly to better fit the environment. It is based on Project 64 and azimer's HLE audio (though the use of the latter is optional, and disabled by default). It is very usable, and crashes are all but unheard of these days. The emulation isn't 100% accurate, as a close comparison with actual hardware output will show, but it is fine for casual listening.
Through reverse engineering I've built up a collection of tools for manipulating various audio and container formats used in video games. Among the more interesting:
I nominally worked on audio for gekko. The most I ever actually did was some very high-level audio emulation that never made it into a release.
Worked on this all throughout high school, it is very playable, one of the largest hobbyist N64 projects ever. This was also (afaik) the first such project to involve custom RSP microcode. It has complete exception handling, lots of stuff linked to interrupts, uses the controller pack for saving, and could take screenshots. All done at the lowest level, no OS to speak of. At the time I wasn't even aware of stacks, though MIPS has enough registers that often that's not an issue. It also led to development of a method for loading whole programs via an N64 gameshark (see gsupload), which Neon64 was the first to make use of. Not as efficient or compatible as it could be, but sufficient for playing a wide variety of games. It included support for a few of the basic memory mappers, decent sound, two controllers, and three saves to the controller pack.
This was the first project I worked on that I got significant recognition for online. Haven't worked on it in a while, but it was a tremendous amount of fun. I still pull it out occasionally to play NES games. And yes, now I know better than to write a large project one line of assembly at a time.
There is a demo on YouTube from Hraesvlgr, I followed up with a really terrible one here.
When I began work on Neon64 there were two computers in my house, one was a 400 MHz Celeron running Windows 98, the other was a 100 MHz 486 running MS-DOS (6?). I don't remember what MIPS assembler I was using when I started out, but it wouldn't run under DOS. When I decided, in 2002, to scrap the current progress on Neon64 and start anew, I decided I'd like to do most of the development on the DOS machine. So I decided I'd write my own assembler, and did so over most of that summer. It has a somewhat screwy syntax, multiple passes, support for something like linking, and is very slow. From then on Neon64 was written for U64ASM.
It has some features which were useful to me at the time, I built in support for attaching a header and caclulating a checksum, so then it could be sent directly to the N64 (for which I also added V64jr sending support). Made the debug cycle a bit shorter (though the damned thing still took forever to assemble, my preprocessor was crap). I wrote it in C++, compiled with Borland, as that's what I was using in my computer class at school. I had lost the source for a while, but it's now up here. Really bad code. You'll notice that everything but the main file is called .H, shows how little I knew at the time...
I wanted Neon64 to be able to take screenshots, and initially I looked at some existing code for that... it wasn't very good. So I wrote my own, which can store the current screen, running at any resolution and color depth, to the RAM of a v64jr. There's a companion tool which then loads that image onto a PC and writes it as a BMP. After I developed this I used it exclusively for taking screenshots of Neon64 in action.
Having written U64ASM and done a lot of low-level N64 development, I decided to use it to help other people pick up N64 coding. I put together a simple demo, which nevertheless used some fairly advanced techniques (such as custom microcode), and was heavily commented. The best part was you could run it right out of the box and have a working N64 ROM.
ZoRAXE used it in a class as the basis of a sorting demo. GBAGuy used it as the basis of his N64 ASM tutorial. In a development community as small as that of the N64 two projects is a lot!
When working on Neon64 I developed a method of patching a small loader into Super Mario 64 via a Gameshark, to load whatever code I could pipe over a parallel port cable and fit in RAM. Since I was working on Neon64 at the time it was naturally the first thing I modified to run this way, and it was a very cool success. It meant that people were able to load Neon64 with mass-market equipment (I bought my GS for $40 at Wal*Mart, though I built my first straight-through parallel port cable), rather than hunting for a rare, expensive, and pseudo-legal backup device.
The early trouble with this method was that there are fairly few PC programs to communicate with the Gameshark, and only one was available that actually had the kind of flexibility I needed (GSCC, specifically), but it was a GUI-only Windows program, and as such there was an irritating series of steps, involving clicking and entering numbers, whenever one wanted to load some code, not to mention somewhat tempermental behavior. The GS was hard enough to get working reliably...
I decided that a command line method was needed. I sent some communications off to the authors of GSCC and another GS tool, but neither were of help. So at some point I broke out a debugger and figured out the protocol, wrote up a program to load Neon64 and an NES ROM from the command line, and all was well. I also wrote a Linux version to do the same thing. I made some improvements to the reliability of the protocol which the author of one tool I disassembled said he'd be incorporating back into his own program.
gsupload, as it stands, will detect the running version of Super Mario 64 (I have working patches for the US and PAL versions, nekokabu has added patches for both Japanese versions and Mario Party, and it also detects if Neon64 is already loaded to avoid wasting time with resending it), write the appropriate loader, wait for the user, then send the ROM. Since the code is freely available anyone else can pick this up and write a program for GS interfacing.
For a presentation I hacked together a quick modification to Neon64 that allows it to act as a loader, with gsupload, for N64 programs, not online yet but a nice part of the in the "fully legal development with off-the-shelf hardware" chain.
Zoinkity used the GS-interfacing bit for a F-Zero X track uploading program.
This was an N64 program I put together to advertise Super Fighter, an old PC game that was looking for some publicity. Got me to learn how to play sound, and do a few cool effects.
Here it was on the official Super Fighter site.
A fairly lame little scroller I put together for the end of 2001 (which nevertheless got the stage set for the Super Fighter demo).
This was my first NES game (in a very short series...). If you want to know more about it I have a whole page on the subject... suffice to say you play the ball in Pong, trying to get past a paddle. In development it was called Vorlag, because I think that's a really cool name.
This was supposed to be my next entry in the Minigame compo. It was a platformer, I had moving platforms and running and jumping implemented (similar physics to Super Mario Brothers, thus the name), as well as a few levels, but I lost interest and never finished it. I rediscovered the source recently, so here it is.
I have a large collection of DVDs which I archived using Cathy, but when I switched to Linux I found myself without a way to search these archives (I had trouble with using Cathy in wine, though I've since figured it out). This is a C program to dump the contents of a .caf file as text, suitable for grepping.
I put this together to form a community for my Halley's Comet Software web site, where video game audio emulation is discussed. The source is linked at the bottom of each page.
For one of my High School senior projects I worked with Utpal Sandesara on a cloud formation simulation program. We got a good grade on it and impressed people...
I don't have the code online anywhere, but I do have this video which we included in our presentation, which was generated by rendering the output of our program through POV-Ray. There was a much nicer one rotating a fully formed cloud, but I can't seem to locate it...
I once wrote a PHP script to display an indicator indicating a user's status on AIM. It showed a little banner saying if you were online, idle or away (and how long), or offline. It used AIM's TOC protocol to quickly log in and check your status. AIM would block an SN if it was used too frequently, so the program had a list of screen names it could use, which had been overused (and when they'd be available again), and thus could work nearly all the time. I don't have the source around anymore, unfortunately.
Michael Kazmierczak and I have been writing this story for years, but only in 2009 did we finally get around to publishing it online. We're currently posting about a chapter per week, and we're still actively writing new material.
This page was written with vim and complies with HTML 4.01 Strict.