lr-mupen64plus-next: experimental scriptmodule for testing

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.

dc.all

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

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.

The core saves my settings fine, sorry if I worded that in a confusing way, but I was asking if changes could be instantaneous like they are in cores for other systems. currently I have to relaunch a game for any changes to take effect, making troubleshooting tediously slow.

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

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.

This makes sense. I figured though when it comes to graphical errors knowing which core suffers the issue might help locate the problem. but I'm no programmer.
Whenever I'd try to use the old lr-Mupen, the performance was so bad I'd immediately go back to stand alone mupen.
so you've already gone well beyond that one. congrats and good luck on the development.
well done to both you and m4xw.

quicksilver

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

The core saves my settings fine, sorry if I worded that in a confusing way, but I was asking if changes could be instantaneous like they are in cores for other systems. currently I have to relaunch a game for any changes to take effect, making troubleshooting tediously slow.

Ah yes, I reread your previous comment and I now understand what you were asking. Sorry!

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+