lr-mupen64plus-next: experimental scriptmodule for testing

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

quicksilver

@hhromic so was testing out Mario tennis, game is playable using the old lr-mupen64plus but game goes to a black screen and freezes with lr-mupen64plus-next. Had to ssh in and reboot.

Edit: found a game that lr-mupen64plus-next is better at running: Nascar 99. Lr-mupen64plus just goes to a black screen and fails to launch the game. Standalone mupen64plus+gliden64 will load the game but the title screen is black and the game froze on on me about 5 secs into a race.

saccublenda

Hello,
I've noticed that after 15 minutes or so the emulator starts glitching and then it crashes.
Anyone else has this problem?

quicksilver

@saccublenda very likely due to the fact that it's using a older version of gliden64 for video. Older versions of gliden64 have issues on raspberry pis when framebuffer emulation is enabled. Try turning framebuffer emulation off. Though some effects may not render properly.

saccublenda

@quicksilver I tried disabling the framebuffer emulation, but the problem remains. Does this bug also occur in older versions of the standalone mupen64plus that used the same version of gliden64 that is in lr-mupen64plus-next?

quicksilver

@saccublenda it has been an issue with gliden64 on the pi for a while now and was only just recently resolved (inadvertently I might add). The issue only occurred when frame buffer emulation was enabled and only in standalone mupen64plus. The bug didn't occur in lr-mupen64plus.

saccublenda

@quicksilver Ok, I will try to replicate the crash in lr-mupen64plus.

Heartless

Any Update or news from this emulator?
Its been a while since this post lacks any new feature or announcements

saccublenda

@Heartless I had some interactions with the developers on GitHub about the 15 minutes crash. It turned out to be related to texture cache size which was too big (15000) by default.
m4xw and hhromic prepared a new build with an extra core option that allows the user to set it to 1500, 4000 or 8000, and this fixed the bug for me. The new build can be installed by re-installing lr-mupen64plus-next form source through the RetroPie scriptmodule.

hooperre

Appears it’s now finished, ya?

https://www.bountysource.com/issues/60020750-update-m64p-gliden64-and-or-parallel-gliden64-to-latest-build?utm_source=share&utm_medium=ios_app

hhromic

@hooperre I tried to build it for RPI3 last night and still has some build issues.
So for now is not yet ready on the RPI unfortunately. I hope to be debugging the build soon but I'm currently busy with other things at the moment :(

quicksilver

@hhromic Yea I tried updating as well but it looks like Im still on a build from about a month ago.

xadox

@quicksilver The same goes for me. Yesterday I was able to build it and today it can't be updated anymore and aborts with several bugs.