Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Dolphin Progress Report (dolphin-emu.org)
73 points by luu on Oct 2, 2015 | hide | past | favorite | 10 comments


I love these monthly progress reports. As a non game-programmer, there's not much of immediate use to me, but these writings give a great insight into the development of the project and sometimes they have really interesting and surprising anecdotes that are just fun to read.

Like the one about fixing the audio in Mega Man 3 after fixing the video timing.

If people from the Dolphin projects are reading HN: Thank you for your hard work and especially thank you for writing the monthly progress reports.


No Problem.


Jeez, I had no idea that emulators were this complicated. I thought all you had to do was emulate the target system, but I guess that approach requires a lot of processing power. This is a tremendous amount of work that these devs are doing.


The problems are:

- The hardware you are emulating is usually undocumented

- For recent systems, you must use a JIT for CPU emulation or it will be too slow

- For pretty much anything with 3D, you need to use GPU acceleration or it will be too slow (and the host and emulated GPUs might work very differently)

- Users want to run 3D games at arbitrary resolutions higher than the ones intended for the emulated targets, so you need to add trickery to handle that (like transparently resizing framebuffer-sized internal textures and so on)

- For recent systems, you may need to emulate a memory access with a single memory access, which means you need to setup the host virtual space to be the same as the emulated system, which requires lots of tricks to handle MMIO regions, memory mapped in multiple places, and finding a place to put the emulator code

- Sometimes you need to emulate one or more software APIs instead of the hardware, because emulating the hardware would be too hard or too slow or not allow to replace functionality (this is called "HLE" - high level emulation)

- You need to map keyboard+mouse and optional 360 controller to whatever input system the emulated target uses, as well as supporting plugging in the actual emulated controllers with some kind of adapter

- There may be a copyrighted BIOS or OS that you need to reimplement or support extracting from the machine


Additionally:

- Floating point issues. Sure both the host and guest implement IEEE 754 floating point math, but that only helps if the emulated cpu is in IEEE 754 compliant mode (which it never is, because it's 754 compliant mode is slower) and only uses instructions supplied by 754 (which they don't because plenty are missing, like FMA, SIN/COS, SQRT). PCSX2 gets this particularly bad, because the PS2's vector units don't even try to implement proper IEEE 754 math and they have about 5 different workarounds to try to make different games work. But even Dolphin runs into issues trying to emulate PowerPC's non-compliant mode. Denormals are now handled correctly, but we still have issues with NANs.

- Unified GPU/CPU memory. The gamecube only has one 24mb block of memory, with both textures and code in it, which is the complete opposite of what the host GPU wants. So we have a huge amount of texture cache code to yank textures out of the unified memory and convert/upload them to the GPU, then make sure we know when the texture has changed so we can re-upload it. Things get even more complex when the game starts coping things back to into the unified memory. In some games end up hash about 12gb of textures every second to make sure they haven't changed.

- Interrupts. So you have jitted your code, what happens when you need to fire an interrupt in the middle of a block?

- Timing. To simplify emulation, you might say that an operation (like loading from the DVD, or rendering a polygon) will complete instantly, which works for most games, until you find one which never expected the result to return that early and crashes or glitches. These issues can be a complete nightmare to debug, and even if you do work out which operation is too fast you have no idea how long that operation is actually meant to take without doing tests on the hardware.


Very interesting, thank you. It's a testament to all the work that's gone into this that emulators work at all, then.


Well, you can "just" emulate the hardware accurately. But that's incredibly slow for modern consoles. In practice you need hacks so things are performant.


Here's a great Ars writeup about what it takes to accurately emulate SNES: http://arstechnica.com/gaming/2011/08/accuracy-takes-power-o...


And IIRC bsnes/higan is "only" cycle-accurate emulation, there's one further step of circuit-accurate emulation: http://boingboing.net/2014/02/25/dice-emulator-for-hardwired...


Seems down... here's a snapshot https://archive.is/a4M8I




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: