Guide

WideMelon Gives DS Games a Real Widescreen View. It Runs on ARM Handhelds Now.

Cole StubblefieldBy Cole Stubblefield 2026-09-14 Updated 2026-09-30
WideMelon Gives DS Games a Real Widescreen View. It Runs on ARM Handhelds Now. — News guide for retro handhelds | Held Games

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

2026-09-14 · News and analysis · Updated 2026-09-30

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

A new Nintendo DS emulator called WideMelon showed up this week, built on melonDS, and the pitch going around is simple. It gives you widescreen support.

That framing undersells the interesting part and skips the important part.

The interesting part is not that it does widescreen. melonDS could already output 16:9, and it has been able to for years. What WideMelon does differently is widen only the 3D view while leaving your menus, sprites, videos and touchscreen at their normal proportions. That is the hard version of the problem and the one people actually wanted solved.

The important part is that there is no Android build and no ARM build. If your handheld is a Retroid or an Anbernic, this is not software you can install today.

The Short Version

  • What it is: a fork of melonDS that expands the 3D render target so compatible games show more of the world at the sides
  • What stays normal: 2D interfaces, menus, sprites, videos and the touchscreen, all composited over the middle at native size
  • Range: native 4:3 through 32:9
  • Requirement: the OpenGL renderer. The widened profiles do not work on the software renderer
  • Bonus feature: it can send the bottom screen to your phone and use the phone as a touchscreen and controller
  • Platforms: Windows x86-64, macOS on Intel and Apple Silicon, and Linux on both x86-64 and aarch64, as AppImage or .deb
  • Not supported: Android. There is still no APK
  • Cost: free, GPL-3.0-or-later
  • How new it is: the repository was created 10 September 2026 and is already on v1.0.4, published 18 September 2026
  • Compatibility list: there isn't one yet

melonDS Already Did Widescreen. Badly.

This is the context that makes WideMelon make sense, and almost nobody is including it.

Standard melonDS has had a 16:9 option for a long while. You set the aspect ratio in the video settings and the picture fills a widescreen display. The problem is what that setting actually does, which is stretch. Your DS image gets pulled sideways. Characters get fat. You see no more of the game world than you did before, you just see the same amount of it distorted.

The better established trick is a widescreen cheat code. These are AR codes written per game by the community, and they tell the game itself to render at a wider field of view. Combine one with the 16:9 display setting and you get a real widescreen picture with correct proportions.

That route works and people have used it for years. It also has three problems. A code has to exist for your specific game, and for most games one does not. The codes are entered as cheats rather than set as a preference, so you have to remember to turn them off before you load a normal game. And the widening applies to everything the game draws, including the 2D layers that were never meant to move.

What WideMelon Actually Changes

WideMelon splits the screen into two jobs instead of one.

In the project's own words, it "expands the 3D render target and adjusts the projection so compatible games reveal additional geometry on both sides." The 3D scene gets rendered wider, so you genuinely see more of the world to your left and right.

Then the 2D layers go back on top, unchanged. The original view stays centred at its original scale, and the native 2D content sits over the middle 256 pixels without being stretched. So your HUD, your text boxes, your menus and your touchscreen all keep the shape they were drawn in.

That is the whole idea. Widen the world, leave the interface alone.

The range runs from native 4:3 all the way out to 32:9, set through a view width that accepts even values from 256 up to 768 pixels. There is a separate scale setting that goes from 1 to 8.

Two practical catches. The widened profiles need the classic OpenGL renderer, and native 4:3 is the only profile available on the compatibility path. And the view width is locked when the program starts, so changing profiles means restarting the emulator.

It Does Not Work on Every Game, and There Is No List

The project is upfront about this, and it matters more than the feature itself.

Widescreen support is game-dependent. Whether you get a good result depends entirely on how a given game builds its 3D scene. Some games cull objects that sit outside the original view, which means the extra space you just unlocked gets filled with nothing, or with scenery popping in and out at the edges. And plenty of things stay 4:3 by design, including menus, battles, videos and special effects.

There is no list of tested games. Not in the README, not in the release notes. The project asks users to report what they find.

So there is no way to look up whether the game you care about benefits. You install it and you try.

The Phone Touchscreen Trick Is the Better Story

Buried under the widescreen headline is a feature that solves a more annoying problem.

WideMelon can serve the DS bottom screen to your phone. You open a menu, pick your local network address, scan a QR code, and the bottom screen appears in your phone's browser. No app to install. Your phone becomes the touchscreen and a controller, and there is a layout editor for moving the controls around.

Technically it crops the bottom screen out of the OpenGL output and pushes it over your local network as JPEG at up to 30 frames per second, accepting touch and button input back over the same connection.

Anyone who has played Phantom Hourglass with a cursor mapped to an analog stick understands why this is appealing. A real finger on a real touchscreen is how the game was meant to be played.

One warning, and the project states it plainly. The connection is not encrypted. The documentation specifically advises against using it on public, guest, school or workplace networks. Keep it on your own home network. The bridge also does not carry audio, so sound stays on the computer.

Which Handhelds Can Run This

Here is the part the social media version of this story leaves out entirely.

Correction, 30 September. When we published this on 14 September, the project shipped x86-64 and Mac builds only, and we said so in the title. It added ARM the next day. Version 1.0.3, published 15 September 2026, introduced an aarch64 AppImage and an arm64 Debian package, and v1.0.4 on 18 September carries both. So the ARM Linux half of our original conclusion is wrong and this section is rewritten.

The current release publishes eight builds: a Windows x86-64 installer, macOS disk images for Apple Silicon and Intel, AppImages for x86-64 and aarch64, Debian packages for amd64 and arm64, and a complete source tarball, with SHA256SUMS alongside.

What is still missing is an APK. Android is not a target and is not mentioned as one.

Steam Deck and Windows handhelds: yes. These are x86-64 machines, so the AppImage or the Debian package applies to a Steam Deck and the installer applies to a Windows handheld. Worth saying that the project never names the Steam Deck or SteamOS anywhere, so treat this as architecture compatibility rather than tested support.

Android handhelds: no. Retroid, the Android Anbernics, AYN, anything running Android. There is no build and Android is not mentioned as a target anywhere in the project's documentation. This is not "untested," it is "does not exist."

ARM Linux handhelds: now yes, on paper. The aarch64 AppImage and the arm64 .deb cover devices running full ARM Linux. That brings the TrimUI range, the ARM Linux Anbernics and similar hardware into scope, which was the whole reason we flagged the gap in the first place.

Two honest caveats. The project still never names a single handheld or custom firmware, so this is architecture compatibility rather than tested support. And the widened profiles require the OpenGL renderer, which is the harder ask on cheap ARM hardware, not the aarch64 binary. A device that can run the AppImage but not the OpenGL path gets you nothing.

Android handhelds: still no. Retroid, the Android Anbernics, AYN, anything running Android. There is no APK in any release and Android is not mentioned as a target anywhere. This is not "untested," it is "does not exist."

Worth knowing about, and worth being careful with: there is also an unofficial aarch64 AppImage sitting in a separate one-file repository with no README and no source, and a third-party ARM64 client project. Neither is from the WideMelon author. Take the official aarch64 build from the project's own releases instead, and read how to download emulators safely before running a loose binary somebody committed to a repo.

There is one genuinely interesting third-party effort, though. WideMelon can send the bottom screen to a phone and use it as a touchscreen. Somebody has built an ARM64 Linux client that does the same job with a handheld instead, so your TrimUI becomes the DS touchscreen for WideMelon running on a PC. It is early, it currently names only one device as compatible, and it carries its own warning about risk to your console. It is a neat idea rather than a recommendation.

Our melonDS setup guide covers the standard emulator on every platform, including the widescreen options that do work on a handheld.

How New This Is, and Why That Matters

Some numbers for calibration, because they are easy to miss.

The repository was created on 10 September 2026. Version 1.0.0 and version 1.0.2 were both published on 11 September 2026, a few hours apart, and there is no 1.0.1 release. It reached v1.0.4 by 18 September and has not been pushed since. Stars went from 38 when we first wrote this to 98.

None of that is a criticism. Plenty of good software starts exactly this way, and the technical documentation is unusually thorough for a four day old project.

It is context for your expectations. This is a very new fork with no compatibility list and a feature the author describes as game-dependent. Four releases in nine days, then quiet for a fortnight, is a normal shape for a one-person project and not a warning sign by itself.

Also worth noting for accuracy: the project describes itself as based on melonDS 1.1, but no upstream commit is pinned anywhere, so that is the project's own claim rather than something you can verify from the repository. It states clearly that it is not affiliated with or endorsed by the melonDS project.

Should You Bother

If you play DS games on a PC or a Steam Deck and you care about 3D titles, yes, it is worth twenty minutes. The games most likely to benefit are the fully 3D ones where a wider camera actually reveals world geometry. Think Mario Kart DS or the 3D Zelda titles rather than sprite based RPGs, where there is no 3D scene to widen in the first place.

If you play on an Android or ARM handheld, there is nothing to try yet.

And if you were hoping this replaces the cheat code approach entirely, not yet. Without a compatibility list, the honest answer is that WideMelon is a better idea than the AR code route with less evidence behind it.

Frequently Asked Questions

What does WideMelon do that melonDS cannot?

It widens the 3D render target while leaving 2D layers and the touchscreen at native proportions. Standard melonDS can stretch the picture to 16:9, and per game widescreen cheat codes can make a game render wider, but neither approach separates the 3D scene from the interface. WideMelon is built around that separation.

Does WideMelon run on Android handhelds like the Retroid Pocket 5?

No. The project ships builds for Windows, macOS and Linux, all x86-64 apart from an Apple Silicon Mac build. There is no APK and Android is not mentioned as a target in its documentation. For DS emulation on an Android handheld, use standard melonDS or the melonDS DS core in RetroArch.

Does it work on a Steam Deck?

It should, since the Steam Deck is x86-64 and the project ships an x86-64 AppImage and a Debian package. The project does not name the Steam Deck or SteamOS anywhere, so this is architecture compatibility rather than confirmed support. We have not tested it.

Does widescreen work in every DS game?

No, and the project says so directly. Results depend on how each game renders its 3D scene. Some games cull objects outside the original view, and menus, battles, videos and effects often stay 4:3 by design. There is no list of tested games yet.

Can I use my phone as the DS touchscreen?

Yes, that is a built in feature. You pick your local network address, scan a QR code, and the bottom screen opens in your phone's browser with no app needed. The connection is not encrypted, so the project advises keeping it off public, guest, school and workplace networks. It does not carry audio.

Is WideMelon free?

Yes. It is released under the GNU General Public License version 3 or later, the same license as melonDS, which it is forked from.

Do I still need DS BIOS files?

Yes. WideMelon is a melonDS fork, so the same requirements apply. Nothing about a widescreen fork changes how DS emulation is set up. Our melonDS setup guide covers BIOS files and everything else.

Should I use the OpenGL or software renderer?

OpenGL, if you want the widescreen feature at all. The expanded view profiles require the classic OpenGL renderer. Native 4:3 remains available as the compatibility profile for cases where OpenGL causes problems.

Written 14 September 2026. WideMelon is four days old with no compatibility list, so the practical picture will change quickly. The platform support described here is from the project's published release assets on that date.

Related reading