
Dolphin Progress Report - luu
https://dolphin-emu.org/blog/2015/10/01/dolphin-progress-report-september-2015/
======
pilif
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.

~~~
phire
No Problem.

------
StavrosK
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.

~~~
devit
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

~~~
phire
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.

------
jszymborski
Seems down... here's a snapshot
[https://archive.is/a4M8I](https://archive.is/a4M8I)

