Mupen64-libretro on Windows

Libretro Cores
#1

I’ve fixed up the build so it builds on Win32 and Win64 now. Tested the 32-bit build a bit in wine, and seems to work fine. However, it still uses the GLES2 drivers pulled from mupen64plus-AE, so compatibility might not be the same. Please don’t bitch if things don’t work right. We know …

I also noticed an interesting thing, at least in SM64. Glide64/Glitch64 runs at 30 fps (like the game itself does I guess), but Rice does either frame doubling or higher FPS because it’s 60 …

EDIT: Remember to follow the README with .ini’s. https://github.com/libretro/mupen64plus-libretro

#2

I know there are probably a few people dying to test this out so here is a 64 bit binary. If you don’t place the ini’s in your system directory then it will crash so be sure to do that first.

https://anonfiles.com/file/54595aaae55da16b8cb98daa96a31a67

also, just a heads up, it will crash on exit.

#3

http://www.mediafire.com/download/h7cdkd4cglt0cmu/RetroArch%2BMupen64plus_Win64_20130831.7z

Includes two Mupen64plus-libretro dll’s, one with interpreter and the other with x86_64 dynarec. Also includes the ini files you need to put in your system directory, as well as the latest RetroArch build

Here’s a win32 build of the dll: http://www.mediafire.com/download/t05u5ludr1lqjr1/Mupen64Plus.zip

Put the ini files in the system directory.

You’ll also need a fairly recent build of Retroarch itself, so here’s one if you need it: http://www.mediafire.com/download/geio8j16z76p7qz/retroarch.zip

#4

It’s nice to see how much work is going into the N64 core. The only issue I came across was that editing the core options in the RGUI do not persist on resets, and editing the plugin config files do not seem to do anything.

#5

The downloads that have been added to the Updater don’t work. Click on it and it will stop with the error message:

Download not complete

#6

Don’t take this as “bitching”, but there is a pretty major bug. In Mario 64, if you try to enter Bowser’s door before you have 8 stars, RetroArch crashes for me. Can someone else reproduce this?

#7

I’ll give it a shot, but the reason they said not to “bitch” is because this is an early RC and many problems are already known about. Give it more time to mature.

#8

Another glitch report. Controls are messed up.

Xinput Wrapper PS3 controller RetroArch version 0.9.9.6 (2013 08 31)

Likely problems with the Xinput driver.

I expect there to be a thousand little glitches.

#9

Thanks for the heads-up. That was due to a stupid error on my part. They should download successfully now, but the retroarch.exe binaries up there seem to fail with an ‘unsupported environ’ even though they’re freshly built… EDIT: false alarm. I think it should be fine. Let me know if anyone has problems with it.

EDIT2: also, GDPD, was that using the interpreter core, the dynarec core or both?

#10

I was using a core compiled by another user. It was labeled as having the dynarec built-in, but I couldn’t access it from the core options, so I suppose I was running cached interpreter. In any case, I downloaded the dynarec core from the Updater, and it seems to work, and now I don’t get the crash there anymore. Huh.

That said, it ends up crashing upon exit for me every time.

#11

yeah the exit crash thing seems to be universal. I tried my own compile and the one’s from the updater and they all crash on exit. Nothing that can’t be fixed for the future though.

#12

Seems like the latest builds fix the crashing issue at least, so that’s good.

I’ve been wondering, though. Why is this using the plugins from the Android Edition? Why not the ones from the PC version? Even though those have some issues, as far as I can tell they are nowhere near as bad as on the GLES versions. At least comparing Mupen64Plus running Glide64mk2 to the Android version, I see less glitches. Was this done for the purposes of speed, or was the code more portable?

#13

To avoid having to maintain two plugin sets I suppose. One set of plugins is bad enough as is :stuck_out_tongue:

#14

So I’m guessing the GLES plugins are more portable, then?

#15

Well, yes. They run on GLES and hence desktop GL as well.

#16

Strangly, they behave worse on mobile right now than on the desktop. I can play through most of Super Mario 64 on my Linux x64 machine and see very few graphical errors(textures shuddering when camera gets too close, other known issues) but when I run the Android build on my Shield… All shadows are drawn incorrectly, sometimes textures are discolored and there’s all sorts of strange issues. I wish I knew any OpenGL or GLES to help with this, heh. Time to break open the specifications, I suppose.

#17

A day late and a dollar short… I can only speak to Android on this, but Android GLES drivers are shitty, in case it isn’t abundantly obvious. As far as I can tell, most gles drivers on Android don’t implement polygon_offset_fill to specification, which leads to stitching on things like shadows and decals for most Android devices. In mupen64plus-ae we chose to resort to some really nasty device-specific hacks. I’ll go along with it on mupen64plus-ae since it has such a narrow platform scope, but I would never even suggest doing that kind of thing for RetroArch. I honestly don’t think a semi-elegant solution will ever exist for android…

#18

anyone noticed the speed issue with PAL games? try playing the EU version of zelda oot and notice how the intro music is stuttering. the game should run with 16.6 fps but instead it runs with 20fps which is the framerate of the NTSC version. I don’t know if this is an issue of the core or has something to do with how the audio sync of retroarch works. but a fix for this issue would be highly appreciated :wink:

#19

It’s a known issue: https://github.com/libretro/mupen64plus … /issues/80

#20

oh alright, should have checked on github first.