Fix a RetroArch touch overlay that is missing or unresponsive on Android
First load a known-good overlay from RetroArch's configured overlay directory and confirm it is visible. If it appears but does not control the game, test one frontend bind, then the core's device and port mapping. A visible image only proves the visual layer loaded; its descriptor names and hitboxes must still produce inputs the selected core accepts.
Do this in order
- 01
Record the RetroArch build, core, video driver, screen orientation, active overlay preset, and whether a hardware controller is connected.
- 02
Open the configured On-Screen Overlay directory and load one known-good preset shipped or maintained by Libretro.
- 03
Confirm the image is visible, then restore opacity, scale, aspect adjustment, and full-screen or viewport placement to known values.
- 04
Press one overlay control bound to a frontend action such as the menu; if that works, test one Player 1 game bind separately.
- 05
Check the selected core's controller device and port assignment, and disable only the overlapping hardware or remap layer for the test.
- 06
Restart the same authorized content in both orientations, then save the narrowest working game or core override and retain a recovery menu control.
Decision and diagnostic table
| Observation | Likely layer | Focused test |
|---|---|---|
| No overlay image | Preset path, visibility, or hardware-controller suppression | Load a known-good preset with no game override |
| Image visible; no button responds | Descriptors, hitboxes, or input capture | Test one frontend action and inspect the overlay log |
| Menu button works; game buttons do not | Core device, port, or remap | Restore Player 1 device and one default bind |
| Controls shift after rotation | Viewport/full-screen placement or saved orientation override | Reset geometry and retest each orientation |
The picture and the input map are separate
A RetroArch overlay preset can reference images and input descriptors. The image may render while a descriptor names the wrong bind, has a misplaced hitbox, or loses priority to an overlapping analog area.
Prove one frontend action first because it does not depend on the emulated machine's control layout. Then move to Player 1 inputs and the core.
Viewport geometry can hide a correct hitbox
Overlay coordinates may follow the game viewport or the full screen. Rotation, aspect ratio, integer scaling, and custom rectangles can therefore leave a visual control away from its intended touch area.
Return geometry to a known preset before editing coordinates. A custom overlay should be changed on a copy, with its image and `.cfg` kept together.
Pointer, lightgun, and gamepad touch are different modes
A normal overlay button sends a bind. Pointer, mouse, and lightgun behavior can use separate overlay options and core input devices. Enabling every mode at once can turn one touch into competing signals.
Select the mode required by the machine, test it alone, and preserve a touch path back to the menu before hiding controls for a hardware gamepad.
Use Libretro-maintained overlays or assets whose license permits your use. A controller graphic, bezel, or cabinet artwork is not automatically redistributable merely because an emulator can load it.