lr-mupen64plus-next: experimental scriptmodule for testing

2stick

This core is awesome on the Nintendo Switch. I'll have to try it out on my RetroPie tonight. Thanks for setting this up.

Heartless

@hhromic Kinda a late response but every game tested comes from the raspberry pi 3 b+

Heartless

@dc-all Hey pretty good testing there. Really appreciated

quicksilver

So far in my comparison I have not found any significant differences between the old lr-mupen64plus and lr-mupen64plus-next. I suspect the real differences will emerge once the gliden64 plugin is brought up to date.

hhromic

@quicksilver thanks for the feedback! Yes probably with the gliden64 update some differences should be expected. Not only gliden64 is being updated, also the core and the hle-rsp modules.

I still have the feeling that "next" runs better for me, but I admit it is subjective. A user above made clear that the standalone mupen64+gliden64 emulator is worse than "next", maybe because of what you said of being "too new for the RPI" ?

I'm going to forward all this feedback to @m4xw once the Gliden64 is in place (as he requested).

Btw, how did you compile "next" in the end? did you add the -std=gnu11 flag?
Thanks!

quicksilver

@hhromic Im running it on stretch. I have been needing to get switched over to retropie 4.4 based on stretch and this has been my motivation.

The other user is correct that standalone mupe64 is sometimes worse than the libretro core (the original and "next"). This I assume is because the more up to date standalone is more demanding on the GPU which affects performance but there are also some games that run smoothly with the standalone core but have severe graphical issues which I assume is because the pis GPU is GLes2 and cannot perform certain functions. But in most cases the standalone core better. Part of the issue here is that we really need to be comparing using the same settings. An above user completely disabled framebuffer emulation which is going to give skewed results and will not be a fair comparison.

Were there any specific games you tested where "next" felt faster than the old lr-mupen?

hhromic

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

Were there any specific games you tested where "next" felt faster than the old lr-mupen?

I can't remember now, it was very subjective and I might have been biased :)
When I have more time to test myself will report back too. Thanks for the feedback!

By the way the fix for Jessie is merged upstream, in case you still have other Jessie devices :D

Heartless

Hello!
Today i tested the next games
Conkers Bad Fur Day: Just as unplayable as the others
Banjo Kazooie: Surprisingly this games plays very fine in the tutorial world!,maybe he will struggle in other areas but for now doesnt seem to be the case
Testing updates:
Kirby 64: The game plays very smooth with some audio lag in the cutscenes(very minor but still)played the whole first world without any slowdowns and also the first half of the second world with no repercussions. I realize a minor graphic bug on the rooftops but doesnt interrupt with the performence of the game. For now i consider this game very playable!
I also want to ask how to disable framebuffer for further testing
See ya!

dc.all

I did a bit more testing last night. No comparisons this time, sorry. Just booting, tweaking settings and seeing what I can get to work.
hopefully this information will still be useful.
Raspberry Pi3 B+, latest stock Rertropie image.

Mario Golf: Fairly decent performance, however you get a black screen when trying to take your shot. if I recall, this is a framebuffer issue. couldn't fix this.

Bomberman64: I was able to fix the transparencies issue by changing that setting (which I forget what it's called right now) to ASync. making the game completely playable.

Space Station: Silicon Valley: The sprite errors which I was experiencing were fixed by changing the filtering to 3point.
stage select screen appears incorrectly, and framerate is fine for the most part.

other thoughts, the only way for me to get any decent performance is to use "Dynamic recompiler", cache and the other one will quarter my frame rate. this setting also seems to effect boot times too, which seemed odd to me.

Also the actual display resolution effects performance too, not just the emulator res. EG, 320x240 at 720p runs noticeably better than 320x240 at 1080p, I suspect even better framerates at 640x480 but my HDTV seems to dislike dropping that low.

@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.
Thanks for your hard work.
eg

quicksilver

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

Also the actual display resolution effects performance too, not just the emulator res. EG, 320x240 at 720p runs noticeably better than 320x240 at 1080p, I suspect even better framerates at 640x480 but my HDTV seems to dislike dropping that low.

You can actually do this to increase performance for the standalone mupen64plus core as well. As I understand it youre essentially passing off the upscaling to your tv as opposed to having your pi do it. I had read somewhere that the upscaling that the pi performs is supposed to be "free" but there is definitely a performance hit for having the pis video mode on 1080p for the more demanding emulators.

dc.all

@quicksilver Is that so? Thanks for adding this information. I recall trying this with stand alone, back when I was trying so desperately to have useable N64 on the Pi, but I didn't notice any difference. Perhaps the games were running so badly there was no hope to begin with lol.

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.