• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Emulator Discussion and Support › General Discussion v
« Previous 1 ... 11 12 13 14 15 ... 367 Next »

Disney Trio of Destruction™
View New Posts | View Today's Posts

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
Disney Trio of Destruction™
07-26-2021, 03:21 AM
#1
AntiRes Offline
Junior Member
**
Posts: 1
Threads: 1
Joined: Jul 2021
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.
Find
Reply
07-26-2021, 05:49 AM
#2
JMC47 Offline
Content Producer
*******
Content Creators (Moderators)
Posts: 6,542
Threads: 29
Joined: Feb 2013
Toy Story 3 makes sense based on what I've seen of how the game behaves.

Disney Infinity and Disney's Cars 2 behave the same there, and if they were built off the same memory manager, then their usage of MEM2 makes sense. Whether it be paranoia, or a rogue developer, or simply the imagination of developers, the Disney Trio of Destruction, as we've lovingly dubbed, are a part of the lore of Dolphin. And whether or not it was malicious, the way these behaviors work present an interesting challenge and give such a personality to the games.

But that doesn't explain the crazy "suicide pill" like behavior with the dcache and other avalanche software games before this with crude messages and other shots at game hackers and reverse engineers. Unless there is some crazy explanation for that, it still remains a mystery and our only guess has to be that it is anti-emulator code. But either way, I will remember this when writing about these games, and perhaps separate out Disney Infinity and Cars 2, since this explanation makes sense for Toy Story 3 and the non-dcache related parts of the aforementioned games.

Obviously, this is just a post on the internet and this could be a ruse, but based on all the research and investigation I've done on these games, everything you've said makes sense. It would also make sense that on some later projects that this memory behavior was either changed/fixed/replaced as their technology improved. Either way I greatly appreciate your insight on this and hope that maybe someday the games are more playable in Dolphin.
Find
Reply
« Next Oldest | Next Newest »


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma

Linear Mode
Threaded Mode