[Feature Request] Frame Generation support for RetroArch on Android for Redmagic devices and others

[Beats24-7]

Hi there,
I’m using a RedMagic Astra tablet (Android 15), which offers hardware‑level Frame Generation for selected games. I went through the known workaround of spoofing the package name and verified that the FrameGen options actually appear in the device game menu.

FrameGen works on Android with other emulation or virtualization solutions such as Dolphin Emulator, Eden, GameHub and Winlator, but unfortunately not with RetroArch, regardless of the core used. I tested SwanStation, Snes9x, Genesis Plus GX, etc.., but none of them trigger true FrameGen behavior (still locked to 60fps).

I’m not an expert at OS‑level rendering or HAL interaction, but it seems that RetroArch doesn't trigger RedMagic’s FrameGen hooks at the hardware‑level, even if the package name is spoofed? Unlike e.g. Eden or GameHub where FrameGen actually works with the same method.

It would be amazing if RetroArch could support (officially or experimentally) RedMagic FrameGen/HAL integration, assuming that this is indeed the missing layer of compatibility. This would especially benefit older systems like NES, SNES, GB, GBA, etc. which normally run at 30fps, and the smoothing effect from FrameGen would make a huge difference.

Thanks for considering this!

[hizzlekizzle]

I didn't see anything that would allow us to enable this from a cursory google search.

NES, SNES, GB, and GBA all run at 60 Hz, for the record.

[Beats24-7]

Thanks for your reply. Just to clarify my perspective - I fully understand that RetroArch outputs these systems at 60 fps and syncs to 60 Hz. My point is more about internal motion cadence rather than final output framerate. The classic consoles did output at 60 Hz (NTSC) or 50 Hz (PAL), but very often the actual motion or animation rate was only updated every second frame. In other words, the display shows 60 images per second, but many games use duplicate frames, resulting in an effective motion cadence closer to 30 fps (or 25 fps on PAL). So the rendering loop is 60 Hz, but the animation logic is ~30 Hz.

That’s where RedMagic’s hardware Frame Generation would help tremendously, by interpolating intermediate frames and smoothing these motion gaps, much like it already successfully does with Dolphin, Eden, Winlator, etc. I've also tested this with Lossless Scaling on Windows where it works, and it really makes a huge difference in motion smoothness and clarity.

However, the issue seems to be that RetroArch might not be using the specific rendering layer / surface / flags that trigger the RedMagic FrameGen hardware hooks, even if package name spoofing works. Other emulator apps like Dolphin, Eden, Winlator and GameHub trigger it, RetroArch doesn’t, which suggests a compatibility or HAL-level integration issue.

It would be fantastic if the RetroArch team could check whether experimental support for hooking into RedMagic’s FrameGen is technically feasible. I think many users (especially on RedMagic devices) would appreciate the benefit.

I think the key difference might be in how the rendering layer is presented to the OS/HAL. Apps like Dolphin, Eden, Winlator or GameHub on Android apparently expose their rendering surfaces in a way that makes them recognizable to the RedMagic FrameGen system. RetroArch, on the other hand, might be using a different composition or surface type (possibly via its video driver backend: Vulkan, OpenGL) which doesn’t trigger the FrameGen hooks, even when the package name is spoofed.

Just to be clear: I am not asking to enable RedMagic integration explicitly or build vendor-specific logic. But it would be ideal if RetroArch’s graphics output path were compatible enough so that, when the user does spoof the package name, the RedMagic HAL can interface with it the same way it already does with other emulation environments.

Even if this is not exposed in Android documentation, it seems empirically demonstrable that real-world apps can trigger it, so there must be some common detectable surface type, flag, buffer format, or rendering hint that RetroArch currently isn’t using?

Perhaps it’s worth investigating whether matching the same Vulkan or SurfaceView characteristics used by Dolphin / Eden would make RetroArch appear “FrameGen-compatible” to the HAL.

[hizzlekizzle]

That's what I'm saying: I can't find anything about it all, so it's a needle in a haystack. Without any clue about what it's doing and why, there's no way to know what we need to expose/enable/mimic/whatever.

[Beats24-7]

Thanks for your reply. I understand it’s a bit tricky since RedMagic doesn’t document anything publicly, so it’s not straightforward to find. But the fact that Dolphin, Eden, Gamehub and Winlator trigger FrameGen without any special RedMagic code suggests it’s really about how the app presents its frames.

A practical way forward could be a simple comparison: Run one of the working apps like Eden and RetroArch under the same conditions and see what differs in how frames are presented?
Eden - Optimized Release: For any Android device that has Frame Generation or any other per-device feature
https://github.com/eden-emulator/Releases/releases

Even just observing differences in video backend, simple settings, or minimal rendering paths could give hints about why FrameGen isn’t triggered with Retroarch but with Eden. RetroArch’s output could then match the conditions the HAL expects when package spoofing is used. This kind of small, experimental check could quickly clarify whether it’s feasible without needing to dig into undocumented details.

[hizzlekizzle]

Okay, looks like it might be related to this:
https://developer.android.com/games/optimize/display-refresh-rate-change (and, by extension, this: https://developer.android.com/media/optimize/performance/frame-rate)

And this existing issue for that:
#15157

[Beats24-7]

Thanks for looking into this! Nice find, Android 15 seems to provide a 'setFrameRate()' API for dynamic refresh rate and frame pacing, which emulators like Eden likely use to enable FrameGen. Could RetroArch implement or hook into these APIs to actually enable FrameGen? The existing issue #15157 seems to describe the same;; I just didn’t find it earlier due to the short description.

[hizzlekizzle]

If that's all it takes, that's something we'd certainly like to support but we don't have anyone who uses and works on Android regularly, and if it's only in Android 15+, it's going to force us to cut off compatibility with a lot of devices.

[gouchi]

@Beats24-7 If it is duplicated issue, it is better to continue the discussion to the original one and close this one ;)

Thank you.

[Beats24-7]

Just to clarify a few things regarding the Android-version concern:

The setFrameRate() API is not limited to Android 15. According to Google’s own documentation, it exists since API level 30 (Android 11): https://developer.android.com/media/optimize/performance/frame-rate

Older Android versions should simply ignore the call if they cannot act on it. The documentation states that the system may switch refresh rates if supported. Also, the Eden emulator supports Android 7+ and still triggers FrameGen for Android versions 11+, which suggests that the behavior depends more on how the app’s surface setup, rendering pipeline and buffer timestamps are configured than on the OS version itself. In other words, the API usage should be optional, not required or automatic.

@gouchi Regarding the duplicate issue: The older issue contains no answers, no technical details and no follow-up. This issue here provides actual documentation links, reproducible examples (Eden, Dolphin, Winlator etc.) and a clearer description of the underlying problem. If anything, it would make more sense to keep this issue open and merge the old one into it, rather than closing this one?

Thank you.