libretro/mupen64plus-libretro-nx

Improved mupen64plus libretro core reimplementation

Mupen64Plus-Next

Mupen64Plus-Next is a N64 emulation library for the libretro API, based on Mupen64Plus (see below).

It is also the successor of the old Mupen64Plus libretro core.

You can always rely on it to give you an excellent Majora's Mask experience. Seriously.

How is this different from any N64 libretro-core, ever?

Due to the amount of libraries that are used and are in regular need of maintenance, I have strict rules about adding dependencies.
This allows for easy maintenance, so available time can be spent on useful improvements and lowers the burden.
By default the experience will be very simliar to the N64 emulators you know and love with a lot extra.

Sidenote:
While I accept pretty much every reasonable contribution, hacks must not impact behavior by default, unless justified.
If you need to add a dependency, please consult me first.
Force-pushes on all branches but develop and master are fair game. master has the best stability memes, if that's your thing.

Used Technologies

The following projects have been incorporated into this repository:

• mupen64plus
• GLideN64
• cxd4
• parallel-rsp
• angrylion-rdp-plus (Currently based on it's ParaLLel variant)

Acknowledgments

A special thanks to:

• The Mupen64Plus Team, especially Gillou68310
• gonetz and those that have worked on GLideN64, especially fzurita
• The Authors of cxd4 and angrylion-rdp-plus (ata4)
• themaister for parallel-rsp and parallel-rdp (including the Vulkan integration)
• Everyone in the libretro Team

- m4xw

mupen64plus-libretro-nx's Issues

Controllers buttons doesn't work in core

When load a game, only the analogs works, all the rest simply doesn't work, but when in retroarch menu, it's work perfectly

Turok - Defect controller pak

If you start turok, a pop up shows up with the message that the controller pak is damaged. This is not happening in stand alone.

Issue with rom native resolution switch

If the video resolution is changed to high, the game is not shown in full screen, leaving black borders on the right and below

Fix main deinit/return conditions, co_switch shenannigans.

libretro/paraLLeXT@6f0fa02
Not really relevant yet, but needs to be fixed regardless.

Softpatching for Nintendo 64 games

Feature to enable libretro‘s softpatching capabilities.

[Known HLE-RSP Upstream Issue] Pokemon puzzle league (Pal) does not boot

Tried to start pokemon puzzle league, but it always results in a black screen during boot

Core runs slow, issue forcibly closed as "spam" for valid issue

It's just slow, period. I have not the best CPU, a quad core AMD 2.4GHz, and it runs unplayably slow at a few frames per second; however, running plain (standalone) mupen64plus with the Glide64 plugin on the exact same machine runs perfectly. Something is wrong with your implementation here, or with RetroArch in general, yet RA seems to run every other core at least somewhat equivalent to standalone emulators, and runs N64 via parallel just fine.

Originally posted by @DoktorSeven in #12 (comment)

Closing this as "spam" and removing the ability to post new replies? That's a terrible way to respond to people. Though, what do I expect from the greater libretro community and their half-assed, slapped together from random bits and pieces "emulator"? I know that sounds trollish, but honestly, every time I deal with issues with this emulator, that's the attitude I get. Might want to adjust that.

Long loading times before content starts for some Platforms

I am currently testing this core out with the latest code from the GLideN64 branch and I'm noticing really long loading times when starting any content.
I am not sure if such a delay is normal compared to most other cores which are usually instant, but with this one on my system I am having 1-2 minutes of waiting time after selecting 'Run' before the content actually starts.
This is happening with my usual RA config file as well as with a fresh new one.

Future maintainability

What is the plan to keep this updated? Won't the exact same thing happen again, if some big update comes to Mupen64Plus or GLideN64, someone is going to have to go through all this work over again, no?

Cg shaders causing black screen

With the latest code from the GLideN64 branch, setting up any Cg shader preset causes the core to run with a black screen.
Content runs normally and audio can be heard without any issue, but the only way to get the video back is to switch to a GLSL / slang shader or disable them.

Update GlideN64

Add LLE RSP

Black Screen - Linux

I suspect that the GL version is not being detected correctly. Running retroarch, mupen64plus-libretro-nx (branch GLideN64) and Mario 64 I get blackscreen with sound and no errors in the terminal. It shows:

[INFO] [GL]: Vendor: Intel Open Source Technology Center, Renderer: Mesa DRI Intel(R) Ivybridge Desktop .
[INFO] [GL]: Version: 3.0 Mesa 18.2.8.

Core was compiled with default flags, just with "make" and copying the core to /usr/lib64/libretro. Default mupen64plus-libretro detects the version correctly:

[INFO] [GL]: Vendor: Intel Open Source Technology Center, Renderer: Mesa DRI Intel(R) Ivybridge Desktop .
[INFO] [GL]: Version: 4.2 (Core Profile) Mesa 18.2.8.

[META] Updated GLideN64 Issues

Meta Thread regarding new GLideN64 Issues.
Please confirm that bugs don't happen with standalone before reporting them here.
No support requests

Fix other Platforms

Functional:

• Libnx Target
• Android aarch64/armv7 Target
• Windows x64/x86
• Raspberry aarch32/armv7
• Linux x86/x64, arm7neonhf

Notes:
Some changes for awk are needed across all platforms and Android doesn't generate the header properly yet (works if pre generated)
These could be generated and committed, but this might cause Issues with different toolchain versions being used.

"mupen_next" is our master branch for the time being

[More infos added later on...]

[GLideN64] Change Overscan scaling

Right now, using the menu to set the offsets will change it for all games. The correct way would be storing these variables for each game separately, as they have different offset values.

Also, changing them by 1 instead of multiples of 5 would be ideal.

Thanks

Fix scissoring

The current core does glScissor once and then does glEnable(GL_SCISSOR_TEST) and glDisable(GL_SCISSOR_TEST) when needed, without resetting the scissor rectangle with glScissor.

This results in issues if the frontend uses scissoring (which is the case) - when opening and closing the frontend menu (which resets glScissor), the core will enable the scissoring test with a leftover rectangle from the frontend, creating black bars hiding the game viewport.

I found a workaround in the frontend : if I set the scissoring rectangle to the whole viewport when disabling the test, it doesn't hide the game anymore when going back to the core. However, it's still wrong, as the rectangle is still different from the one mupen set in the first place (it's too large). It may result in artifacts if the core draws things in an area expected to be scissored out, or if it doesn't clear those areas properly between frames.

[Android] Crash when using the volume buttons early

Retroarch x64 on Samsung Galaxy Note 9.
I updated the core today, and the game seems to work fine, but when you press one of the volume buttons Retroarch crashes. Doesn't happen on other cores.
I can send logs if someone tells me how to create them.

Lots of compilation errors on musl

This currently fails to compile hard on Musl systems like Alpine Linux.

build-error.log

[Android] Lots of titles crash with a gamepad attatched.

Most games I have crash, with the only common thread being that my controller is being used. The only games I've been able to boot so far are Banjo-Kazooie and Super Mario 64.

I'm running this on Android, and during this time I have a controller and keyboard recognized at once. With only the keyboard all works fine.

Core options prefix

I noticed that this core is using the same core options prefix than the older/regular mupen64plus-libretro core. I know this core is supposed to eventually replace the older one, but it is possible that in the meantime you differentiate the options? for example by appending nx to the prefix.

This is important to ensure this core plays nicely alongside the older core when both are installed at the same time, a very likely situation given the status of this core as for testing. This is specially important to make sure users don't get confused and are not facing errors because of this core taking options set for the older core.

RE2, depth rendering Issue in GLES2 due to API limitations

In my Mx3-G Box android tv, android 5.1.1 32bits, S192, plus mali 450 with Open Gl 2.0 ES, the scenery gets normal, but the characters are invisible.

Q: Texture transparency in Super Smash Bros on RPI

In Super Smash Bros (USA) I'm observing a texture transparency glitch on Raspberry PI. The texture is the "far away circle" object. See example photo for clarification:

It happens in every part of the game where that circle needs to be displayed, not only in demo mode. More than an issue, this is a question if this is a known glitch in the old 2.x GLideN64 code. Also, this doesn't happen in current Windows build. I tried different core options and none seems to help.

Controller Pak and Rumble Pak switching

The rumble pak had a large number of supported games, and the controller pak likewise had an extensive list of support, with not insignificant crossover.

Many of the games that supported both allowed you to switch them out as needed, such as San Francisco Rush 2049 and Beetle Adventure Racing, so that you could save your progress but also have rumble enabled during a game.

Mupen standalone has the ability to switch them out via button press, and every game I have tested with it so far works like I remember it working on real hardware.

I understand that exposing core options to be toggleable via a button in RetroArch isn't feasible currently, but it would be nice if, upon a game requesting you to insert a controller/rumble pak, that changing the core option would be recognized by the game consistently, especially since the standalone emulator can do so. Currently it isn't.

As a specific example, Beetle Adventure Racing checks for a controller pak after loading, and allows you to insert one both on real hardware and on standalone Mupen, upon doing so it reads the memory and proceeds as normal. Then, before starting a race, the game has a prompt to insert a rumble pak, and if you do then on real hardware and Mupen standalone you will have rumble in game.

This currently does not work in the RetroArch core or NEXT. I am unsure of how difficult this would be to implement, but I do know that, for comparison's sake the PCE Fast core and Beetle PSX both allow you to change controller settings from the core options menu (enabling turbo for PCE and analog for PSX), and in both cases it immediately works.

Custom Robo V2 blighter screen

the screen of custom robo v2(japan) on mupen64plus-next is not correct color. probably the gamma value is wrong.

Version and OS

• RetroArch 1.7.7 stable
• Mupen64Plus-Next 96608ba
• Windows 10 Pro 64bit 1809

Comparison
-Mupen64Plus-Next (Not Correct)

-ParaLLEl (Correct)

Fix savefiles

Fix Cheats

Android armv7 support

I managed now to get the backtrace of the crash in Android armv7.
I'm using RetroArch 1.7.6 downloaded from the Website, and I have a LineageOS 14.1 device (Android 7.1.2) with SELinux set to permissive.

Logcat of the working old mupen64plus core: https://pastebin.com/U8EvPsHF
Logcat of the crashing mupen64plus-next core: https://pastebin.com/JFXdyKky

The two main differences between these logs are:

02-15 14:10:31.320 13327 13327 I Thread-2: type=1400 audit(0.0:1815): avc: denied { read } for name="gpuclk" dev="sysfs" ino=11273 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
02-15 14:10:31.320 13327 13327 I Thread-2: type=1400 audit(0.0:1815): avc: denied { open } for name="gpuclk" dev="sysfs" ino=11273 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
02-15 14:10:31.320 13327 13327 W Thread-2: type=1300 audit(0.0:1815): arch=40000028 syscall=322 per=800008 success=yes exit=49 a0=ffffff9c a1=a757c07a a2=20000 a3=0 items=1 ppid=248 auid=4294967295 uid=10099 gid=10099 euid=10099 suid=10099 fsuid=10099 egid=10099 sgid=10099 fsgid=10099 tty=(none) ses=4294967295 exe="/system/bin/app_process32" subj=u:r:untrusted_app:s0:c512,c768 key=(null)
02-15 14:10:31.320   214   214 W auditd  : type=1307 audit(0.0:1815): cwd="/"
02-15 14:10:31.320   214   214 W auditd  : type=1302 audit(0.0:1815): item=0 name="/sys/class/kgsl/kgsl-3d0/gpuclk" inode=11273 dev=00:0d mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=u:object_r:sysfs:s0
02-15 14:10:31.320   214   214 W auditd  : type=1320 audit(0.0:1815): 
02-15 14:10:31.320 13327 13327 I Thread-2: type=1400 audit(0.0:1816): avc: denied { getattr } for path="/sys/devices/platform/kgsl-3d0.0/kgsl/kgsl-3d0/gpuclk" dev="sysfs" ino=11273 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
02-15 14:10:31.320 13327 13327 W Thread-2: type=1300 audit(0.0:1816): arch=40000028 syscall=197 per=800008 success=yes exit=0 a0=31 a1=ace6bba0 a2=ace6bc30 a3=74f216ec items=0 ppid=248 auid=4294967295 uid=10099 gid=10099 euid=10099 suid=10099 fsuid=10099 egid=10099 sgid=10099 fsgid=10099 tty=(none) ses=4294967295 exe="/system/bin/app_process32" subj=u:r:untrusted_app:s0:c512,c768 key=(null)
02-15 14:10:31.320   214   214 W auditd  : type=1320 audit(0.0:1816): 

--------- beginning of crash
02-15 14:00:50.140 10972 11005 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xb0f5718 in tid 11005 (Thread-2)
02-15 14:00:50.140   215   215 W         : debuggerd: handling request: pid=10972 uid=10099 gid=10099 tid=11005
02-15 14:00:50.183 11132 11132 I debuggerd: type=1400 audit(0.0:1807): avc: denied { read } for name="mupen64plus_next_libretro_android.so" dev="mmcblk0p29" ino=29892 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file permissive=1
02-15 14:00:50.183 11132 11132 I debuggerd: type=1400 audit(0.0:1807): avc: denied { open } for name="mupen64plus_next_libretro_android.so" dev="mmcblk0p29" ino=29892 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file permissive=1
02-15 14:00:50.183 11132 11132 W debuggerd: type=1300 audit(0.0:1807): arch=40000028 syscall=322 per=800008 success=yes exit=9 a0=ffffff9c a1=b6a20000 a2=20000 a3=0 items=1 ppid=215 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 exe="/system/bin/debuggerd" subj=u:r:debuggerd:s0 key=(null)
02-15 14:00:50.183   214   214 W auditd  : type=1307 audit(0.0:1807): cwd="/"
02-15 14:00:50.183   214   214 W auditd  : type=1302 audit(0.0:1807): item=0 name="/data/data/com.retroarch/cores/mupen64plus_next_libretro_android.so" inode=29892 dev=b3:1d mode=0100600 ouid=10099 ogid=10099 rdev=00:00 obj=u:object_r:app_data_file:s0:c512,c768
02-15 14:00:50.183   214   214 W auditd  : type=1320 audit(0.0:1807): 
02-15 14:00:50.183 11132 11132 I debuggerd: type=1400 audit(0.0:1808): avc: denied { getattr } for path="/data/data/com.retroarch/cores/mupen64plus_next_libretro_android.so" dev="mmcblk0p29" ino=29892 scontext=u:r:debuggerd:s0 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file permissive=1
02-15 14:00:50.183 11132 11132 W debuggerd: type=1300 audit(0.0:1808): arch=40000028 syscall=197 per=800008 success=yes exit=0 a0=9 a1=be80e860 a2=9a8545a9 a3=0 items=0 ppid=215 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 exe="/system/bin/debuggerd" subj=u:r:debuggerd:s0 key=(null)
02-15 14:00:50.183   214   214 W auditd  : type=1320 audit(0.0:1808): 
02-15 14:00:50.220 10972 11005 F libc    : failed to resend signal during crash: Operation not permitted
02-15 14:00:50.241   607 21064 I WindowManager: WIN DEATH: Window{7c79ee9 u0 com.retroarch/com.retroarch.browser.retroactivity.RetroActivityFuture}
02-15 14:00:50.241   607  1054 I ActivityManager: Process com.retroarch (pid 10972) has died
02-15 14:00:50.241   607  1054 D ActivityManager: cleanUpApplicationRecord -- 10972
02-15 14:00:50.242   607  1054 W ActivityManager: Force removing ActivityRecord{4e65e7d u0 com.retroarch/.browser.retroactivity.RetroActivityFuture t14770}: app died, no saved state
02-15 14:00:50.270 11132 11132 E DEBUG   : unexpected waitpid response: n=11005, status=00000000
02-15 14:00:50.270 11132 11132 E         : debuggerd: timed out waiting for signal
02-15 14:00:50.270   607   776 W NativeCrashListener: Couldn't find ProcessRecord for pid 10972
02-15 14:00:50.270 11132 11132 E         : debuggerd: ptrace detach from 11005 failed: No such process
02-15 14:00:50.271 11132 11132 E         : debuggerd: failed to kill process 10972: No such process
02-15 14:00:50.274   607   626 I BootReceiver: Copying /data/tombstones/tombstone_06 to DropBox (SYSTEM_TOMBSTONE)
02-15 14:00:50.275   215   215 W         : debuggerd: resuming target 10972
02-15 14:00:50.275   215   215 E         : debuggerd: failed to send signal 18 to target: No such process
02-15 14:00:50.319  1680  1758 I Adreno-EGL: <qeglDrvAPI_eglInitialize:379>: QUALCOMM Build: 10/21/15, 369a2ea, I96aee987eb
02-15 14:00:50.320  1680  1758 I OpenGLRenderer: Initialized EGL, version 1.4
02-15 14:00:50.320  1680  1758 D OpenGLRenderer: Swap behavior 1

It seems like a permission issue (?) when trying to directly access hardware from an untrusted app. Apparently the old mupen64plus build is not doing this but the new next core is. Maybe something new in GLideN64? I will give more info when I find it.

Option to disable filtering

Games like yoshis story or mischief makers are 2D games.
Unfortunately those games are affected by the bilinear or 3-point filtering.
With the filtering, upscale shaders like scalefx looks very blurry.
Therefore the possibility to deactivate the filtering to have the pixel graphics would be beneficial to use shaders without limitations

[RPI] Can see through walls in Zelda OoT

RetroArch 1.7.6
Mupen64Plus-Next 96608ba
RetroPie 3B
I'm playing Zelda OoT, and I've noticed that some texture elements (water, roads, vines, etc.) are visible through walls and floors, and they actually appear on top of everything, Link included.
Is this a bug, or there is a specific setting that can fix this?
Thanks.

Native resolution option

First off, awesome work! This is a big improvement over the previous Mupen64Plus core. If it matters, I'm using the build from https://m4xw.net/nextcloud/index.php/s/ASMiAmQBPnP8D3w

Gauntlet Legends boots up and plays mostly ok. However, the text is very blurry (even unreadable in some cases). I compared it to Angrylion which looks perfect (alas, it's too slow on my machine). Comparison below, same shader for both. Yes they're taken with my phone :) was faster than getting a proper screenshot.

Mupen64Plus Next (all default settings):

Parallel N64 (with Angrylion):

I eventually determined this is because the resolution is set to 320x240. However, setting the resolution to the next level up, 640x480, isn't quite right either. It appears this game runs at 640x240 (at least, that what is with Angylion, and that looks right to me). The vertical resolution does matter since it greatly affects the look of scanlines from the shader. Also according to https://nintendo.fandom.com/wiki/Nintendo_64_Expansion_Pak, it would appear there are a wide variety of resolutions between 320x240 and 640x480 that are used. Ideally there should be a "native resolution" option in addition to the fixed resolution options. However, if it's easier to implement, a reasonable partial solution would be a "320x240 with high-res" (maybe you could come up with a better name) option. That would be 320x240 for most games, but would switch to 640x480 for games that use any higher resolution.

C Buttons Mode

Hi there,

RetroArena is testing this core on an Odroid XU4. It runs really well on our build. I do have a suggestion.

When playing games like Killer Instinct, I have to hold the C Buttons mode button in order to use the other 2 buttons.

I'd like to suggest, as a Core Option, to be able to fully toggle the C buttons instead of using a hotkey.

Thanks for all your work.

[Libnx] Cleanup and merge JIT branch

-Only enable dynarec if OFW >= 4.0

Can't open N64 ROMs

Excited to see that someone is working on an updated Mupen64Plus core!

I downloaded the latest version of this core ("Mupen64Plus-Next OpenGL 1.0 1c2029a) in Retroarch. When I try to open an N64 ROM, it only allows for other N64 emulators (Parallel N64, old Mupen64Plus), but not this one. If it matters, these ROMs are in z64 format.

Fix dynamic recompilers / awk

Mario kart n64 emulation: emulate screen above the tunnel 1st stage on android shield tv

Hi,
great work thanks.
I was thinking that the tunnel effect will be OK with the new updated glide plugin on latest mupen64next android core but now I only see a static weird picture like this:

Is it possible on android to make this effect works on shield tv with this new core pupen64 next ? Thanks

Crash on core reset from frontend

On Windows and RPI3 platforms (at least), when you try to reset the core from the frontend, i.e. using RetroArch -> Quick Menu -> Reset/Restart, the core and frontend crash.

This is a known issue even in the old mupen64plus libretro core. I'm opening this issue to track the problem and provide more information for debugging.

---

Crashes with CPU types

Dynamic Recompiler
Pure Interpreter

Doesn't crash with CPU types

Cached Interpreter

Crash using Dynamic Recompiler (instrumentalised)

[INFO] Reset.
[libretro INFO] mupen64plus-next: Entering retro_reset()
[libretro INFO] mupen64plus-next: *** M64CMD_RESET ***
*** Entering main_reset(1) ***
*** Entering hard_reset_device() ***
*** Calling call_interrupt_handler(&r4300->cp0, 11) ***
*** Entering call_interrupt_handler(cp0, 11) ***
*** Entering reset_hard_handler() ***
*** Calling poweron_device() ***
[libretro INFO] mupen64plus-next: Initializing 4 RDRAM modules for a total of 8 MB
*** Calling pif_bootrom_hle_execute() ***
*** Calling init_interrupt() ***
*** Calling invalidate_r4300_cached_code() ***
*** Calling generic_jump_to(a4000040) ***

Thread 1 "retroarch" received signal SIGSEGV, Segmentation fault.
0x64999100 in cached_interp_MTC0 () at mupen64plus-core/src/device/r4300/mips_instructions.def:1185
1185        switch(rfs)

GDB stack trace using Dynamic Recompiler

Thread 1 (Thread 0x71b41000 (LWP 11149)):
#0  0x64999100 in cached_interp_MTC0 () at mupen64plus-core/src/device/r4300/mips_instructions.def:1185
        r4300 = 0x6e0f7000 <g_dev>
        cp0_regs = 0x705f8190 <g_dev+38801808>
        cp0_next_interrupt = 0x705f8040 <g_dev+38801472>
        __PRETTY_FUNCTION__ = "cached_interp_MTC0"
#1  0x64a51430 in MTC0_new (copr=13, count=20480, diff=0, pcaddr=-1543503808) at mupen64plus-core/src/device/r4300/new_dynarec/new_dynarec.c:11208
        r4300 = 0x6e0f7000 <g_dev>
#2  0x6e5f8024 in g_dev () from /opt/retropie/libretrocores/lr-mupen64plus-next/mupen64plus_next_libretro.so

Crash using Pure Interpreter (instrumentalised)

[INFO] Reset.
[libretro INFO] mupen64plus-next: Entering retro_reset()
[libretro INFO] mupen64plus-next: *** M64CMD_RESET ***
*** Entering main_reset(1) ***
*** Entering hard_reset_device() ***
*** Calling call_interrupt_handler(&r4300->cp0, 11) ***
*** Entering call_interrupt_handler(cp0, 11) ***
*** Entering reset_hard_handler() ***
*** Calling poweron_device() ***
[libretro INFO] mupen64plus-next: Initializing 4 RDRAM modules for a total of 8 MB
*** Calling pif_bootrom_hle_execute() ***
*** Calling init_interrupt() ***
*** Calling invalidate_r4300_cached_code() ***
*** Calling generic_jump_to(a4000040) ***

Thread 1 "retroarch" received signal SIGSEGV, Segmentation fault.
0x649bbd84 in generic_jump_to (r4300=0x6e0f7000 <g_dev>, address=2751463488) at mupen64plus-core/src/device/r4300/r4300_core.c:413
413             *r4300_pc(r4300) = address;

GDB stack trace using Pure Interpreter

#0  0x649bbd84 in generic_jump_to (r4300=0x6e0f7000 <g_dev>, address=2751463488) at mupen64plus-core/src/device/r4300/r4300_core.c:413
No locals.
#1  0x649a75d0 in reset_hard_handler (opaque=0x6e0f7000 <g_dev>) at mupen64plus-core/src/device/r4300/interrupt.c:497
        dev = 0x6e0f7000 <g_dev>
        r4300 = 0x6e0f7000 <g_dev>
#2  0x649a7688 in call_interrupt_handler (cp0=0x709f86d4 <g_dev+42997460>, index=11) at mupen64plus-core/src/device/r4300/interrupt.c:511
        __PRETTY_FUNCTION__ = "call_interrupt_handler"
        handler = 0x709f8838 <g_dev+42997816>
#3  0x649a7770 in gen_interrupt (r4300=0x6e0f7000 <g_dev>) at mupen64plus-core/src/device/r4300/interrupt.c:540
        cp0_regs = 0x705f8190 <g_dev+38801808>
        cp0_next_interrupt = 0x705f8040 <g_dev+38801472>
#4  0x649ae73c in BEQ (r4300=0x6e0f7000 <g_dev>, op=325058571) at mupen64plus-core/src/device/r4300/mips_instructions.def:897
        take_jump = 0
        jump_target = 2148350228
        link_register = 0x705f8080 <g_dev+38801536>
#5  0x649b9d28 in InterpretOpcode (r4300=0x6e0f7000 <g_dev>) at mupen64plus-core/src/device/r4300/pure_interp.c:393
        op_address = 0x4215a8ec
        op = 325058571
#6  0x649bb1b4 in run_pure_interpreter (r4300=0x6e0f7000 <g_dev>) at mupen64plus-core/src/device/r4300/pure_interp.c:730
No locals.
#7  0x649bb508 in run_r4300 (r4300=0x6e0f7000 <g_dev>) at mupen64plus-core/src/device/r4300/r4300_core.c:137
No locals.
#8  0x64982138 in run_device (dev=0x6e0f7000 <g_dev>) at mupen64plus-core/src/device/device.c:252
No locals.
#9  0x649c4794 in main_run () at mupen64plus-core/src/main/main.c:1259
        i = 5
        k = 2
        rdram_size = 8388608
        count_per_op = 2
        disable_extra_mem = 0
        si_dma_duration = 2304
        no_compiled_jump = 0
        randomize_interrupt = 0
        eep = {data = 0x712bb3b0 <saved_memory> '\377' <repeats 200 times>..., size = 2048, filename = 0x0}
        fla = {data = 0x712e3bb0 <saved_memory+165888> '\377' <repeats 200 times>..., size = 131072, filename = 0x0}
        sra = {data = 0x712dbbb0 <saved_memory+133120> '\377' <repeats 200 times>..., size = 32768, filename = 0x0}
        dd_rom_size = 0
        dd_disk = {data = 0x0, size = 0, filename = 0x0}
        audio_out_backend_libretro = {set_format = 0x64a59470 <set_audio_format_via_libretro>, push_samples = 0x64a59918 <push_audio_samples_via_libretro>}
        control_ids = {0, 1, 2, 3}
        cin_compats = {{control_id = 0, cont = 0x712b9c20 <g_dev+52177952>, tpk = 0x712b9ce0 <g_dev+52178144>, last_input = 0, last_pak_type = 2, main_switch_pak = 0x0,
            pak_switch_delay = 0, gb_switch_delay = 0, gb_cart_switch_enabled = 0}, {control_id = 1, cont = 0x712b9c38 <g_dev+52177976>, tpk = 0x712b9cf4 <g_dev+52178164>,
            last_input = 0, last_pak_type = 1, main_switch_pak = 0x0, pak_switch_delay = 0, gb_switch_delay = 0, gb_cart_switch_enabled = 0}, {control_id = 2,
            cont = 0x712b9c50 <g_dev+52178000>, tpk = 0x712b9d08 <g_dev+52178184>, last_input = 0, last_pak_type = 1, main_switch_pak = 0x0, pak_switch_delay = 0,
            gb_switch_delay = 0, gb_cart_switch_enabled = 0}, {control_id = 3, cont = 0x712b9c68 <g_dev+52178024>, tpk = 0x712b9d1c <g_dev+52178204>, last_input = 0,
            last_pak_type = 1, main_switch_pak = 0x0, pak_switch_delay = 0, gb_switch_delay = 0, gb_cart_switch_enabled = 0}}
        mpk_storages = {{
            data = 0x712bbbb0 <saved_memory+2048> "\201\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\377\377\377\377\005\032_\023", size = 32768, filename = 0x6488b354 "\260\273+q"}, {
            data = 0x712c3bb0 <saved_memory+34816> "\201\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\377\377\377\377\005\032_\023", size = 32768, filename = 0x6488b354 "\260\273+q"}, {
            data = 0x712cbbb0 <saved_memory+67584> "\201\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\377\377\377\377\005\032_\023", size = 32768, filename = 0x6488b354 "\260\273+q"}, {
            data = 0x712d3bb0 <saved_memory+100352> "\201\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\377\377\377\377\005\032_\023", size = 32768, filename = 0x6488b354 "\260\273+q"}}
        mpk = {
          data = 0x712bbbb0 <saved_memory+2048> "\201\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\377\377\377\377\005\032_\023", size = 131072, filename = 0x0}
        gbcam_backend = 0x0
        igbcam_backend = 0x0
        flashram_type = 12714014
        dd_rtc_iclock = 0x0
        dd_idisk = 0x0
        joybus_devices = {0x712b9c20 <g_dev+52177952>, 0x712b9c38 <g_dev+52177976>, 0x712b9c50 <g_dev+52178000>, 0x712b9c68 <g_dev+52178024>, 0x712b9f90 <g_dev+52178832>}
        ijoybus_devices = {0x64aa9d1c <g_ijoybus_device_controller>, 0x64aa9d1c <g_ijoybus_device_controller>, 0x64aa9d1c <g_ijoybus_device_controller>,
          0x64aa9d1c <g_ijoybus_device_controller>, 0x64aa9cf8 <g_ijoybus_device_cart>}
#10 0x6497a0b4 in CoreDoCommand (Command=M64CMD_EXECUTE, ParamInt=0, ParamPtr=0x0) at mupen64plus-core/src/api/frontend.c:176
        rval = M64ERR_SUCCESS
        keysym = 0
        keymod = 0
#11 0x64a53098 in EmuThreadFunction () at libretro/libretro.c:322
No locals.
#12 0x64a7518c in co_switch (handle=<error reading variable: Cannot access memory at address 0xfffffff0>) at libretro-common/libco/armeabi.c:101
        co_previous_handle = <error reading variable co_previous_handle (Cannot access memory at address 0xfffffff8)>

low performance on extremely low end hw

It's not some little lag it's more like number of static pictures which change from time to time.
My hardware is pretty old, but it can run GLideN64 plugin in standalone mupen64plus.
Same problem I experience on this https://github.com/libretro/mupen64plus-libretro core, while parallel core runs well (except angrylion plugin, but it's still playable).

CPU:       Topology: Quad Core model: AMD Athlon X4 750K bits: 64 type: MCP arch: Piledriver rev: 1
           L2 cache: 2048 KiB
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 27157
           Speed: 2499 MHz min/max: 1400/3400 MHz Core speeds (MHz): 1: 2774 2: 3368 3: 2271 4: 2251
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Cape Verde PRO [Radeon HD 7750/8740 / R7 250E]
           vendor: PC Partner Limited driver: radeon v: kernel bus ID: 01:00.0
           Display: wayland server: X.Org 1.20.4 driver: radeon resolution: 1920x1080~60Hz
           OpenGL: renderer: AMD VERDE (DRM 2.50.0 5.0.0-arch1-1-ARCH LLVM 7.0.1) v: 4.5 Mesa 18.3.4
           direct render: Yes

Add support for bsOnColorImageChange bufferswap mode

When using this core, DOOM 64 has sound issues when you are in-game (crackling/popping).

In the other cores (older Mupen and ParaLLel) the sound is clean and the same applies with the standalone.

Tried disabling anything that could slow down emulation (like GPU sync) but the crackling doesn't stop.

Core runs slow on Low end Hardware.

This core needs some optomization to run on low end Intel Atom hardware. I use -mtune=atom. It is still slightly too slow in places to run full speed. (Tested with Super Mario 64)

Fix Savestates

Input poll behaviour issues

Seems currently it only works with poll behaviour: early or late, according to some reports

Shader cache is crashing on RPI

At the moment, when the option EnableShadersStorage is set to True the core crashes when you launch the same game a second time. In other words, when a game already has a cache entry.

---

#0  0x6864a310 in CombinerKey::CombinerKey(CombinerKey const&) () from /opt/retropie/libretrocores/lr-mupen64plus-next/mupen64plus_next_libretro.so
No symbol table info available.
#1  0x6864a0e4 in std::_Rb_tree_iterator<std::pair<CombinerKey const, graphics::CombinerProgram*> > std::_Rb_tree<CombinerKey, std::pair<CombinerKey const, graphics::CombinerProgram*>, std::_Select1st<std::pair<CombinerKey const, graphics::CombinerProgram*> >, std::less<CombinerKey>, std::allocator<std::pair<CombinerKey const, graphics::CombinerProgram*> > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<CombinerKey const&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<CombinerKey const, graphics::CombinerProgram*> >, std::piecewise_construct_t const&, std::tuple<CombinerKey const&>&&, std::tuple<>&&) ()
   from /opt/retropie/libretrocores/lr-mupen64plus-next/mupen64plus_next_libretro.so
No symbol table info available.
#2  0x686c780c in glsl::ShaderStorage::_loadFromCombinerKeys(std::map<CombinerKey, graphics::CombinerProgram*, std::less<CombinerKey>, std::allocator<std::pair<CombinerKey const, graphics::CombinerProgram*> > >&) () from /opt/retropie/libretrocores/lr-mupen64plus-next/mupen64plus_next_libretro.so
No symbol table info available.
#3  0x686c7bb0 in glsl::ShaderStorage::loadShadersStorage(std::map<CombinerKey, graphics::CombinerProgram*, std::less<CombinerKey>, std::allocator<std::pair<CombinerKey const, graphics::CombinerProgram*> > >&) () from /opt/retropie/libretrocores/lr-mupen64plus-next/mupen64plus_next_libretro.so
No symbol table info available.
#4  0x686a3df4 in opengl::ContextImpl::loadShadersStorage(std::map<CombinerKey, graphics::CombinerProgram*, std::less<CombinerKey>, std::allocator<std::pair<CombinerKey const, graphics::CombinerProgram*> > >&) () from /opt/retropie/libretrocores/lr-mupen64plus-next/mupen64plus_next_libretro.so
No symbol table info available.
(...)

Building current GLideN64 branch fails on RPI3

The core is not currently building on RPI3. I'm opening this ticket to log the build error for discussion.

The failing compilation unit is GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp.

---

$ make -j2 platform=rpi3
(...)
g++  -O2 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -fvisibility-inlines-hidden -std=gnu++11 -O2 -DNDEBUG -fsigned-char -ffast-math -fno-strict-aliasing -fomit-frame-pointer -fvisibility=hidden  -DGIT_VERSION=\"" 9b1fd9e"\" -DOS_LINUX -I./mupen64plus-core/subprojects/md5 -I./mupen64plus-core/subprojects/minizip -I./mupen64plus-core/subprojects/xxhash -DHAVE_NEON -D__ARM_NEON__ -D__NEON_OPT -ftree-vectorize -mvectorize-with-neon-quad -ftree-vectorizer-verbose=2 -funsafe-math-optimizations -fno-finite-math-only -D__LIBRETRO__ -DUSE_FILE32API -DM64P_PLUGIN_API -DM64P_CORE_PROTOTYPES -D_ENDUSER_RELEASE -DSINC_LOWER_QUALITY -DTXFILTER_LIB -D__VEC4_OPT -DMUPENPLUSAPI  -I/opt/vc/include -I/opt/vc/include/interface/vcos -I/opt/vc/include/interface/vcos/pthreads -I./custom -I./custom/mupen64plus-core -I./custom/android/include -I./custom/GLideN64 -I./GLideN64/src -I./GLideN64/src/osal -I./mupen64plus-core/src -I./mupen64plus-core/src/api -I./custom/mupen64plus-core/plugin/audio_libretro -I./libretro-common/include -I./libretro -I./GLideN64/src/inc -I./xxHash  -fPIC  -DVC -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard  -DEGL -DHAVE_OPENGLES -DHAVE_OPENGLES2 -DGLES2  -DNEW_DYNAREC=3 -DDYNAREC -I./mupen64plus-core/src/asm_defines/ -c GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp -o GLideN64/src/Graphics/OpenGLContext/GLFunctions.o
In file included from GLideN64/src/Graphics/OpenGLContext/GLFunctions.h:11:0,
                 from GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:6:
./GLideN64/src/inc/GL/glcorearb.h:199:0: warning: "GL_FALSE" redefined
 #define GL_FALSE                          0

In file included from ./libretro-common/include/glsym/rglgen_headers.h:61:0,
                 from ./libretro-common/include/glsm/glsm.h:30,
                 from ./libretro-common/include/glsm/glsmsym.h:26,
                 from GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:2:
/opt/vc/include/GLES2/gl2.h:78:0: note: this is the location of the previous definition
 #define GL_FALSE                          (GLboolean)0

In file included from GLideN64/src/Graphics/OpenGLContext/GLFunctions.h:11:0,
                 from GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:6:
./GLideN64/src/inc/GL/glcorearb.h:200:0: warning: "GL_TRUE" redefined
 #define GL_TRUE                           1

In file included from ./libretro-common/include/glsym/rglgen_headers.h:61:0,
                 from ./libretro-common/include/glsm/glsm.h:30,
                 from ./libretro-common/include/glsm/glsmsym.h:26,
                 from GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:2:
/opt/vc/include/GLES2/gl2.h:79:0: note: this is the location of the previous definition
 #define GL_TRUE                           (GLboolean)1

In file included from GLideN64/src/Graphics/OpenGLContext/GLFunctions.cpp:2:0:
./libretro-common/include/glsm/glsmsym.h:94:48: error: variable or field ‘rglDisable’ declared void
 #define glDisable(T)                rglDisable(S##T)
                                                ^
./GLideN64/src/inc/GL/glcorearb.h:162:21: note: in expansion of macro ‘glDisable’
 GLAPI void APIENTRY glDisable (GLenum cap);
                     ^~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:94:48: error: ‘SGLenum’ was not declared in this scope
 #define glDisable(T)                rglDisable(S##T)
                                                ^
./GLideN64/src/inc/GL/glcorearb.h:162:21: note: in expansion of macro ‘glDisable’
 GLAPI void APIENTRY glDisable (GLenum cap);
                     ^~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:95:47: error: variable or field ‘rglEnable’ declared void
 #define glEnable(T)                 rglEnable(S##T)
                                               ^
./GLideN64/src/inc/GL/glcorearb.h:163:21: note: in expansion of macro ‘glEnable’
 GLAPI void APIENTRY glEnable (GLenum cap);
                     ^~~~~~~~
./libretro-common/include/glsm/glsmsym.h:95:47: error: ‘SGLenum’ was not declared in this scope
 #define glEnable(T)                 rglEnable(S##T)
                                               ^
./GLideN64/src/inc/GL/glcorearb.h:163:21: note: in expansion of macro ‘glEnable’
 GLAPI void APIENTRY glEnable (GLenum cap);
                     ^~~~~~~~
./libretro-common/include/glsm/glsmsym.h:96:50: warning: ‘rglIsEnabled’ initialized and declared ‘extern’
 #define glIsEnabled(T)              rglIsEnabled(S##T)
                                                  ^
./GLideN64/src/inc/GL/glcorearb.h:186:26: note: in expansion of macro ‘glIsEnabled’
 GLAPI GLboolean APIENTRY glIsEnabled (GLenum cap);
                          ^~~~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:96:50: error: ‘GLboolean rglIsEnabled’ redeclared as different kind of symbol
 #define glIsEnabled(T)              rglIsEnabled(S##T)
                                                  ^
./GLideN64/src/inc/GL/glcorearb.h:186:26: note: in expansion of macro ‘glIsEnabled’
 GLAPI GLboolean APIENTRY glIsEnabled (GLenum cap);
                          ^~~~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:333:11: note: previous declaration ‘GLboolean rglIsEnabled(GLenum)’
 GLboolean rglIsEnabled(GLenum cap);
           ^~~~~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:96:50: error: ‘SGLenum’ was not declared in this scope
 #define glIsEnabled(T)              rglIsEnabled(S##T)
                                                  ^
./GLideN64/src/inc/GL/glcorearb.h:186:26: note: in expansion of macro ‘glIsEnabled’
 GLAPI GLboolean APIENTRY glIsEnabled (GLenum cap);
                          ^~~~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:67:37: error: conflicting declaration of C function ‘void rglDeleteRenderbuffers(GLsizei, const GLuint* ’
 #define glDeleteRenderbuffers       rglDeleteRenderbuffers
                                     ^
./GLideN64/src/inc/GL/glcorearb.h:1378:21: note: in expansion of macro ‘glDeleteRenderbuffers’
 GLAPI void APIENTRY glDeleteRenderbuffers (GLsizei n, const GLuint *renderbuffers);
                     ^~~~~~~~~~~~~~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:274:6: note: previous declaration ‘void rglDeleteRenderbuffers(GLsizei, GLuint*)’
 void rglDeleteRenderbuffers(GLsizei n, GLuint *renderbuffers);
      ^~~~~~~~~~~~~~~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:184:37: error: conflicting declaration of C function ‘void rglDrawElementsBaseVertex(GLenum, GLsizei, GLenum, const void*, GLint)’
 #define glDrawElementsBaseVertex    rglDrawElementsBaseVertex
                                     ^
./GLideN64/src/inc/GL/glcorearb.h:1622:21: note: in expansion of macro ‘glDrawElementsBaseVertex’
 GLAPI void APIENTRY glDrawElementsBaseVertex (GLenum mode, GLsizei count, GLenum type, const void *indices, GLint basevertex);
                     ^~~~~~~~~~~~~~~~~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:455:6: note: previous declaration ‘void rglDrawElementsBaseVertex(GLenum, GLsizei, GLenum, GLvoid*, GLint)’
 void rglDrawElementsBaseVertex(GLenum mode, GLsizei count, GLenum type,
      ^~~~~~~~~~~~~~~~~~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:178:37: error: conflicting declaration of C function ‘void rglWaitSync(GLsync, GLbitfield, GLuint64)’
 #define glWaitSync                  rglWaitSync
                                     ^
./GLideN64/src/inc/GL/glcorearb.h:1631:21: note: in expansion of macro ‘glWaitSync’
 GLAPI void APIENTRY glWaitSync (GLsync sync, GLbitfield flags, GLuint64 timeout);
                     ^~~~~~~~~~
./libretro-common/include/glsm/glsmsym.h:451:6: note: previous declaration ‘void rglWaitSync(void*, GLbitfield, uint64_t)’
 void rglWaitSync(void *sync, GLbitfield flags, uint64_t timeout);
      ^~~~~~~~~~~

[ALL] Zelda OoT/Majoras random freezing (+ potential pause menu fb corruption.)

Platform - Windows 10
Version - 1.7.6
Rom - Zelda Ocarina of Time (all versions)
CPU - i5-4670k
GPU - GTX 980

Having an issue where the background of the pause menu will get all rainbow colored (see example below). The only solution I was able to find was the old PJ64 gameshark code which doesnt work.

That issue I can live with, however i'm mainly looking for information regarding random freezing I get where the rom will freeze, but the audio will still be playing, and the retroarch menu works fine. Save/load state brings me to a white screen with the same audio playing. These freezes can occur anytime between a few minutes of play, up to about an hour of play. The only lead I found to this issue was a year old post on the mupen64plus-libretro github saying that its related to Delay SI, which wasnt/isnt an option on the libretro cores.

Some games are not recognizing the Game Pad

Some games when I load do not recognize the game pad do not know the reason and after the presentation close the retroarch, the ones I remember head:

Kirby 64
Star Soldier: Vanishing Earth
Super Smash Bros

Adapt configuration logic for the libretro API (Core options)

Currently incomplete.

Instability/Corruption likely related to Texture cache size on low end devices.

Hello,
I've noticed that on RetroPie after 20 minutes or so the emulator starts glitching and then it crashes.
I tried disabling the framebuffer emulation, but the problem remains.

Linux - Rogue Squadron Hang Black Screen

I realise that this is still under heavy development but I just wanted to mention an issue that I have seen on Linux.

I have built from the latest source (Commit : 07f0915) and the core appears to work well for most games (top gear rally is working great and that used to have a terrible stuttering issue) but when I try rogue Squadron it just hangs at a black screen at startup.

The UI and everything works so it hasn't frozen, it just seems to halt the emulation?

Is there any debug or anything that I can enable to provide any further information to yourself?

[libretro INFO] mupen64plus: Goodname: Star Wars - Rogue Squadron (U) (M3) (V1.0) [!]
[libretro INFO] mupen64plus: Name: Rogue Squadron
[libretro INFO] mupen64plus: MD5: 47CAC4E2A6309458342F21A9018FFBF0
[libretro INFO] mupen64plus: CRC: 66A24BEC 2EADD94F

Fedora 29 64 bit (KDE)
i7 6700K @ 4.5Ghz
32GB Ram

Rogue Squardron black screen on Intel HD

closed, not a good place to report issues to.