TASEmulators / BizHawk

BizHawk is a multi-system emulator written in C#. BizHawk provides nice features for casual gamers such as full screen, and joypad support in addition to full rerecording and debugging tools for all system cores.
http://tasvideos.org/BizHawk.html
Other
2.2k stars 384 forks source link

Emuhawk crashes when reloading N64 core with XSplit Game Source enabled. #831

Closed NarryG closed 7 years ago

NarryG commented 7 years ago

Here's an interesting and extremely annoying bug for streamers.

If you're running XSplit and have the "Game Source" enabled, if you load an N64 game then take focus away from the Emuhawk window, then do anything that reloads the N64 core (manually reload the core, load a different N64 game, etc), the core will fail to load and you'll be greeted with a black screen. If you then quit the program, you'll be greeted with a crash. If you do anything else to reload the core, you'll be greeted with a crash.

Disabling XSplit's "Game Source" fixes this issue but prevents optimal capture of the emulation output for streamers (as game capture is generally better than window capture. Also, window capture doesn't work properly with OpenGL mode)

Video demonstrating the bug: https://streamable.com/j7vzd

Steps to reproduce: Open XSplit (with Game Source enabled in the settings, on by default) Open Emuhawk Load N64 Rom Switch focus from emuhawk to any other window and switch back Reload the N64 Core in some way (manual reload, change games, etc) You should be greeted with a black screen instead of the game you attempted loading, and if you attempt to load it again, it crashes.

This has been reproduced by a friend and I've reproduced it on multiple computers.

zeromus commented 7 years ago

game source is hacks. these hacks break the jabo plugin, which we don't have the source code to. If we had the source code, someone might could find out how xsplit is breaking jabo. But it's XSplit's problem to fix.

You could use a n64 video different plugin, but none of them work with game source it seems, so you're out of luck.

zeromus commented 7 years ago

Why did I see an email about this which didnt show up in the thread

NarryG commented 7 years ago

Apologies. I removed the post as I discovered my replication steps were incorrect.

I had a weird quirk where it'd crash when reloading the N64 core which went away after a system reboot and I haven't been able to replicate.

I thought it was related to having Process Explorer open (as after I opened Process Explorer it started happening) so I posted a response asking for it to be re-opened as I thought other programs were causing a very similar crash, but I haven't been able to replicate it after rebooting my computer.

All I can say for certain is it was related to Glide64MK2 as before I rebooted, I loaded up a second copy with the default settings and it was running fine. Went back to the version I had set to use Glide64Mk2 and it started crashing again (the only differences in config were Glide64Mk2 and OpenGL. I actually tried changing OpenGL back to DirectX and it still happened. I never directly tried changing Glide back to Jabo but I did try a fresh copy as I stated before).

I'm working on replicating it but as of now I haven't been able to. Due to the fact it persisted across restarts of the application and went away after reboot, either something external was interfering (which is why I thought it was process explorer) or something outside of the emulator experienced an issue (graphics driver?). I'm working to replicate it and I'll open a new issue if I can properly replicate it.

One thing to note is that the program doesn't quit properly when using Glide64Mk2. You'll find that when you quit it stays open for about 30 seconds and werfault.exe will be spawned under it and then it'll close.