Input not being recognized for N64 using front end.

[stuffu]

Mupen64 does not record input when using frontend. It does for some games strangely but the majority it doesn’t.

I don’t think this only applies to mupen64, Also tested other N64 emulators with the same result, but mupen64 is the one I would like to use.

Launching a game from within RA, all key presses are fine.

I’m using daijisho on frontend on android in this case but read other posts about people having the same issue with other frontends as well, also with other os.

All other systems works as expected, just N64 that behaves this way and according to issue on daijisho, it’s not related to the frontend itself, but a bug in RA.

[hizzlekizzle]

Do you have a link to the daijisho issue discussing this? it would be nice if they had any hints about what could be going wrong, since it works fine from RetroArch itself.

@jasonunbrokensoftware Do you have this issue on your end?

[stuffu]

Here is the link to the issue, but I have seen it with other frontends as well.

https://github.com/magneticchen/Daijishou/issues/181

[jasonunbrokensoftware]

It doesn't look like there are any issues with controller input when launching games from LaunchBox through the Parallel N64 core. I've been using that for quite a long time, and I just tested it and everything is working fine. So I don't really understand the issue. I know if input was broken for the N64 cores through LaunchBox we'd have tons of reports of issues. Regardless, for what it's worth I've been testing via Bluetooth with an Xbox Series X controller.

[stuffu]

Can I contribute with something to narrow it down?

[hizzlekizzle]

I guess if you could pinpoint which cores exhibit this behavior, we can see if there's a common thread among them.

[jasonunbrokensoftware]

Since I have some experience with strange issues like this between emulators and frontends, I can probably help to narrow it down. First off, this is 99% most likely a quirk with Android on certain devices, or a quirk with the way that Daijisho launches RetroArch. It's extremely unlikely that the RetroArch code is to blame for an issue like this, though it is always possible.

Therefore, some questions that would help to narrow it down:

What specific Android devices are affected? What version of Android are the affected devices running? Are there any Android devices out there that don't have this issue? What specific controllers have been tested? Do any controllers not have this issue? Have both Bluetooth and USB controllers been tested? If testing with an Xbox controller of some kind, has the firmware on the Xbox controller been updated by plugging it into an Xbox?

Per the very last question, I'm reminded that I have seen some weird issues with Xbox controllers that are fixed by updating the firmware on the Xbox controllers. I can't remember if this issue is specific to Xbox One or Xbox Series X controllers, or if it affects both. So it is possible that that is the issue.

[stuffu]

I guess if you could pinpoint which cores exhibit this behavior, we can see if there's a common thread among them.

I have tried mupen64_next_gles2/3 and parallele64 same behavior with either core.

[stuffu]

What specific Android devices are affected?

In my case Retroid Pocket 3+, which is great for handheld gaming. I don’t see any specific devices mentioned in other posts so not sure how widespread it is.

What version of Android are the affected devices running?

Again, in my case Android 11.

What specific controllers have been tested? Do any controllers not have this issue? >Have both Bluetooth and USB controllers been tested?

These devices have built in controls, think Nintendo switch but for retro games. The strange part here is that all other cores work fine, even running dolphin, scummvm point and click, amiga games with mouse input etc.

[stuffu]

I should also mentioned that tried to launch a few games. 007 and super Mario worked as expected, resident evil 2 did not recognize any inputs.

The majority of the games does not recognize input. For reference, I previously had RA on Xbox S with dev mode without any issues and with the same game collection.

[jasonunbrokensoftware]

Okay, I think it has to be assumed that it's an issue with that specific device, at least until someone else comes forward that has run into the same thing on a different device. Unfortunately I don't have any means of testing that without going out and buying that device, so it may be difficult to figure out.

[jasonunbrokensoftware]

I do know that there are quite a few users in the LaunchBox community with that device though, and I have yet to hear of that specific issue (at least that I can remember). So it's still very possible that it's a bug in the Daijisho code, or it could be a bug in the firmware of that device. If you have any other reports of the same issue from any other users, it would be useful to know what device(s) they're using, of course.

[unbelievableflavour]

Hi, as show in the issues above I have the exact same problem. Here is some extra information that might help with the issues.

Steps to reproduce: Launch an instance of mupen using the following config:

-n com.retroarch.aarch64/com.retroarch.browser.retroactivity.RetroActivityFuture
-e ROM /PATH/TO/FILE
-e LIBRETRO /data/data/com.retroarch.aarch64/cores/mupen64plus_next_gles3_libretro_android.so
-e CONFIGFILE /storage/emulated/0/Android/data/com.retroarch.aarch64/files/retroarch.cfg\n  
-e IME com.android.inputmethod.latin/.LatinIME
-e DATADIR /data/data/com.retroarch.aarch64
-e APK /data/app/com.retroarch.aarch64-1/base.apk
-e SDCARD /storage/emulated/0
-e EXTERNAL /storage/emulated/0/Android/data/com.retroarch.aarch64/files
--activity-clear-task
--activity-clear-top

Issue has been confirmed on the following devices:

• OS: Android 11, device: Retroid Pocket 3+
• Retroid Pocket 2+

Important This issue does not happen with every game.

Try one of the following

• Harvest Moon 64(USA)
• Star Wars: Rogue Squadrons(USA)
• Super Smash Bros(USA)
• Tonic Trouble(USA)
• Rakugakids(EU)

Frontends where this happens

• Retroid Launcher
• Daijisho
• Dig
• Launchbox

CANNOT reproduce this on the following device OS: Google Pixel 3A with Xbox controller. works perfectly there. Maybe built in controllers only.

[jasonunbrokensoftware]

Okay, well then assuming that all of @unbelievableflavour 's testing is correct (thank you @unbelievableflavour for all the detailed information), that would mean that the issue is likely specific to Retroid Pocket devices, which means that it's most likely a bug with the Retroid firmware/Android installation. It might be wise to report it to Retroid themselves, as they're the most likely to be able to fix the bug.

There may be a workaround that could be implemented by the RetroArch team, but whoever works on this will definitely need a Retroid Pocket 3+ device on hand, and they may or may not be able to do anything about it, depending on how bad the bug in the firmware actually is.

If anyone finds any other devices that are affected (other than Retroid devices), that may suggest that there is an actual bug in RetroArch and not just the Retroid firmware. But until then, it should probably be assumed that it's a Retroid firmware issue.

[stuffu]

Thanks, I have asked retroid on their discord to look into it.

[unbelievableflavour]

Thanks. Im also still trying to find someone who will test on a device with physical buttons other than retroid. I think we still gotta rule that out.

[stuffu]

I got a reply with a workaround and that the issue has been forwarded to the engineers. The workaround is to do button presses immediately after launching a game. I tried with Resident Evil 2, it works!

[unbelievableflavour]

@stuffu yes. I've listed that workaround here too: https://github.com/libretro/mupen64plus-libretro-nx/issues/485 https://github.com/libretro/parallel-n64/issues/758

What else did the developers say? And by developers you mean Retroid? Will they look into the issue?

[stuffu]

@unbelievableflavour Yes, they said they will look into it, but not sure what that really means...

[unbelievableflavour]

Thanks. I also got a reply from Retroid support: Their exact reply:

"Hi, I have reported this issue to our engineers and they will try their best to improve this issue, maybe the next OTA will fix this issue. There are two temporary solutions to this problem. The first is to quickly press the button after starting the game. The second is to enter the menu through the virtual button of RA after starting the game, and then press the button. Thank you for your support of our products."

[cbrumbau]

What specific Android devices are affected? Odin Pro What version of Android are the affected devices running? 10 What specific controllers have been tested? The built in controller

As such it's more than just Retroid Pocket devices affected by this issue

Just did a quick test using Daijishou and found Kirby 64 had the input issue while Mario Kart 64 was fine

[unbelievableflavour]

@jasonunbrokensoftware Since Odin Pro also has this issue now. It is no longer a Retroid specific issue.

[jasonunbrokensoftware]

Good to know. Unfortunately I don't have either of those devices so I'm not likely to be much help here, but hopefully that will help to narrow it down.

[delta62]

Hi all, reporting in with another handheld that has similar symptoms:

Parameter	What I tested
Device	Odin Lite
Core	Mupen64Plus-Next GLES3, ParaLLEl N64
Frontend	Daijishou 1.4.62 (394), LaunchBox 1.9
Android version	11
Controller	Built-in gamepad, 8BitDo SN30 Pro, Xbox One Controller

In my case, the posted workarounds of either pressing buttons immediately after launching or using the touch screen do not restore functionality of any hardware controls. I can control the game using the on-screen controls, but the built in buttons & controllers only work if I start the game via RA directly.

To be clear, I tested with every combination of frontend + controller above and always had the same results. In my case the game did not appear to make any difference, it never worked. The only way controllers of any kind worked for me were from launching the game within RetroArch. This worked 100% of the time.

I also tested configuring Daijishou and LaunchBox to launch Mupen64 FZ rather than RetroArch, and things work correctly then.

Also, this interestingly only effects the N64 cores as far as I can tell. I also tested SNES and GBA and both worked fine with each frontend & hardware controller, with the frontend launching RA.

[loki666]

I had the same issue with my Backbone One. I changed input polling to Early.

No issues anymore.

[edbanshee]

I'm having the same problem. I'm on Retroarch Nightly 1.16.0 Device: Poco X3 Pro, Android 13. My gamepad is BSP-3, tried different input modes and none of them work. Daijisho Frontend Tried with Parallel64 and MupenGLES3 cores. I'm only having issues with those, every other core I have works fine (this includes many other consoles like Dreamcast, SNES, GB, GameCube, Wii, etc) Diddy Kong Racing worked, the majority of the other games did not.

Neither Hotkeys or game input work at all. It only works when played directly through retroarch without the Daijisho Frontend.

In an attempt to find a fix, I saved a Directory Config, just to see if that would somehow override any input problem when launching from the Frontend, but it actually made it worse, RA now simply crashes for some reason when launched from the frontend (all other cores have functioning Directory config overrides)

[unbelievableflavour]

@loki666 workaround worked for me! Thank you.

Change this setting like so:

1. Go to Retroarch > Settings > Input > Polling Behaviour
2. Change to "Early"
3. Save configuration.
4. Restart retroarch.

[feress737]

I think all Games that support rumble are not working from a frontend without "Polling behavior = early". With set to "early" the input works, but no rumble. Both works if I start a game directly over retroarch.

[Kevinwensh93]

unbelievableflavour

Want to add that this also happens to Odin Mini 2 with ES-DE Frontend.

Setting polling = early will fix the issue of recognizing the controller but rumble will never be operational.