Feature Request: Custom Overlay/Bezel Support for TWL_FIRM (DS Mode)

[Redbullsenpai]

When playing Nintendo DS games on a 3DS in 1:1 mode (integer scaling), large black borders appear around the gameplay screen. While TWiLight Menu++ and nds-bootstrap offer great control over scaling, they cannot fill those borders with a bezel or overlay image. This makes the screen feel underutilized, especially on XL models.

Add an option (via Luma3DS settings, or an external configuration file) to display a static user-defined overlay or bezel image during DS mode (TWL_FIRM).
Ideally:

• The overlay should render above the DS game framebuffer.
• It should support PNG/JPG files placed in a designated directory.
• The feature could optionally toggle on/off via Luma’s in-game menu.

Ive Considered

• TWiLight Menu++ and nds-bootstrap developers confirmed this is not possible to implement on their side, as overlays would require modification of TWL_FIRM’s rendering layer.
• Editing DS ROMs to add borders is impractical.
• Hardware screen mods are possible but expensive and irreversible.

Additional context
This feature would bring DS gameplay presentation closer to RetroArch or emulator-style overlay setups, improving aesthetics and immersion without affecting game logic.
Example of the intended effect: (attach your example image here)

Confirmed response from TWiLight Menu++ dev:

“Not possible to implement on TWiLight Menu++ (or nds-bootstrap)'s side. This would have to be done on TWL_FIRM's side.”

[TuxSH]

Planned, but:

• I think you vastly underestimate the effort needed. This basically requires writing a replacement for TwlBg (the Arm11 component process) which in turns requires re-implementing most of the driver stack. This something I've been doing for the past two years or so
• In TWL mode there is just not enough memory: FCRAM (main RAM) is unavailable, so is DSPRAM, and VRAM loses its contents upon sleep entry. It will have to be a small texture, which means 16x16 (highest power of 2 dividing both 400, 320 and highest power of two dividing 240, resp.)

[Redbullsenpai]

Thanks so much for the detailed explanation that really helps put the scope into perspective.

I completely understand now why this would be such a heavy lift, especially with how TWL_FIRM isolates memory and the fact that TwlBg handles all of the DS-mode framebuffer work. Re-implementing the driver stack sounds like a massive undertaking, so it’s really impressive to hear that you’ve already been working on it for a couple of years.

Even limited support (like small 16×16 tiled textures or a static pattern) would already be a great visual enhancement for 1:1 DS mode. It’s awesome to know this is planned in the long term. thanks again for clarifying and for all the work that goes into making DS mode improvements possible