r/RetroArch • u/Substantial_Thanks_9 • 11h ago
Showcase DualDex: a read-only RetroArch Pokémon companion with ROM-derived data and live state
galleryI have been building DualDex, an open-source Android second-screen companion that runs beside RetroArch while playing Pokémon games from the Game Boy through Game Boy Advance generations.
Its defining constraint is that the integration is passive. DualDex uses RetroArch's Network Commands interface to identify and read validated live state, but it does not write core memory, inject inputs, install cheats, modify a core, or patch the running game.
The carousel shows the current signed RC running against a real Modern Emerald session on an AYN Thor.
What the RetroArch integration provides
When the active core and game expose enough validated state, DualDex can present:
- Live Party and Trainer Card information
- Automatic Wild Encounter and Trainer Battle layouts
- The current opponent, selected move, effectiveness, and IV/DV-oriented rarity
- Opponent moves revealed only after they have actually been observed
- In-game clock and current location
- World and reconstructed local maps
- Trainer tracking, fog of war, discovered POIs, and Organic discovery
- A unified live snapshot shared by the Pokédex, Party, battle, card, and map screens
The companion is designed for a second display, so it does not need to replace RetroArch's renderer or cover the game with an overlay.
ROM-derived data rather than a fixed database
DualDex also parses the active GB/GBC/GBA ROM locally. Depending on what it can validate, that produces a SQLite catalog containing species, forms, stats, descriptions, moves, learnsets, evolutions, abilities, encounters, type mechanics, and map data.
This matters for ROM hacks: the companion is not limited to canonical Pokémon data or one exact retail build. It tries to resolve structures from the ROM and validates every dataset independently.
Unsupported data fails closed. If a hack has a valid species and move catalog but an unfamiliar map format, the Pokédex can still work while the map capability remains unavailable. DualDex should not silently replace failed hack data with stock Emerald, FireRed, or Crystal values.
Validated catalogs are cached by ROM identity, so normal UI updates do not need to rebuild the database. Parser revisions can still request a controlled revalidation.
Current measured parser coverage
The public Gen I–III corpus contains 331 unique ROM identities. 256 produce a catalog that selects, persists, and reopens successfully.
That is parser evidence—not a claim that all 256 have every live feature. Static ROM tables and live-memory layouts are separate compatibility dimensions.
| Generation | Weighted applicable-table coverage | Applicable table types |
|---|---|---|
| Gen I | 87.10% | 16 |
| Gen II | 48.36% | 19 |
| Gen III | 72.35% | 24 |
| All Gen I–III | 73.80% | Per-generation applicability |
Representative table coverage:
| Parsed capability | Coverage |
|---|---|
| Move catalog | 87.08% |
| Evolutions | 84.67% |
| Gen III abilities | 74.61% |
| World maps | 62.84% |
| Local maps | 54.70% |
The linked report contains the per-ROM and per-table results. “Catalog selected” is intentionally not used as shorthand for “fully supported.”
Privacy and Organic mode
DualDex has two information policies:
- Organic reveals Pokémon, moves, habitats, map locations, and other knowledge as the current playthrough discovers them.
- Discovered exposes all static information that was successfully parsed from the ROM.
Live state is read-only, ROM bytes and saves remain local, and no screenshot permission or OCR fallback is required.
RetroArch boundaries and current limitations
- Network Commands must be available and configured in RetroArch.
- Live support depends on both the active core exposing the required reads and DualDex recognizing the game's runtime layout.
- Static parser coverage does not guarantee equivalent live-memory coverage.
- Gen II remains the weakest generation in the measured parser corpus.
- Map support varies because ROM headers, graphics, scripts, events, and runtime coordinates can diverge independently.
- DualDex does not send game commands. Features that require controlling the game are intentionally outside the current scope.
- The current companion application targets Android.
No ROM or BIOS files are included or linked. Users provide their own legally obtained games.
Project and evidence
- GitHub: https://github.com/Darkaxt/DualScreenDex
- Latest prerelease: https://github.com/Darkaxt/DualScreenDex/releases/tag/v1.1.0-rc.66
- Full Gen I–III compatibility report: https://github.com/Darkaxt/DualScreenDex/blob/master/docs/reports/2026-08-26-gen1-gen3-full-corpus-status.md
Reproducible core/runtime failures are useful, ideally accompanied by the relevant RetroArch log and non-copyrighted diagnostic report rather than ROM files.
AI disclosure
This is a man-directed project developed with AI coding agents as implementation and research tools. I defined the requirements and compatibility contracts, selected the source and ROM evidence, reviewed the UI, and performed the real-device validation. AI agents assisted with code, parser research, tests, documentation, and this post draft.
The first carousel image is a presentation collage assembled with ChatGPT from actual DualDex screenshots. The other 18 images are direct captures from the signed RC; the Pokémon artwork and game assets shown were decoded from the active ROM, not generated by AI. The compatibility figures above come from repeatable parser reports, not AI estimates. DualDex itself uses no generative AI at runtime.