
Dolphin Progress Report: August 2016 - dEnigma
https://dolphin-emu.org/blog/2016/09/01/dolphin-progress-report-august-2016/
======
jjcm
The "allowing texture samples from 0x0" fix is really an interesting read.
Makes perfect sense if you think about it - it should always work just fine on
the console. Terribly poor readability for the code though.

~~~
Aldo_MX
But it still leaves you puzzled, why on earth would you load a texture from
0x0???

~~~
MBCook
It's a simple constant that you just happened to know won't hold values that
are considered transparent and is always loaded?

~~~
teach
More like it's a bug that worked on the real console so they didn't ever
notice it.

~~~
mastax
Yeah this seems like null pointer dereference that happened to work fine so it
was never found.

~~~
loeg
Well, and that NULL was a valid memory location on this platform. It's
actually quite nice to have virtual memory with NULL unmapped!

~~~
hrydgard
NULL is actually only a valid memory location from the view of the GPU on this
platform, not the CPU, and yeah, this is very likely to simply be an uncaught
bug.

Traditional game console architectures don't usually have a lot of memory
protection for the GPU - in fact, both the 360 and the 3DS were at various
points in times hacked by subverting the GPU to do writes to global memory.

~~~
to3m
This is going back a few years now, but I'm pretty sure NULL was valid to read
from the Wii's CPU (though not write, I don't think).

It was where the product code was stored, as I recall - so every now and again
you'd find some junk in some random string, starting with your title's product
code, and it would be time to track down another missing NULL check...

------
Narann
This is the quote any emulator dev should write on top of its desk:

> <the emulator> should never, ever trust the software it is running to be
> sane.

Console games always does weird things the only way to check is real hardware,
that's why writing a good emulator is hard, because you must have a way to
quickly test a particular behavior on hardware.

~~~
byuu
We like to romanticize our favorite games as being written by people as
passionate as we are about said games.

But the reality is that most (though certainly not all!!) of them are
primarily there for a paycheck. They're expected to work on new systems with
poor debugging capabilities, and get games out as fast as possible. So
naturally, they end up having lots of gross hacks and erroneous code just to
get things working and ship the game.

My favorite bug so far was a game that read from a write-only register in a
loop until a certain bit was set. That bit could never have been set under
normal conditions, so it was freezing in emulators. Turns out that the game
had a DMA channel running during each scanline, and after a few million
iterations of the loop, the stars would align and the DMA channel would read a
byte from memory that had the required bit set, and that value would be
floating on the bus, followed immediately by reading from said undefined
memory location. Since nothing would respond to it, it would reuse that DMA
byte fetch, and exit the loop.

Even more fun, to test on real hardware, I was using a copier device. But said
copier device pulled the data bus lines low whenever an unmapped region was
accessed, which effectively broke the game on the copier as well. It took me
two weeks of full-time work to track down that bug and exhaust all other
possibilities for what was happening.

I can't begin to imagine why that loop was in the shipped game, nor why it
only ever triggered once during hitting one of many buttons (this one required
to finish the level), in stage 6-2 of the game.

~~~
ryanplant-au
I'm going to have nightmares after reading that. I don't know you do it.

------
soared
I've never heard of this project - very interesting. I wonder if this will
start to happen more frequently in the near future.. software simply being to
old to really manage and keep updating to run on current operating systems.

I'm also always amazed at the hardware reqs for emulators. They suggest at
least an i5 or i7 and recommend a dedicated gpu! For a gamecube! Released 15
years ago!

~~~
mwfunk
Not surprised at the system requirements- it has to emulate a 486 MHz PowerPC
CPU. I have no idea why it would require a discrete GPU though. It only needs
to output SD-quality video. Maybe shader performance is a limiting factor in
the GPU emulations?

~~~
byuu
> Not surprised at the system requirements- it has to emulate a 486 MHz
> PowerPC CPU.

Yeah, to anyone who has tried to optimize a CPU interpreter before; dynamic
recompilers are nothing short of magical.

You'd be quite talented to emulate just a 50 MIPS interpreter core from a
sufficiently awkward CPU at 100% speed on modern processors. Let alone all the
other parts of the emulator, and synchronization between components.

Of course, dynamic recompilers sacrifice huge amounts of synchronization
precision in return for that raw speed. But it's very much a necessary evil --
otherwise we wouldn't have playable modern emulators at all. The developers of
dynarecs deserve extra special praise for being willing to give up both
idealism _and_ portability when writing them.

~~~
delroth
If you sacrifice synchronization you can also hit some pretty good performance
with an interpreter. Until fairly recently CEMU was interpreter-only and they
managed to hit 100% speed in a few games. The trick: they were running 50K
instructions at a time without checking external interrupts or scheduling
other components. At least, that's from what I can tell from reverse
engineering...

~~~
byuu
I can only see full speed on a Wii U CPU interpreter happening when the game
has huge idle loops that you can skip over.

If you're saying they hit it at 100% Wii U CPU load at fullspeed, then that's
really impressive! :)

------
petetnt
For those interested, the next generation Nintendo emulator, Cemu for Wii U
emulation is also making rapid progress, with many games fully playable near
native speeds.

[http://cemu.info/](http://cemu.info/)

Unlike Dolphin, it's currently closed source & Patreon backed though.

~~~
Jasper_
There's reasons to believe that Cemu is closed-source because it uses stolen
code from official Nintendo SDKs.

decaf is fully open source: [https://github.com/decaf-emu/decaf-
emu](https://github.com/decaf-emu/decaf-emu)

~~~
delroth
I think the claim of "using stolen code" is a bit strong. Do you have any
evidence of that?

I'm completely willing to believe that they asm2c'd quite a lot of system
libraries instead of properly reimplementing them. And I wouldn't be surprised
if that's a prime reason why their software is not open source. But that's a
step away from "stolen code" in my opinion.

