lr-mupen64plus-next: experimental scriptmodule for testing
-
@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-next
core 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 RDRAM
option 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=gnu11
flag?
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?
-
@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
-
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!
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.