lr-mupen64plus-next: experimental scriptmodule for testing

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+

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