RetroPie forum home
    • Recent
    • Tags
    • Popular
    • Home
    • Docs
    • Register
    • Login

    lr-mupen64plus-next: experimental scriptmodule for testing

    Scheduled Pinned Locked Moved Ideas and Development
    retroarchlibretro coreexperimentaltestingn64
    80 Posts 13 Posters 19.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • saccublendaS
      saccublenda @quicksilver
      last edited by 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?

      quicksilverQ 1 Reply Last reply Reply Quote 0
      • quicksilverQ
        quicksilver @saccublenda
        last edited by

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

        saccublendaS 1 Reply Last reply Reply Quote 0
        • saccublendaS
          saccublenda @quicksilver
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • H
            Heartless
            last edited by

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

            saccublendaS 1 Reply Last reply Reply Quote 0
            • saccublendaS
              saccublenda @Heartless
              last edited by

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

              1 Reply Last reply Reply Quote 1
              • hooperreH
                hooperre
                last edited by

                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

                4B ~ RPi PSU 5.1V / 3.0A ~ 32GB SanDisk microSD ~ 128GB USB

                H 1 Reply Last reply Reply Quote 1
                • H
                  hhromic @hooperre
                  last edited by 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 :(

                  quicksilverQ 1 Reply Last reply Reply Quote 0
                  • quicksilverQ
                    quicksilver @hhromic
                    last edited by

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

                    xadoxX H 2 Replies Last reply Reply Quote 0
                    • xadoxX
                      xadox @quicksilver
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • H
                        hhromic @quicksilver
                        last edited by

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

                        xadoxX 1 Reply Last reply Reply Quote 0
                        • xadoxX
                          xadox @hhromic
                          last edited by 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
                          
                          H 1 Reply Last reply Reply Quote 0
                          • H
                            hhromic @xadox
                            last edited by 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!

                            1 Reply Last reply Reply Quote 2
                            • H
                              hhromic
                              last edited by 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.

                              1 Reply Last reply Reply Quote 2
                              • H
                                hhromic
                                last edited by

                                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!

                                quicksilverQ 1 Reply Last reply Reply Quote 0
                                • quicksilverQ
                                  quicksilver @hhromic
                                  last edited by

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

                                  H 1 Reply Last reply Reply Quote 0
                                  • H
                                    hhromic @quicksilver
                                    last edited by

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

                                    1 Reply Last reply Reply Quote 0
                                    • quicksilverQ
                                      quicksilver
                                      last edited by 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.

                                      H 1 Reply Last reply Reply Quote 0
                                      • H
                                        hhromic @quicksilver
                                        last edited by

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

                                        quicksilverQ 1 Reply Last reply Reply Quote 0
                                        • quicksilverQ
                                          quicksilver @hhromic
                                          last edited by

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

                                          H 1 Reply Last reply Reply Quote 0
                                          • H
                                            hhromic @quicksilver
                                            last edited by

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

                                            quicksilverQ 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post

                                            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.