lr-mupen64plus-next: experimental scriptmodule for testing

hhromic

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.

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

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

dc.all

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

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.

saccublenda

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

quicksilver

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

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.