Mupen64+ crashes when interacting with window

RetroArch Windows devices
#1

I’ve recently downloaded RetroArch, as my friends recommended it as a very good emulator, probably the best there is right now. And in fact, it really is. The cores run even better than what they’re based on, and I’m happy to have stumbled upon this gem. However, while trying to play N64 games, the Mupen64+ core crashes whenever I interact with the RetroArch window. Alt-tabbing, moving the window, resizing, maximizing, fullscreening, windowing, everything crashes it. Which is a shame, since I’m a person who loves to multitask – chatting in skype and playing games at the same time. Does anybody have any idea what causes this error?

Operating System Windows 7 Ultimate 64-bit SP1 CPU AMD FX-8350 Vishera 32nm Technology RAM 8,00GB Single-Channel DDR3 @ 803MHz (4-5-5-15) Motherboard ASUSTeK Computer INC. M5A78L-M/USB3 (AM3R2) Graphics HBTV-3203HD (1280x720@60Hz) 2048MB ATI AMD Radeon R9 200 Series (XFX Pine Group) Storage 931GB Seagate ST1000DM003-1CH162 ATA Device (SATA) Optical Drives ATAPI iHAS122 W ATA Device Audio AMD High Definition Audio Device

#2

I can alt-tab just fine here. What version are you using? resizing is a no go since context-reset hasn’t been implemented

#3

I’m using the latest stable release. I’ve been considering trying out a nightly build to see if the alt-tabbing issue is solved. Also, it’s not only resizing – even moving the window to the center causes it to crash.

#4

Weird… Works fine here:

[media:1qelft2v]https://dl.dropboxusercontent.com/u/149537/Desktop%2012.28.2014%20-%2001.01.30.06.mp4[/media:1qelft2v]

#5

I guess it’s something to do with my computer or my monitor, then. http://youtu.be/fd0zPmhtKJY

As expected, opting to a nightly build only increased my crashing issues.

EDIT: This may have something to do with it.

#6

Try setting it to OpenGL if its a D3D error.

#7

Could be a video driver issue as recent Catalyst Omega drivers seemed to have stopped the Mupen64 core from crashing in this way i’m guessing, even trying an old retroarch with it, doesn’t seem to happen to me anymore.

I have had this same alt-tab+window manipulation crash with Mupen64 while trying to develop the 3dfx filter in the past year on 2013 drivers and I assume this crash was already known, and assumed the crash dealt with shader recompilation hitting the wall with Mupen64’s cached shaders

#8

I’d like to state that I’m running into this issue. Anything that causes Retroarch to lose focus while using the Mupen64plus core causes the program to crash whenever I reenter it. I almost exclusively use the Glide plugin.

No relevant info appears in the command prompt box upon it crashing. Other cores don’t seem to run into this problem. I’m always using the OpenGL backend, and my graphics card driver is up to date.

#9

Thanks for the info, Leilei. I’ll try updating to the latest beta driver for Cataclysm Omega. Seems like I skipped the most basic step – keeping your drivers up to date, haha.

I was capable of temporarily solving this issue by altering Mupen64’s core options – however, it started crashing on start up shortly after. However, I’ll say.

For the little time I was capable of using it, the way 3dfx shader looked made my jaw drop. It gave me such a nostalgic feeling from when I played on my actual N64 that I almost cried tears of joy.

#10

The crashing seems to occur when using any graphics plugin other than the Angrylion plugin. Of course, that comes with its own givens, such as not being able to play most games at full speed consistently. Is there some reason why this plugin would be the only one to not crash when making RetroArch an inactive window and returning to it?

I will say, though, that the Angrylion plugin sure works as advertised. Never before using it had I seen the level geometry in the first part of Whomp’s Fortress in Super Mario 64 render properly in an emulator. Now THAT is pretty awesome.

#11

Bleak, try changing the framerate speed from “original” to “fullspeed”. That solved the issue for me.

#12

Nope, it’s an inconsistent fix. Doing that only works some of the time, and reopening RetroArch after making the change will make it have no positive effect on stability.

Something seems to be wrong with the plugin implementation for the core.

#13

I’m not able to even run n64 games using both the latest nightly build retroach and cores. No option to change the plugins even appears in retroarch_core__option.cfg

#14

It appears as if the most recent nightlies have fixed this issue! The other plugins now work when switching windows.

On the flipside, though, the updates seem to have broken the Angrylion plugin.

#15

What’s the best nightly to feature a working angrylion plugin?

#16

The issue has returned in recent builds of this core.

With all the changes recently brought about by porting features from GLideN64, it’s not a surprise that some things might sporadically break. However, I’m kind of surprised that this issue has shown up again.

With me, it seems like the Angrylion plugin seems to vary its functioning state frequently with the libretro core. It’ll work for a few builds, then it’ll break again. Make sure you have the internal resolution set to 640 x 480 and the Angrylion VI filter on in core options. Not that that matters, as I can’t get it to work in the most recent build for the core.

I don’t know if you’d necessarily care for it to work, anyways. I’m not surprised that it doesn’t run at full speed on my PC. However, I’ve seen a report from someone who has the most recent Haswell-based Intel processors OCed at high clock rates that still can’t run it at full speed (standalone emulator, not RetroArch BTW), despite the emulator not using CPU resources fully. Processor speed has a lot to do with it, but it sounds like there might also be an issue with how the plugin works on a fundamental level. I don’t know if that’s the case, though. Maybe the person just didn’t have things set up correctly.