lr-mupen64plus-next: experimental scriptmodule for testing

saccublenda

@quicksilver I tried disabling the framebuffer emulation, but the problem remains. Does this bug also occur in older versions of the standalone mupen64plus that used the same version of gliden64 that is in lr-mupen64plus-next?

quicksilver

@saccublenda it has been an issue with gliden64 on the pi for a while now and was only just recently resolved (inadvertently I might add). The issue only occurred when frame buffer emulation was enabled and only in standalone mupen64plus. The bug didn't occur in lr-mupen64plus.

saccublenda

@quicksilver Ok, I will try to replicate the crash in lr-mupen64plus.

Heartless

Any Update or news from this emulator?
Its been a while since this post lacks any new feature or announcements

saccublenda

@Heartless I had some interactions with the developers on GitHub about the 15 minutes crash. It turned out to be related to texture cache size which was too big (15000) by default.
m4xw and hhromic prepared a new build with an extra core option that allows the user to set it to 1500, 4000 or 8000, and this fixed the bug for me. The new build can be installed by re-installing lr-mupen64plus-next form source through the RetroPie scriptmodule.

hooperre

Appears it’s now finished, ya?

https://www.bountysource.com/issues/60020750-update-m64p-gliden64-and-or-parallel-gliden64-to-latest-build?utm_source=share&utm_medium=ios_app

hhromic

@hooperre I tried to build it for RPI3 last night and still has some build issues.
So for now is not yet ready on the RPI unfortunately. I hope to be debugging the build soon but I'm currently busy with other things at the moment :(

quicksilver

@hhromic Yea I tried updating as well but it looks like Im still on a build from about a month ago.

xadox

@quicksilver The same goes for me. Yesterday I was able to build it and today it can't be updated anymore and aborts with several bugs.

hhromic

@quicksilver @xadox good news! last night we managed to make it work with the upstream dev (m4xw) :)
We will be testing a few more things before patching it on the repository for good.

@xadox are you sure you could build the mupen64plus "next" core? It hasn't been able to build for some time now, how did you compile it yesterday?

xadox

@hhromic said in lr-mupen64plus-next: experimental scriptmodule for testing:

@xadox are you sure you could build the mupen64plus "next" core? It hasn't been able to build for some time now, how did you compile it yesterday?

Yes. Since I was able to set it up at runcommand as default emulator.
Also, I get the folder lr-mupen64plus-next with mupen64plus_next_libretro.so in it under libretrocores.

I build it just as you described:

sudo ./retropie_packages.sh lr-mupen64plus-next clean
sudo ./retropie_packages.sh lr-mupen64plus-next

hhromic

@xadox just to confirm, you are building on an RPI device right?
Also can you check in scriptmodules/libretrocores/lr-mupen64plus-next.sh what it says on the gitPullOrClone line? I've been also updating the scriptmodule recently.

Anyway, the build fix is now upstream and it should work for everyone.

Just make sure you also update the scriptmodule. I recommend you to delete it and re-apply the instructions on the original post to make sure you are using the latest version.

This is now building the new updated GLideN64 plugin, so any feedback on how games are working for you, including your setup (RPI model, settings, GPU memory) are highly appreciated by the upstream developer to continue improving this core.

Be warned that some games take a bit of time to boot, so be patient!

An option we are very interested on getting feedback about is the Max Texture Cache Size. It is defaulted to 1500 on RPI but we think it can be raised to 4000 without major issues. If you can test that setting with different games and provide input it would be awesome.

Thanks everyone!

hhromic

Update
We found that games only boot once, if you try to boot them again it will crash.
This is due to a new shader cache. To make games boot again, you have to clear the cache in $HOME/RetroPie/BIOS/Mupen64plus/shaders. We will investigate more.

EDIT: This can be circumvented for now setting the EnableShadersStorage option to False.
EDIT2: A commit was pushed now to disable this option entirely on the RPI, so you should be fine now.

hhromic

Update

The FBemulation option is now also made available to RPI devices, with it being default to Off.
M4xw suggested me to play with it to see how it goes, and to play with:

EnableLODEmulation = Off
NoiseEmulation = Off

There is also a new FXAA option that we can play with on the RPI and see how it goes.

Lastly, m4xw also suggest to make sure you are experimenting with video threaded enabled in RetroArch, that potentially can give better performance as well.

Happy testing guys!

quicksilver

@hhromic I was just about to report that FBE appeared to be off even though it was set to true. If I update it should fix this problem? (I updated about an hour ago)

hhromic

@quicksilver yes the commit enabling it for RPI was pushed nearly an hour ago:
https://github.com/libretro/mupen64plus-libretro-nx/commit/67284e393cd0954f709e43943610f2e4443782d9

quicksilver

Looks like some games refuse to boot if framebuffer emulation is enabled. SW rogue squadron and battle for naboo for example.

Ocarina of Time has severe graphical depth issues if framebuffer emulation is enabled.

Also performance is much better than I expected, being able to have the advantages of up to date gliden64 and tweaking per game settings using retroarch is amazing.

Edit: I tested OOT with standalone Mupen64plus/gliden64 and it has the same graphical depth issues. If framebuffer emulation is turned off it looks ok. Must be a function the pi is incapable of.

hhromic

@quicksilver said in lr-mupen64plus-next: experimental scriptmodule for testing:

Looks like some games refuse to boot if framebuffer emulation is enabled. SW rogue squadron and battle for naboo for example.
Ocarina of Time has severe graphical depth issues if framebuffer emulation is enabled.
Edit: I tested OOT with standalone Mupen64plus/gliden64 and it has the same graphical depth issues. If framebuffer emulation is turned off it looks ok. Must be a function the pi is incapable of.

Yes I think FBEmu is too much for the RPI hence why it was unavailable before :(

Also performance is much better than I expected, being able to have the advantages of up to date gliden64 and tweaking per game settings using retroarch is amazing.

I tested it briefly and I also have the impression performance is pretty decent!
Also I have the impression that, compared to the old gliden plugin, the graphical emulation is better, i.e. there are more thing properly emulated.

quicksilver

@hhromic the standalone mupen64plus does allow rogue squadron to boot if framebuffer emulation is enabled so I'm not sure what's going on in this case.

Looks like Yoshi's story is running slower than the old lr-mupen64plus.

hhromic

@quicksilver I will report that to m4xw.

He also said that he fixed the Yoshi's Story issue. Therefore you need to re-build from source and see if gets better now! fingers crossed.