Something like a long, detailed resume.
thus my current occupation as student at RUTGERS. Currently in my fourth year, though the first year and a half were somewhat misdirected (Electrical and Computer Engineering turned out to be not for me) so I lost a bit of time there.
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 just yet but a keystone 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.
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 used some fairly advanced techniques (such as my pioneering use of 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.
Someone who goes by the name of 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...
Worked on this all throughout high school, it is very playable, one of the largest hobbyist N64 projects ever. This was also the first (that I know of) 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 support (and only, to my knowledge). Not as efficient or compatible as it could be, but great for playing a wide variety of games from the best console ever. It included support for a few of the basic memory mappers, very good 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.
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. I don't even 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 an 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...
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 is on the official Super Fighter site.
A fairly lame little scroller I put together for the end of 2001.
I'm nominally working on audio for gekko.
Destop once wrote a Winamp plugin to play files of a specific format called DSP. This was used on a lot of audio files in Metroid Prime, for the 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:
There is currently an xmms port by Todd Jeffreys, bits of it were incorporated into foo_adpcm by kode54, and it is also used in xbmc for Xbox 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.
The "next-generation" in_cube, vgmstream is to be a portable library for decoding various types of streamed audio. It is currently in construction, though the code is stable and developed publicly. It has support for few formats now, but some of them seen nowhere else. I'm focusing work in vgmstream rather than in_cube now, as it is designed more carefully and much easier to work with.
Currently there is a command line decoder and Winamp plugin available for any who want to try it out, I release builds occasionally though there haven't been any proper releases yet.
Extracts a bunch of audio from Max Payne, for the PS2. Only the program to unpack the individual VAGs from the archive is mine.
To actually make any use of a USF rip you need a player, at 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.
USF is a format that I developed, based on Neill Corlett's PSF, which 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, from me and other rippers, since then. They're pretty much useless without 64th Note.
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.
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 it is a sort of interesting game with a neat new way of looking at Pong. In development it was called Vorlag, because I think that's a really cool name.
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 Halley's Comet Software. 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.