lr-mupen64plus-next: experimental scriptmodule for testing
-
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 -
@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
Thanks for testing and giving the output log. Indeed as @mitu correctly identified, there is a missing
-std=gnu11flag 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-nextis aiming to be as close as possible as the standalone, and surely better than the old core. -
@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).
-
@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.
-
@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.
-
@hhromic Is the non libretro version of the emulator+plugin
-
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 -
@Heartless thanks for the clarificaiton! so you are comparing the new
lr-mupen64plus-nextcore and the standalonemupen64 + 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 RDRAMoption set toAsync? It is supposed to make some games smoother but also may introduce graphical glitches. Looking forward to hear from you.Thanks!
-
@Heartless ah one more thing, what is your setup for your test? are you using a raspberry pi device, if so which one? thanks!
-
@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.
-
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). -
@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.
-
@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. -
@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!
-
This core is awesome on the Nintendo Switch. I'll have to try it out on my RetroPie tonight. Thanks for setting this up.
-
@hhromic Kinda a late response but every game tested comes from the raspberry pi 3 b+
-
@dc-all Hey pretty good testing there. Really appreciated
-
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.
-
@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=gnu11flag?
Thanks! -
@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?
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.