Mupen64 and GlideN64

I would like to ask, which version of Glide does the Mupen core use? Are any fixes from GlideN64 implemented?

There are many fixes in GlideN64 that fix a few games, one of the major ones was Beetle Adventure Racing. Using PJ64 and GlideN64, the graphics are almost perfect even in HLE mode. They fixed several things like the reflections on the car, the menu transitions and the fog effects in the second track.

However, i have yet to see these fixes in the Mupen Core. The game looks pretty glithcy like it did years ago. So does it use an outdated version? These fixes are pretty old already, they were introduced more than a year ago, most likely more. Unfortunately, ParaLLEl also shows some very weird glitches in various parts that make the game look unplayable.

So, is there any chance we see the newer GlideN64 used by the core?

There is a libretro core in development that uses latest GLideN64 - https://github.com/loganmc10/GLupeN64

Only downside is that it’s not Windows compatible yet, but it looks promising. I’ve started a GitHub issue regarding this so hopefully a nice kind soul in the future will have the power to make it work.

has anyone happened to build an android version of that core? I would love to get my hands on it and test it but have no idea how to build it myself.

My question is, what version of Glide does the mupen core use? In Goldeneye i don’t see the graphic bugs i usually see in the standalone versions of the plugin. Seems like most of the fixes in GlideN64 have made it in the core version (at least for this game)?

@GemaH Glide(64) and GLideN64 are different plugins. mupen64-libretro’s version of GLideN64 is from about 5-6 months ago it looks like, but with some backpatches/changes.

glupen64 uses the current version.

[QUOTE=dankcushions;46814]@GemaH Glide(64) and GLideN64 are different plugins. mupen64-libretro’s version of GLideN64 is from about 5-6 months ago it looks like, but with some backpatches/changes.

glupen64 uses the current version.[/QUOTE] Wait, Mupen core uses the older Glide not GlideN. However, it seems to work better than the standalone Glide. It has some of the fixes in Goldeneye that i saw on standalone GlideN.

So i wonder if the core version is a more advanced version of the older Glide (not GlideN).

There is now a Windows (x64) build of GLupeN64 for Libretro/RetroArch:

https://s3.amazonaws.com/loganbuildbot/glupen64_libretro.dll

Please report issues to this GitHub issue: https://github.com/loganmc10/GLupeN64/issues/36

Any chance there is an Android build of glupen? Haha

Thanks for the core.

I only test one game when i use GlideN64, Beetle Adventure Racing (it was a focus game when the plugin was made). It doesn’t work as well as on standalone though but i submitted it’s issues on GitHub.

I recommend you to file a issue request on GitHub, https://github.com/loganmc10/GLupeN64 It shouldn’t be hard to fix I think.

THANK YOU! I saw he replied to you with a link to new builds and it works great on android!

Which games are running noticeably better on glupen64?

Just tried Beetle racing which has nasty bugs and Mario 64 that slows down a lot here and there…

[QUOTE=Tatsuya79;46964]Which games are running noticeably better on glupen64?

Just tried Beetle racing which has nasty bugs and Mario 64 that slows down a lot here and there…[/QUOTE] I’m willing to test a lot of games with the plugin, once a specific issue is sorted out.

There is also the issue that you can’t “overclock” the N64 like you can in Mupen and ParaLLel core and the fact that you can’t use shaders at all (i get a black screen, even on the RetroArch GUI when i use a shader with this).

What parts in Mario64 slow down for you?

Edit: glsl shaders work with this. Also, i noticed increased input lag compared to Mupen64 core.

Just going near the castle at the beginning and looking on the right side. Or entering world 1 (left door) and everything is slow.

Or perhaps it needs threading ON? I wonder about the need to activate this option in Retroarch sometimes…

edit: Ok it’s random. Speed is quite OK (feels a bit slow? or perhaps I’m just used to the fullframe speed option other plugins have) then I go to the option menu. Even if I change nothing there, when I’m back to the game it slows down a lot.

Figured it out. That’s again one of those GPU energy saving issues.

Making a profile for retroarch with power management mode on “Prefer maximum performance” in nvidia control panel makes it run OK.

What about the input lag? Do you feel like it’s higher on GlupeN64?

Yes, I feel it’s quite bad. Hope that can be fixed.

But there are some improvements for sure. Just played Rally 99/2000 which is working nicely. Not a bad Sega Rally alternative.

[QUOTE=Tatsuya79;47129]Yes, I feel it’s quite bad. Hope that can be fixed.

But there are some improvements for sure. Just played Rally 99/2000 which is working nicely. Not a bad Sega Rally alternative.[/QUOTE] And those real time reflections, damn!

There’s definitely high input lag, I tested it with Brunnis Method ©. 5 frames vs 2 in Mario 64. Made an issue here:

https://github.com/loganmc10/GLupeN64/issues/55