Native systems integration

FalcomBGMInfo

The feature looks small. The engineering surface is not: different executables, audio paths, CPU architectures, renderers, and compatibility layers all need to behave like one product.

20+supported games
DX9/11render paths
x86/x64architectures

Compatibility surface

One feature. A matrix of runtimes.

The visible overlay is the smallest part of the product. The engineering work is preserving one behavior across incompatible executables, renderers, architectures, and host environments.

SystemFalcomBGMInfoone product behavior
Rendering
DirectX 9 · DirectX 11
Architecture
x86 · x64
Host
Windows · Proton
Integration
Proxy DLL · native hooks · ImGui · YAML
Browse the full supported-games catalog

Problem

Older Falcom PC releases lack the unobtrusive track notification found in newer ports. No single hook or rendering path works across the full catalog.

Engineering approach

  • Detect the running title and select game-specific configuration and music metadata at runtime.
  • Support DirectX 9 and DirectX 11, x86 and x64, proxy DLL loading, MinHook detours, and game-specific fallback hooks.
  • Preserve renderer state while drawing a lightweight ImGui notification backed by external YAML metadata.
  • Keep installation compatible with Windows and Proton-based Steam Deck setups.

Outcome

  • A single public project supports modern and retro releases with six published release iterations.
  • The project demonstrates compatibility engineering across systems that were never designed to share an extension layer.

The hardest problem

The challenge

One notification behavior across nineteen games whose only common trait is the publisher.

The constraint

DirectX 9 and 11 manage render state differently, x86 and x64 change calling conventions, and several games expose no clean hook point for music changes.

The way through

Detect the title at runtime, load a per-game music map and hook strategy, and isolate renderer backends so ImGui drawing always restores the exact state it found.

How I worked through it

Installation is part of the compatibility surface. Players load the mod through a proxy DLL, winmm, dinput8, version, or xinput1_4 depending on the game and on Proton, so a name that works on one title silently does nothing on another. The fix was treating the loader matrix as a product feature: documented per-game and per-Proton renames, with Xanadu Next needing its own d3d8 wrapper on top.

Where no clean audio hook exists, the mod falls back to game-specific hooks chosen per title, and all music metadata lives in external YAML so supporting a new game rarely means recompiling, it means mapping it.

Technologies

  • C++17
  • DirectX 9
  • DirectX 11
  • MinHook
  • Dear ImGui
  • CMake
  • YAML
  • Win32

Next case study

RPGModder

A transactional mod manager for RPG Maker MV and MZ with recovery snapshots, automatic rollback, and structured conflict analysis.