Emulator

Would you please test this game with the fifobusy branch? I guess you can locally merge the fifobusy branch into the current master for the test.

...Uh. I'm not exactly experienced at using git. How would I go about merging it?

...Okay, I took a fresh clone of master and rebased it on the latest FifoBusy commit, skipping conflicts (I don't know how i would merge the code manually, or if it even should be merged). Compiles fine.

Yet, I get the exact same results with the game.

I don't know whether to blame Dolphin or my terrible git skills, but I'm 80% sure I rebased it and built it properly. ;~;

Would you please identify the revision that broke the game? That'll give us a starting point.

I first tried the game on revision 0ed8af2287bd, and it was already crashing like this. Sorry, I can't provide more detail...

You can try some older builds and see when it was working, then move up until it doesn't.

it sounds like you may have used git incorrectly there; you want to checkout fifobusy branch OR rebase fifobusy on master (not the other way around).
you can use git bisect to speed up testing if needed.

also some gdb trace of the crash would be helpful in any case.

$ git clone https://code.google.com/p/dolphin-emu/
$ cd dolphin-emu
$ git checkout FifoBusy
$ git rebase master
$ git rebase --skip
$ git rebase --skip
$ cmake . && make -j2
(compiles fine, Dolphin says [FifoBusy] in its window titlebar)

Running the game produces the same results as before, though it's not a solid green this time - the top two-sixths or so plus another line in the middle are a jumble of colors, mostly purple/pink and white. Stuff I've seen numerous times before when using Dolphin, these greenscreens and jumbles of colors.

So, FifoBusy doesn't help.

On the gdb trace suggestion: how does one eke a core dump out of Dolphin? (Sorry to ask so many questions.)

On trying older builds: I will if I have more time. I did try it on the prebuilt 3.0 (yeah, I'm lazy), but I can't get past the Poe quote. (It's not crashing, it just doesn't seem to accept my button-presses. I haven't tried any other games, so I'm not sure if my GCpad settings or the game is broken there.)

In Source/Core/Core/Src/PowerPC/PowerPC.cpp, try commenting out line 296:

ExpansionInterface::UpdateInterrupts();

http://code.google.com/p/dolphin-emu/source/browse/Source/Core/Core/Src/PowerPC/PowerPC.cpp#296

And retry. Let us know if that fixes the issue.

[edits file in Smultron, saves, cmake . && make -j2]
...Nope, it doesn't. Still the same crash...

If a CrashReporter log is of any help, here: http://pastebin.com/ssjcHnCY

The graphics thread, thread 2, is crashing with a simple EXC_BAD_ACCESS. How... ominous? I dunno, I'm not a programmer.

But that gives me an idea: disable Dual Core!

...Nope, stupid idea, made no difference.

Is that crash log from before or after you made the change skid told you to?

OGL::VertexManager::Draw() is the problem func in that crash log. Do you have the crash log of a clean build of master?

After - 3.0-479-dirty, 479 indicating it's on FifoBusy, and dirty indicating that it's, well, not a clean build.

http://pastebin.com/erTnpuTR
Here's it on a current build of master (3.0-465). The screen isn't a solid green on master anymore, for some reason.

It appears that Dolphin is using the Intel HD 3000. Do you also have a discrete video card? If so try changing to that.

Dolphin does not work that well with Intel GPU (even on operating systems other than OSX).

OGL::VertexManager::Draw()

Same place! :D

Ah... No, I don't have a discrete GPU, unfortunately. (It's a MacBook Air, and it has Thunderbolt, so I could theoretically hook up a Thunderbolt GPU, once those exist.)

My other Mac has a discrete GPU, an ATi Radeon X1600, but that thing's so weak I get severe graphical glitches (e.g. textures being parts of other OS X windows, so in Brawl I have things like Mario standing on a platform that looks like iTunes's titlebar).

The software renderer just gives me a black screen. Is it supposed to be broken?

Yeah, with the software renderer, if you wait 30 minutes, a Nintendo logo might appear though. That's also not OSX specific.

parlane: I have about ten crash logs from this game, from a few different builds of Dolphin (master, FifoBusy, FifoBusy with that line in PowerPC.cpp commented out), and they all look pretty much the same.

The software renderer's broken on every OS for this game? Hm... If the software renderer is for debug purposes, why's it broken where OpenGL isn't?

Software rendering isn't broken. It's just very very slow.

Turns out, a) I'm an idiot, and b) every single checkbox in Graphics > Hacks > Other is specifically made to break things, especially on Intel GPUs. I had half these checkboxes idiotically checked when I filed this issue - some time later, I unchecked everything but OpenMP texture decoding, which fixed everything but Metroid Prime, and today I finally realized OpenMP broke that game, and subsequently realized that I hadn't tested Eternal Darkness since before I unchecked any of those options. The game works perfectly fine now. (Also: those green/partly-green screen flashes are gone with EFB to RAM.)

tl;dr This issue is invalid, I suck at graphics options, everyone using an Intel GPU should disable everything in Graphics > Hacks > Other.