lr-mupen64plus-next: experimental scriptmodule for testing

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.

quicksilver

@hhromic Yoshi's Story is performing much better now, thank you for bringing it to m4xw's attention!

Something else I have noticed is when toggling the bi-linear filter in the retroarch video settings the screen goes black. You can still hear the game audio playing but suddenly there is no display. In the old lr-mupen64plus you could toggle this setting on the fly with no issue.

Also now that this emulator is on parity with the current gliden64 is there any plans to incorporate the script module into retropie?

hhromic

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

@hhromic Yoshi's Story is performing much better now, thank you for bringing it to m4xw's attention!

You are welcome, the idea is to easen the development :)

Something else I have noticed is when toggling the bi-linear filter in the retroarch video settings the screen goes black. You can still hear the game audio playing but suddenly there is no display. In the old lr-mupen64plus you could toggle this setting on the fly with no issue.

We will be investigating, m4xw mainly test using the Switch version and he said this does not happen there.

Also now that this emulator is on parity with the current gliden64 is there any plans to incorporate the script module into retropie?

The plan has been always to incorporate the scriptmodule into RetroPie eventually. I first launched this topic to help debug and gather feedback before submitting it formally.

If you think this emulator is now on par with the other alternatives (I know your feedback is very trustful in terms of N64 emulation), I have no problem on polishing the scriptmodule and send it.

@BuZz are you ok with adding this scriptmodule to RetroPie? As mentioned in the OP, the main developers do not plan to update the older lr-mupen64plus anymore in favour of this "next" version.

quicksilver

@hhromic in "Iggy's reckin' balls"the textures are now missing on the race tracks. Previously was working fine with lr-mupen64plus-next before the big gliden64 update. I should note that this matches the current standalone gliden64 as it is also missing the textures.

Edit: nevermind, I found that by disabling less accurate blending that the tracks display properly again.