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.6k 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.
    • H
      hhromic
      last edited by

      Thanks everyone for all the testing and feedback reporting. This is surely very useful and I will make sure to collate and forward upstream to @m4xw.
      This core seems very promising and your feedback seems to be supportive of this too!

      As @quicksilver pointed out before, besides comparing "next" to the standalone emulator, it would be nice to also compare to the old "non-next" libretro core, to be sure of the real contribution of this new core.

      I'm currently waiting for a small enhancement I submitted upstream to be merged so we are able to rename the options prefix for the core. In this way it will be able to be installed gracefully alongside the old core and don't have option name clashing.


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

      I also want to ask how to disable framebuffer for further testing

      The option name should be Framebuffer Emulation; True|False in the retroarch core options (when you have a rom loaded).

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

      @hhromic, do you know if it is/will be possible to edit the game settings files in a similar format to stand alone mupen glide?
      what I mean is, stand alone included "gliden64_custom.ini" in it's config directory, this is the same file that Gliden64 uses on my Windows machine with Project64. It allowed me to define specific settings which weren't normally available through the GUI or config files.

      I know what you mean. I went to check the source code and I'm not sure this is currently possible, but is a good suggestion. I will ask @m4xw and see what he thinks. Thanks for the idea.

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

        Update
        A proper announcement/introduction to lr-mupen64plus-next was made available by @m4xw recently, so I added that to the OP for more accurate information about the core. @m4xw also recently said that the GlideN64 update is about 50% done and going steady :)

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

          Update
          I sent a patch upstream that is now merged and allows to customise the option name prefix of the core so they don't clash with the old lr-mupen64plus core. In other words, it is now possible to install this new core and the old core at the same time and they won't interfere with the options of each other.

          The scriptmodule configures the prefix as mupen64plus-next-*. I updated the OP notes with this.

          Thanks for all for the testing! Let me know if you find any other issues so we can send the scriptmodule to RetroPie to be integrated.

          Soon the updated GLideN64 plugin should be available upstream, so stay tuned if you are interested on testing this. I also will be checking some of the suggestions left in this topic with @m4xw

          1 Reply Last reply Reply Quote 1
          • D
            dc.all
            last edited by

            Sorry to be asking this here, but I guess it's relevant to this new Core.
            Is there currently a way to set the peak analog range? playing Duke64 I notice that my analog direction will max out after I've only pushed my ps3's stick to about half it's range.
            Stand Alone mupen has a setting for Analog Peak under it's generated autoinputcfg.ini, was hoping there'd be a similar setting in Mupen-Next.
            I've already spotted the deadzone and sensetivity settings under the Liberto Menu, but they still won't actually increase the range of the analog.
            I have my controllers calibrated already and the full range is witnessed when viewing jstest from terminal.
            Looking forward to trying out the new Gliden64 when it's updated :D

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

              @hhromic so was testing out Mario tennis, game is playable using the old lr-mupen64plus but game goes to a black screen and freezes with lr-mupen64plus-next. Had to ssh in and reboot.

              Edit: found a game that lr-mupen64plus-next is better at running: Nascar 99. Lr-mupen64plus just goes to a black screen and fails to launch the game. Standalone mupen64plus+gliden64 will load the game but the title screen is black and the game froze on on me about 5 secs into a race.

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

                Hello,
                I've noticed that after 15 minutes or so the emulator starts glitching and then it crashes.
                Anyone else has this problem?

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

                  @saccublenda very likely due to the fact that it's using a older version of gliden64 for video. Older versions of gliden64 have issues on raspberry pis when framebuffer emulation is enabled. Try turning framebuffer emulation off. Though some effects may not render properly.

                  saccublendaS 1 Reply Last reply Reply Quote 1
                  • 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
                                            • 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.