Pokémon Fulldex Merges Both DS Screens Into One Picture. Here Is What Actually Runs It.

2026-11-09 · News and analysis

Affiliate disclosure: This guide contains affiliate links. As an Amazon Associate, we earn from qualifying purchases at no extra cost to you. Learn more.

Every DS emulator asks you to pick a compromise. Stack the two screens and both are small. Put them side by side and both are smaller. Show one at a time and you are pressing a hotkey every time you want the map.

A project called Pokémon Fulldex takes a different route. It watches what the game is doing, works out whether you are in the overworld, in a battle or in a menu, and then rebuilds both DS screens into a single 16:9 picture arranged for that situation. The touch screen's buttons get tucked beside the action instead of sitting underneath it. It covers nine DS Pokémon games and six GBA ones, and it runs on Windows, Mac, Linux, Android, iPhone and a modded Switch.

The pitch going around is that this is ideal for retro handhelds. That is the part we wanted to check, so we downloaded the ARM64 build and read what it needs. The answer is more interesting than a yes or a no.

The Short Version

• What it does: merges the two DS screens into one widescreen picture, recomposed per situation rather than just stacked
• Games: nine DS titles (Black, White, Black 2, White 2, HeartGold, SoulSilver, Platinum, plus Diamond and Pearl marked experimental) and six GBA titles
• What it is not: not a native port, and despite the project's naming history, the build you download contains no recompiled game code. It is melonDS and mGBA with a clever layer on top
• The gate on Linux handhelds: the ARM64 build needs glibc 2.38 or newer. That one number decides whether your custom firmware can run it at all
• The gate on Android handhelds: the widescreen 3D is drawn by the processor by default, not the graphics chip
• The 60 fps: interpolated in-between frames, not the game running at 60
• ROMs: you bring your own. The downloads contain no games

Will It Run On Your Handheld?

If your firmware is not in that table, you can settle it yourself in one command over SSH:

ldd --version

Anything that reports 2.38 or higher can run the Linux build. Anything lower cannot, and no amount of settings will change that.

The glibc Floor Is The Whole Story On Linux

We pulled the ARM64 release apart rather than trusting a requirements line. The shipped executable asks for two things that matter: glibc 2.38 and GLIBCXX 3.4.32. The second one means it was built with a 2023 era compiler. Both are hard requirements. A binary that wants symbols your system does not have will not start, and it will not tell you why in any friendly way.

This is not a theoretical worry. The project's own validation notes concede that the x86_64 build "requires GLIBC_2.38 and fails on Ubuntu 22.04", and describe that as an unresolved issue.

So the question for a cheap Linux handheld becomes a question about your firmware, and the answer splits the field in a way that surprised us.

ROCKNIX clears it comfortably. ROCKNIX ships a modern glibc and bumped it again in October 2026, so it sits well above the floor. If you are running ROCKNIX on a Rockchip or Snapdragon handheld, the ARM64 build is at least installable.

ArkOS does not clear it. ArkOS is built on a much older Ubuntu base, and its glibc is roughly 2.30. That is below the floor, so this is not software you can install there.

That is the opposite of what you might guess. The cheap handheld firmware with the modern userland is in, and the older favourite is out. If you have been putting off a firmware decision, this is a small point in ROCKNIX's favour.

We have seen this exact pattern before. When we covered the Spider-Man and Edge of Time recompilation projects, the glibc requirement on their AppImage was the thing that decided which handhelds were invited, and almost no coverage mentioned it. It is worth checking every time a project ships a prebuilt Linux binary.

One more detail worth knowing. The project's own documentation points ARM handheld users at Armada, the SteamOS style ARM Linux distribution we cover in our Steam on Android handhelds guide. That is a reasonable suggestion, but be clear about what it asks of you. You are replacing your handheld's operating system to play a Pokémon game on one screen. For most people that is a bigger project than the game.

Android Is The Realistic Route, And It Has One Real Catch

For a Retroid or an Anbernic, the APK is the sensible path. The requirements are gentle on paper. You need a 64 bit device running Android 7.0 or newer, and the app only asks for OpenGL ES 2.0, which every handheld in this category has.

Then you read how the widescreen picture gets drawn, and the gentle requirements stop mattering.

On Android the 3D world is drawn by the processor, not the graphics chip, and it starts at 720P. That is a very different workload from normal DS emulation. You are asking the CPU to render a widened 3D scene every frame, on top of emulating the DS at all.

The project lists exactly one device as running at full speed: a Pixel 9 Pro XL. That is a current flagship phone. It tells you almost nothing about a Helio G99 or a Snapdragon 680, which is what most handhelds in the Anbernic range actually use.

So treat Android performance as unknown on your device until you try it. Three settings exist for exactly this, and you should expect to use them:

• 3D RESOLUTION. Drop it below 720P. On a 640x480 or 720p handheld panel you are not losing much
• LOWER DETAIL WHEN BUSY. Trades sharpness for a steady frame rate in crowded areas
• 60 FPS. Turn it off. This is the interpolation, and it is the most expensive thing in the list

Two notes from the project's own bug tracker, because they tell you how young this software is. A Retroid Pocket Nova owner reported the app opening to a black screen and never starting. The cause turned out to affect only certain Android devices, a fix shipped, and the person who reported it confirmed it worked afterwards. That is a good outcome and a healthy sign.

On the other hand, an AYN Odin 3 has still not been verified at all. The project says so itself and is openly asking for someone to test one. There was also a crash on Android 15 devices that use 16 KB memory pages, which the project has since rebuilt its libraries to handle.

None of that is damning. It is normal for software this new. It does mean you should not buy a handheld for this, and you should expect to be the one who finds the next bug.

About That 60 fps

The headline figure is real, but it does not mean what most people will read into it.

DS Pokémon games render their 3D at 30 fps. Fulldex does not make the game run faster. It generates in-between frames and shows those, so the motion looks like 60 fps while the game underneath is still doing what it always did.

That is frame interpolation, and it is the same distinction we drew about frame generation on handhelds. Generated frames make motion smoother. They have never made a game feel faster, and they cost performance to produce. On a weak handheld that cost is the first thing you should give back.

If the game feels sluggish, turn 60 FPS off. You will be seeing the frame rate the game always ran at, which is the frame rate it was designed around.

It Is Not A Recompilation, And That Matters

This part needs care, because the project's history points one way and the thing you download points another.

Fulldex grew out of a genuine static recompiler. That earlier project took Pokémon SoulSilver, translated its ARM9 code into C++, and ran that translated code in place of an emulator's interpreter. It worked by rebuilding the game on your own machine from your own copy, which is why it never distributed any game code.

The build you download from Fulldex does not do that. We checked inside the binary, and it carries its own explanation in plain text: this build has no recompiled code, and runs on the interpreter. Its command line options say the same thing from another angle, offering to load a "function table of a game that is not recompiled".

So what you are running is melonDS for the DS games and mGBA for the GBA ones, both bundled in, with a layout engine on top that uses those per game function tables to know which screen to show and where. The project's own description agrees. It says plainly that this is not a native port.

This is not a criticism. The layout work is the interesting part and it is genuinely good. But it sets your expectations correctly in three ways:

• Performance is melonDS performance. If melonDS struggles on your handheld today, this will struggle too, and then add a widened 3D view on top
• Compatibility is melonDS compatibility. The supported game list is about which games the layout engine has been taught, not about which games can be emulated
• It will not run on hardware that cannot already emulate the DS. There is no magic here that removes the emulation cost

It also means this does not belong in our list of recompiled games, and we have deliberately left it out. Filing it there would make that list wrong.

Made With AI, And The Project Says So

Worth mentioning because the project volunteers it rather than hiding it. Its own metadata states that nearly all of the code was written by an AI coding assistant, directed and play tested by the person running the project.

We note that the way we noted it for other projects that disclose it. Disclosure is better than silence, and the code either works or it does not. In this case there are signs of real care: the project keeps detailed validation records, admits in writing which devices it has not tested, and documents the bugs it has not fixed.

One related detail. The layout engine knows where to look inside each game because it uses function name lists from published decompilation efforts. Only the symbol files, not the code. Those projects did years of patient work that made this possible, and they deserve the credit for it.

If You Cannot Run It, Here Is The Free Answer That Works Today

Plenty of readers will finish that table and find themselves on the wrong side of it. The good news is that the compromise version of this has been built into melonDS for years, and it is genuinely fine.

Set the screen layout to single screen, then bind a Screen Swap hotkey. You play on the top screen and tap the hotkey when you need the map, the bag or the touch menu. Our melonDS setup guide has the exact menu paths for both the standalone emulator and the RetroArch core, under the single screen section.

It is not as elegant as one merged picture. It costs nothing, runs on anything that can emulate the DS at all, and works with every DS game rather than nine Pokémon titles.

If you want the wider 3D view specifically, WideMelon is the other project in this space. It widens the 3D while leaving menus and the touch layer at normal proportions, and it does ship ARM Linux builds.

And if what you actually want is both screens at full size, that is a hardware answer rather than a software one. Our dual screen handhelds guide covers the devices that give each DS screen its own panel.

What You Need To Play These

The honest ranking here follows the table. One route has no caveats, and the rest have at least one.

The Steam Deck is the clean answer. SteamOS clears the glibc floor, the hardware draws the widescreen world on the GPU rather than the CPU, and the project gives Deck specific setup instructions. Set 3D RESOLUTION to 720P to match the panel and add it as a non Steam game.

A Snapdragon Android handheld is the portable answer, with a question mark. Something in the Retroid Pocket class has the processor headroom to make CPU drawn 3D plausible, and the APK install takes two minutes. Just go in knowing that your specific device may not have been tested by anyone.

If DS is what you mostly play, consider buying the problem away. A dual screen handheld gives both DS screens a real panel each and needs no special software at all. Our DS and 3DS handheld guide covers the trade offs in full.

Frequently Asked Questions

What is Pokémon Fulldex?

It is a free program that plays nine DS and six GBA Pokémon games with both DS screens merged into a single widescreen picture. It bundles the melonDS and mGBA emulator cores and adds a layer that rearranges the screens based on what the game is doing. It runs on Windows, Mac, Linux, Android, iPhone, iPad and a modded Switch.

Does it include the games?

No. You bring your own ROM files. The downloads contain no game data at all, and the project is explicit about that.

Will it run on my Anbernic or Retroid handheld?

If the handheld runs Android, probably, but performance is the open question. The widescreen 3D is drawn by the processor rather than the graphics chip, and the only device the project confirms at full speed is a current flagship phone. If the handheld runs Linux custom firmware, it depends entirely on your glibc version. ROCKNIX is new enough and ArkOS is not.

What glibc version does the Linux build need?

2.38 or newer, along with GLIBCXX 3.4.32. We read both requirements directly out of the shipped ARM64 executable. You can check your own system with ldd --version over SSH. Below 2.38 the program will not start.

Is the 60 fps real?

It is interpolated. The DS games render their 3D at 30 fps, and the program generates in between frames to make motion look smoother. The game is not running faster and it will not respond faster. Turning the setting off is the first thing to try if performance is poor.

Is this a recompilation like the Zelda and Mario 64 ports?

No, and this is a common confusion because of the project's naming history. It grew out of a real static recompiler, but the build you download runs no recompiled code. It is emulation with a sophisticated layout layer on top. That means performance and game compatibility both behave like melonDS, because underneath it is melonDS.

Does it work on a modded Switch?

Yes. The Switch build runs every supported game at 720p from a single program, and it can add HOME Menu icons for each game. Those icons are forwarders, so they need sigpatches to launch, the same as any other forwarder.

What do I do if it will not run on my handheld?

Use melonDS with the screen layout set to single screen and a Screen Swap hotkey bound. You see one screen at a time and swap when you need the other. It costs nothing, works on far weaker hardware, and supports every DS game rather than a short list.

Related Reading

• melonDS Setup Guide: Best Settings, Screen Layouts, and Controls
• Best Handhelds for DS and 3DS Emulation
• WideMelon Gives DS Games a Real Widescreen View
• Dual-Screen Android Handhelds in 2026: The DS Revival
• Anbernic RG DS Plus: The Screen Math Is the Whole Story
• What Is Integer Scaling? Pixel-Perfect Retro Games Explained
• Best Nintendo DS Games Worth Replaying on a Retro Handheld

Written 9 November 2026. The glibc 2.38 and GLIBCXX 3.4.32 requirements, the absence of recompiled code and the bundled mGBA core were read directly from the project's shipped ARM64 Linux release on that date. The Android rendering behaviour, the single verified full speed device, the Switch details and the AI disclosure come from the project's own documentation and metadata. The Retroid Pocket Nova fix, the unverified Odin 3 and the Android 15 memory page crash come from its public issue tracker and changelog. ROCKNIX glibc versions come from that project's own package definitions. This software shipped eight releases in five days, so specifics will move quickly.