Chapter 75 Case Study: Speedy Blupi and Planet Blupi

free-direct’s subsystem boundaries come from audits of the two games at named commits. Both use DirectDraw and DirectSound; only Free Eggbert uses DirectPlay. free-eggbert calls Blt four times and BltFast six times; Planet Blupi calls them three and five times. In each game, one Blt performs the once-per-frame back-buffer-to-primary present. This call-site pressure explains why Chapter 60 describes DirectDraw as the most developed of the library’s three subsystems.

Both games request an explicit display depth: free-eggbert selects 8 or 16 bits through a runtime flag, while Planet Blupi requests 8 bits. free-direct’s SetDisplayMode ignores that value and creates a 32-bit primary surface. The deviation does not affect these two games because their offscreen surfaces follow a separate, hard-coded 32-bit path. Every observed producer and consumer therefore agrees on the delivered format. This is a verified harmless deviation for the audited callers, not a general guarantee about ignoring pixel-format requests.

Planet Blupi uses source color-keying at two call sites through one caching helper. Both construct a single-value range and match white through a GetDC / SetPixel / Lock round trip, not through a fixed palette index. free-direct implements low-to-high ranges, but the audited games exercise only the single-value case. A third game would need separate evidence for ranged behavior.

Planet Blupi’s IsIconPixel performs a per-click gameplay hit test through GetDC / ReleaseDC. The implementation must handle both a zero-copy 32-bit wrap and an 8-bit surface expanded into a temporary palette-converted buffer. An API that appears to be incidental GDI interoperation therefore sits on an active gameplay path.

A later performance audit benchmarked the compiled library headlessly with SDL_VIDEODRIVER=dummy. DirectDraw 3’s BltFast has no destination-size parameter, so it cannot scale. Every audited BltFast interface call in both games (free-eggbert: pixmap.cpp:406,574,580,612,1762,1818; Planet Blupi: pixmap.cpp:395,401,433,1235,1291) is consequently 1:1. At the time of measurement, the shared blit engine still performed a per-pixel integer division and bit-depth branch for these copies. It measured 29 times slower than a raw memcpy of the identical byte count at an optimized build (0.715 ms versus 0.0244 ms for one 640$\times$480 32-bit blit), and 206 times slower under the then-default unoptimized configuration.

Those numbers are discovery evidence, not the current implementation. The pin now defaults an otherwise-unspecified top-level, single-configuration free-direct build to Release while leaving a consuming project’s choice untouched. It also detects equal source/destination extents at runtime and performs per-row memcpy when format and color-key conditions permit, followed by the required opaque-alpha fixup. The recorded follow-up benchmark reduced the same Release case from 0.715 ms to 0.466 ms, or from 29.4 to 14.8 times the raw-copy reference. The remaining gap is mostly the alpha pass; the original 205.8-times row no longer describes a plain standalone configure. The two measurements preserve the before-and-after evidence instead of presenting the discovery result as current performance.

One Blt-family call does require scaling: free-eggbert’s CPixmap::Display() (pixmap.cpp:1509--1516) presents the fixed internal resolution into the window client area. The 1:1 fast path therefore compares the two rectangles at runtime. The audit also found dead code on the game side: free-eggbert’s CPixmap::DrawMap(int, RECT, RECT) (pixmap.cpp:640) has exactly one Blt() call, but no callers of its three-argument signature in the inspected source.

Across both games, the only QueryInterface call belongs to a DirectPlay object. None targets the four DirectDraw classes, whose free-direct implementations return DDERR_UNSUPPORTED. Planet Blupi contains no DirectPlay use, so the DirectPlay scope described in Chapter 60 comes entirely from free-eggbert.

Both games populate PCMWAVEFORMAT, not the larger WAVEFORMATEX. The layouts place wBitsPerSample at different offsets; interpreting the caller’s pointer as WAVEFORMATEX would read padding as the sample depth. free-direct therefore stores a raw void* and interprets these audited calls as PCMWAVEFORMAT. Both games also call SetPan() only on mono effects. That explains why the intended contract was documented as mono-only, but it does not make current panning audible. The implementation computes left/right gains and discards them; only the ordinary volume gain reaches SDL. The tests prove clamping, return values, and no-crash behavior, not an audible stereo split.

free-eggbert’s alternate BASS-backed sound implementation is behind a compile-time flag fixed to false with no build override. Each game also contains a wave-loading source file that only includes itself. Finally, every inspected call to the sound-playback method passes zero for the looping flags. This caller-side result agrees with Chapter 60’s implementation-side conclusion that the two games cannot reach DirectSound looping.

Two narrower searches bounded possible additions. Excluding vendored DirectX 3 SDK headers, neither game calls GetCurrentPosition; free-direct declares only its SetCurrentPosition counterpart. The method remains unimplemented until a target caller requires it. Neither game explicitly requests an 8-bit CreateSurface format either. Together with the 32-bit primary path in §75.2, this means the audited games do not exercise BlitFrom’s silent mixed-depth fallthrough. That behavior remains a limitation, even though adding a new error route was outside the target-driven scope.

The preceding evidence concerns the free-direct compatibility shell. A later cna.md in the inspected free-eggbert working tree, dated 2026-07-16, studies a different question: what would it take to port Free Eggbert directly onto CNA’s Game / GraphicsDevice / SpriteBatch surface, replacing free-direct (and free-api beneath it) rather than merely running through it? That 30,145-byte document was untracked, so it is supplemental evidence outside Appendix  D’s immutable Git pins; the exact inspected copy has SHA-256 87b1e3de041cdbe2af85c8c4b4faf6e74f0e518f9ff72f851f339e5419ceadb3. It reframes the compatibility layer as a migration bridge, not a migration destination — a distinction the analysis itself states plainly: “a CNA application using the FREEDIRECT renderer has adopted the XNA-facing API, but it still transitively depends on free-direct.”

The call-site method produces a narrower compatibility layer than a speculative full-surface implementation, but one aligned with the two target games. It exposed details that an API-only reading could miss, including GetDC’s gameplay role and the PCMWAVEFORMAT layout requirement. For a native CNA port, the same method identifies stable seams, timing assumptions, evidence gaps, and licensing questions before code is moved.