lr-mupen64plus-next: experimental scriptmodule for testing

hhromic

Hi all,
As some of you already know, the lr-mupen64plus libretro core is no longer actively maintained upstream. However, recently a new developer (@m4xw) took the mantle to keep working on it and the new active core is known as lr-mupen64plus-next. More info in the GitHub repository.

Announcement: https://gbatemp.net/threads/retroarch-1-7-6-released.530532/#post-8499706

Introducing Mupen64Plus-Next:
This is the WIP new Mupen core @m4xw has been working on.
It is developed with a close-to-upstream approach, which eases the maintainability
and provides a easier way to update core components.

Some notable changes:
- New Repository approach based on `git subrepo`
- Updated *everything* but GlideN64
- Full feature parity to old Mupen
- Additionally:
- Added LOD Core option
- Added Noise Core option
- Added "Fullspeed" Core option (simliar to ParaLLEl)
- Added VI Refresh Overclock (simliar to ParaLLEl)
- Savestates for Version 1.4
- Added Frame-duping option if Framebuffer Emulation is disabled
- AArch64 Dynamic recompiler (by Gillou68310)
- x64 Dynamic recompiler (by Gillou68310)
Current supported platforms:
- Libnx (buildbot)
- Android AArch64 (buildbot)
- Windows x64 (buildbot)
- Raspberry aarch32/armv7 (via RetroPie)
- Linux x86/x64 (buildbot), arm7neonhf (supported but not active)

What is next?
- Updated GlideN64 (currently runs already, but still many Issues to tackle down)
- Adding Threaded Angrylion (for desktop platforms)

The developer expressed that he would be happy to have RetroPie users test the new core and provide feedback, therefore I created this experimental scriptmodule for installing this new core.

Please Remember: while the new version aims to become faster and more compatible with N64 games than the older core, the limitation of the RPI hardware are still present. Some games seem to run better than before, but some other game will never run as in the original N64 console. Your testing and feedback are a good opportunity for the core to improve where possible.

INSTALLING/UNINSTALLING THE LR-MUPEN64PLUS-NEXT SCRIPTMODULE FOR TESTING

The scriptmodule is now part of official RetroPie. To install or uninstall the lr-mupen64plus-next core, go to the "Manage Packages" section, then to experimental and you will find the lr-mupen64plus-next package there.

USAGE

This core can be used exactly in the same way as the older lr-mupen64plus core. After installation the new lr-mupen64plus-next core is selectable in the runcommand menu when you launch any N64 game from EmulationStation.

CORE OPTIONS

The scriptmodule configures the core options so they are prefixed with mupen64plus-next-* in the retroarch-core-options.cfgfile. In this way, the options set for the newer lr-mupen64plus-next do not clash nor interfere with the options for the older lr-mupen64plus.

If you find a good set of options for particular games, it would be very helpful for the community and future development if you can share these settings in this thread.

quicksilver

@hhromic I very much interested in this! When I have some time I would be glad to test it out and report back!

hhromic

@quicksilver great! this core should be at a minimum like the old one, never worse. However due to the recent updates, it might run some games better than the old one. Looking forward for your feedback!

quicksilver

@hhromic I'm getting a build error. Says it can't find the lr-mupen64plus-next.so file. When I have a sec I'll post the contents of the log.

Edit: Here is the log

https://pastebin.com/CzCiUgfj

mitu

@quicksilver I think the error comes from running on Jessie and the C++ compiler doesn't default to C11.

mupen64plus-core/src/device/r4300/new_dynarec/arm/assem_arm.c:4300:9: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code

You can modify the scriptmodule and add -std=c11 to the build flags, or wait for @hhromic to sort it out.

quicksilver

@mitu Yea I just figured out that was the problem. I really need to to finish migrating to stretch so I can stop running into these issues.

mitu

@quicksilver There's no rush, this should be working on Jessie also.

BuZz

@hhromic thanks for your work on this.

Heartless

Got some good testing for some games for now...

Super Smash Bros: Works fine but standard Mupen64plus+GlideN64 Works better
F-Zero X: Struggles to run fine when a lot of racers are on screen, this doesnt happen on Mupen64plus+GlideN64
Kirby 64: Works very fine with the graphical bug from the Mupen64plus+GlideN64 fixed, for some reason when encountering Waddle Doo it lag a lot but other than that is very good on gameplay
Star Fox 64: Other than the opening scene and map gameplay wise runs very fine, just as good as glesN64
Testing a few more in the next days, some of this games may have changes on performance during development of this core

hhromic

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

@hhromic I'm getting a build error. Says it can't find the lr-mupen64plus-next.so file. When I have a sec I'll post the contents of the log.

Edit: Here is the log

https://pastebin.com/CzCiUgfj

Thanks for testing and giving the output log. Indeed as @mitu correctly identified, there is a missing -std=gnu11 flag in the Makefile. I already filled a PR upstream to fix it now. Hopefuly will get merged soon.

In the meantime, as mitu suggests you can try adding the flag manually in the scriptmodule. For this just replace:

make "${params[@]}"

With:

CFLAGS="$CFLAGS -std=gnu11" make "${params[@]}"

And it should compile. If you aren't in a rush, probably is best to wait for the PR to be merged upstream (I expect this to be soon anyway).

Thanks again for the feedback!

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

@hhromic thanks for your work on this.

My pleasure, happy to contribute. If you are interested on eventually adding this scriptmodule to RetroPie let me know and I will follow it up and submit a PR. This new core is (on paper) at least as good as the old one (is a fork after all) but is actively maintained now, so I would think is a good idea to include it.

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

Got some good testing for some games for now...

Thanks for the great breakdown of games you did! great feedback for the upstream developer. One question: in your comparison are you referring to the standalone "Mupen64Plus+GlideN64" emulator or the old libretro core lr-mupen64plus?

They are not the same and the standalone is probably always going to be slightly better because of not having RetroArch as middle-man. However this new lr-mupen64plus-next is aiming to be as close as possible as the standalone, and surely better than the old core.

quicksilver

@hhromic one thing I am concerned about is as lr-mupen64plus-next gets closer to catching up with the current gliden64 it will start to expose all of the short comings of the raspberry pi gpu. The current lr-mupen64plus in some cases actually runs some games better than the standalone mupen64plus-gliden64 because the lr-mupen64plus core is outdated. For example lr-mupen64plus plays Zelda oot without major issues but the standalone mupen64plus-gliden64 has severe graphical depth issues (this is a problem for multiple games using current gliden64 on the pi). I'm not sure when but there must have been an update to the gliden64 plugin that broke a lot of games on the pi (I'm sure it was good for everyone else though).

BuZz

@quicksilver If/When this is included I am probably going to keep the other one also and have this named -next. Depending on what happens upstream.

hhromic

@quicksilver that's a very good point indeed. Specially because upstream is interested on higher-end hardware as well. I think having the core actively maintaned is a great opportunity to provide RPI-based feedback and keep the core happy with both ends. So the more feedback the better.

In upstream, @m4xw is currently porting gliden64 3.0 to this core in active collaboration with the gliden64 developer. He said very soon he should have it done and ready for more testing. So I guess we'll soon see how updates affect the shortcomings of the RPI GPU in this regard.

@BuZz yes definitively the old core shouldn't be replaced until fully confirmed that any new core is at least equal than the old core. By the way, I already raised the issue of this "next" core having the same core options prefix as I mentioned on the OP. @m4xw said he is aware and will come up with something soon. So hopefully something is cooked soon and both cores can co-exist gracefully.

Heartless

@hhromic Is the non libretro version of the emulator+plugin

Heartless

I did further testing with some games for now
Mario Kart 64: Runs perfectly with no drawbacks from the racers onscreen
Pokemon Stadium: The menus and characters pictures are broken both other than that the in-game is pretty smooth
TLOZ: Ocarina Of Time: Tested on the first zone of the game and works pretty fine, the opening and menu works well but in-game inventory is extremely corrupted, other than that playable.
Banjo Kazooie: Needs further testing, but the initial menus work wonders still.
I also reliaze that i just forgot to decrease resolution so i re tested with the Resolution CEA-1, here some results:
Super Smash Bros 64: Plays just as well as the Standard Mupen64plus+GlideN64
Kirby 64: Plays slightly better than before.
Star Fox 64: No difference in-game
F-Zero X: This one was the most that got so much better with the resolution change, now plays just as well as the standard counterpart.
Some of this games may have changes on performance during development of this core

hhromic

@Heartless thanks for the clarificaiton! so you are comparing the new lr-mupen64plus-next core and the standalone mupen64 + gliden64.

Great that you are reporting how these games actually play beyond just launching them, many users will be happy to have that information. And great it seems the new core is definitively not a step back from the old core.
I'm going to report your finding to the main devleoper upstream as well, he will be happy to hear the good results and maybe he has some suggestions too.

Can I suggest you to also try the Copy color buffer to RDRAM option set to Async ? It is supposed to make some games smoother but also may introduce graphical glitches. Looking forward to hear from you.

Thanks!

hhromic

@Heartless ah one more thing, what is your setup for your test? are you using a raspberry pi device, if so which one? thanks!

quicksilver

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

Can I suggest you to also try the Copy color buffer to RDRAM option set to Async ? It is supposed to make some games smoother but also may introduce graphical glitches.

When you say smoother do you mean the textures will appear smoother or the game will may have better performance?

If you find a good set of options for particular games, it would be very helpful for the community and future development if you can share these settings in this thread.

For the zelda games less accurate blending needs to be false otherwise there are some fairly severe graphical issues such as the fairies look weird and the dust storm before the desert colossus is nearly impossible to see through.

dc.all

I did some testing, Raspberry Pi3 B+ with offical Retropie build, pretty sure it's the latest version.
Also, well I pretty much disable everything Framebuffer related, this is for performance reasons.
for reference, my old core was Mupen with Glide.

Snowboard Kids (U)
With old Mupen and Glide, I used to get sometimes decent speeds with FB disabled. this is not the case with the new plugin.
FPS drops on even the title screen, however no graphic issues were introduced.

Duke Nukem 64 (U)
Any combination of Cores or plugins used to give me varying depth issues with sprites popping behind the geometry. also choppy framerates. Using the new plugin there were no Graphical issues at all, everything rendered correctly.
Also the frame rate has improved incredibly, I saw no noticeable frame drops in the first stage, even in two player splitscreen.
again, lowest res, no frame buffer settings.

Mystical Ninja 2 (PAL)
old core used to give me bad performance. (and HUD graphical issues when I tried to disable framebuffer)
new core gives me much better framerates, only saw subtle slowdowns while in the main town. other stages would probably get worse though. and previously mentioned graphic issue is not there.

GoldenEye 007 (U)
ran awful in old core,
slightly better, but still unplayable in new core.

Space Station: Silicon Valley (U)
Old core ran decent but with depth issues, also garbage graphics would appear over the water surface.
New core has better performance, and before mentioned graphical errors were no longer present.
however, a new graphical error effects all particle effects, looks like they don't have their alphas.

Bomberman 64 (U)
Old core looked fine, however multiplayer used to run in slow motion. ( I think this was VI refresh related though)
new core seems to get better performance, and after changing the VI refresh and gamespeed settings, Battle mode seems to run at the correct speed, however now there seems to be no transparencies on explosions or ghost players.

Mario Tennis (U)
Never tried it with older cores, new core would not boot and actually crash my pi.

that's all I tested tonight, very exciting times, friends.
I hope this information is helpful, I'm sure it'd be better if I was testing with the framebuffer still on, but for me and most other Pi owners, performance is priority.

on a closing note I noticed games took noticeably longer to boot (stuck at the "Press A to configure" screen)
and also was hoping it would be some day possible to have the settings change upon exiting the RA menu,
currently I most close and restart the game for any core settings to take effect, (including analog deadzone).

quicksilver

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

on a closing note I noticed games took noticeably longer to boot (stuck at the "Press A to configure" screen)
and also was hoping it would be some day possible to have the settings change upon exiting the RA menu,
currently I most close and restart the game for any core settings to take effect, (including analog deadzone).

If you make any changes in the RA menu then you need to save a game config and/or controller overrides otherwise it will revert back to default settings when you relaunch the game.

Also I feel that we probably should be comparing this new core vs the old lr-mupen64plus core not the standalone mupen64plus. Otherwise we are not getting an apples to apples comparison.