Please do not post a support request without first reading and following the advice in https://retropie.org.uk/forum/topic/3/read-this-first

lr-mupen64plus-next: experimental scriptmodule for testing



  • @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
    


  • @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!



  • 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.



  • 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!



  • @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)





  • 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.



  • @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.



  • @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.



  • @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.



  • @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?



  • @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.



  • @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.


  • administrators

    @hhromic yes.



  • @quicksilver the scriptmodule is now part of official RetroPie (thanks @BuZz !).

    You will find it under the experimental package section after you update your RetroPie-Setup script :). I update the OP now to reflect this too.

    I hope it brings joy to your N64 memories! Feel free to report issues and feedback for future development too.



  • @hhromic Thank-you to you and BuZz! Would the lr-mupen64plus-next dev prefer direct bug reports to the github or should we keep reporting here? I saw some of his responses on there that seemed to imply he didnt want a plethora of bug reports on the github page.



  • I tested it on Super Mario 64. There are some slowdowns here and there, but I found it much more fluid than the previous versions of lr-mupen64plus-next.



Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.

Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.