In regard to...
I discovered and developed an affinity for the emulation community in 1998 when a friend told me about Nesticle. This same friend also gave me a copy of Michael Abrash's Graphics Programming Black Book for my birthday. In the book, Abrash discussed an optimization technique that intrigued me and I thought would be well suited for an emulator.
Since the Super NES was my favorite console, I began work on a 65816 emulator as a proof-of-concept. Soon I decided that was too complex for what I was trying to do, so I scaled back and switched to writing an SPC700 emulator. Once I was finished, I realized I had no way to know if the emulator was actually working. So I printed out the current instruction to show each step of execution, then I added register output. As I discovered bugs and inaccuracies, I needed to see more details of what was going on, and I eventually created a UI that displayed a full disassembly, memory view, and register editor.
The emulator appeared to be working—at least, the original idea I had was working—but I still didn't know if it was really emulating the hardware accurately. By this point, I had become more involved in this hobby project than I originally intended, and I decided to take it all the way and begin coding DSP emulation to produce sound. After a lot of trial and error, I created an emulator that could play most of the music from Super NES games. I sent a copy—which I was calling SPCTool—to one of the admins of Zophar's Domain. It was received far better than I had hoped for, and I was encouraged to turn it into a Winamp plug-in called SNESAmp.
Being an unemployed college student, I needed a job. When I saw a listing for a Gameboy programmer, I applied, and I was granted an interview. The interview didn't start out well, as I had no professional experience as a programmer. However, when I was asked what I knew about video game consoles, I mentioned that I wrote an SPC700 emulator, and that landed me the job.
Over the years, I worked for several video game studios. I've always been passionate about working directly with hardware, and I got to write a lot of low-level assembly code for the Gameboy, PlayStation 2, and PSP. In 2007, I was working as the lead on a port to the Wii when I was contacted by the tech director of Fall Line Studio—a newly created studio under the Walt Disney Company—and offered a position as an audio programmer. With audio being my second passion, I took the job.
In my previous role, I had written a general purpose memory manager to track our memory usage and handle the unique situation of having two sets of RAM in the Wii. My first few months at Disney didn't see much audio programming, because we didn't have an audio team or a final game design yet. Fall Line was using an in-house engine developed by sister studio Avalanche Software. Having just come off a Wii project, I started looking through the code to see how Fall Line was handling MEM2 allocations. Turns out they weren't. Everything was coming out of MEM1. So I wrote a new memory manager to help out.
Now, at my previous studio, we were very conservative about memory allocation. We pre-calculated as much as we could and tried to allocate memory in large chunks. We made about 100 memory allocations in total. The engine from Avalanche did no such thing. By the time the main menu was loaded, the game had already made over 18,000 allocations. I was shocked at the haphazard programming.
The title we were working would become fraught with memory fragmentation issues. If the player exited to the main menu, then tried to enter another level, the game would crash because there wouldn't be enough contiguous memory to allocate space for the textures. We ended up, basically, resetting the game between levels to restore free memory.
After shipping our first (and only) Wii title, I thought about the memory issues we had. I recalled a panel I went to one year at GDC where a programmer from Factor 5 talked about how they programmed the MMU in the Gamecube to create a virtual swap space in ARAM. I thought I could do a similar thing on the Wii, but instead of creating a swap space, I could use logical addresses to contiguously map fragmented physical addresses. (I had also always had a desire to write a logical memory manager ever since I had learned about protected mode on the 80386, and this was good excuse to scratch an item off my programming bucket list.)
In practice, it wasn't that simple. Any hardware external to the CPU could understand only real addresses. So graphics and audio data had to be stored in physical memory, but everything else—animation, collision, and all other game data—could be stored in logical space. I implemented a real-time defragmenter that would constantly push blocks allocated for logical addresses to the back of RAM freeing up lower addresses for physical allocations.
Around this time, Disney decided to shut down Fall Line. Some people were laid-off, but most of us were absorbed into Avalanche. The powers that be had little interest in adopting any tech that had been developed at Fall Line, but the code they had didn't effectively manage multiple heaps, and so I was given the go ahead to merge my memory manager into the existing code base.
In the end, it worked. I don't think either Toy Story 3 or Infinity could've shipped on the Wii without it. The open gameplay created a churn of allocations, and without a disciplined approach to asset management that other studios use, fragmentation was unavoidable.
tl;dr
As an emulator author and enthusiast, I never put code into a game with the intent to thwart emulators.
I discovered and developed an affinity for the emulation community in 1998 when a friend told me about Nesticle. This same friend also gave me a copy of Michael Abrash's Graphics Programming Black Book for my birthday. In the book, Abrash discussed an optimization technique that intrigued me and I thought would be well suited for an emulator.
Since the Super NES was my favorite console, I began work on a 65816 emulator as a proof-of-concept. Soon I decided that was too complex for what I was trying to do, so I scaled back and switched to writing an SPC700 emulator. Once I was finished, I realized I had no way to know if the emulator was actually working. So I printed out the current instruction to show each step of execution, then I added register output. As I discovered bugs and inaccuracies, I needed to see more details of what was going on, and I eventually created a UI that displayed a full disassembly, memory view, and register editor.
The emulator appeared to be working—at least, the original idea I had was working—but I still didn't know if it was really emulating the hardware accurately. By this point, I had become more involved in this hobby project than I originally intended, and I decided to take it all the way and begin coding DSP emulation to produce sound. After a lot of trial and error, I created an emulator that could play most of the music from Super NES games. I sent a copy—which I was calling SPCTool—to one of the admins of Zophar's Domain. It was received far better than I had hoped for, and I was encouraged to turn it into a Winamp plug-in called SNESAmp.
Being an unemployed college student, I needed a job. When I saw a listing for a Gameboy programmer, I applied, and I was granted an interview. The interview didn't start out well, as I had no professional experience as a programmer. However, when I was asked what I knew about video game consoles, I mentioned that I wrote an SPC700 emulator, and that landed me the job.
Over the years, I worked for several video game studios. I've always been passionate about working directly with hardware, and I got to write a lot of low-level assembly code for the Gameboy, PlayStation 2, and PSP. In 2007, I was working as the lead on a port to the Wii when I was contacted by the tech director of Fall Line Studio—a newly created studio under the Walt Disney Company—and offered a position as an audio programmer. With audio being my second passion, I took the job.
In my previous role, I had written a general purpose memory manager to track our memory usage and handle the unique situation of having two sets of RAM in the Wii. My first few months at Disney didn't see much audio programming, because we didn't have an audio team or a final game design yet. Fall Line was using an in-house engine developed by sister studio Avalanche Software. Having just come off a Wii project, I started looking through the code to see how Fall Line was handling MEM2 allocations. Turns out they weren't. Everything was coming out of MEM1. So I wrote a new memory manager to help out.
Now, at my previous studio, we were very conservative about memory allocation. We pre-calculated as much as we could and tried to allocate memory in large chunks. We made about 100 memory allocations in total. The engine from Avalanche did no such thing. By the time the main menu was loaded, the game had already made over 18,000 allocations. I was shocked at the haphazard programming.
The title we were working would become fraught with memory fragmentation issues. If the player exited to the main menu, then tried to enter another level, the game would crash because there wouldn't be enough contiguous memory to allocate space for the textures. We ended up, basically, resetting the game between levels to restore free memory.
After shipping our first (and only) Wii title, I thought about the memory issues we had. I recalled a panel I went to one year at GDC where a programmer from Factor 5 talked about how they programmed the MMU in the Gamecube to create a virtual swap space in ARAM. I thought I could do a similar thing on the Wii, but instead of creating a swap space, I could use logical addresses to contiguously map fragmented physical addresses. (I had also always had a desire to write a logical memory manager ever since I had learned about protected mode on the 80386, and this was good excuse to scratch an item off my programming bucket list.)
In practice, it wasn't that simple. Any hardware external to the CPU could understand only real addresses. So graphics and audio data had to be stored in physical memory, but everything else—animation, collision, and all other game data—could be stored in logical space. I implemented a real-time defragmenter that would constantly push blocks allocated for logical addresses to the back of RAM freeing up lower addresses for physical allocations.
Around this time, Disney decided to shut down Fall Line. Some people were laid-off, but most of us were absorbed into Avalanche. The powers that be had little interest in adopting any tech that had been developed at Fall Line, but the code they had didn't effectively manage multiple heaps, and so I was given the go ahead to merge my memory manager into the existing code base.
In the end, it worked. I don't think either Toy Story 3 or Infinity could've shipped on the Wii without it. The open gameplay created a churn of allocations, and without a disciplined approach to asset management that other studios use, fragmentation was unavoidable.
tl;dr
As an emulator author and enthusiast, I never put code into a game with the intent to thwart emulators.
