Chapter 77 cna-samples and cna-examples

At commit 149a19f, the repository tracks the official XNA Game Studio 4.0 collection under the Microsoft Permissive License. It expects CNA and sharp-runtime as sibling directories and builds each completed sample as an independent executable.

Its plan accounts for 153 source-archive directories in three populations: 63 completed ports, 23 tracked placeholders, and 67 explicitly ignored entries. The filesystem corroborates the first two numbers: 86 sample directories each carry a missing.md, and 63 contain a sample CMake target. The ignored set covers tools, redundant training material, platform/service-bound programs, and other declared non-targets rather than pretending every archive directory is a portable game.

These are catalog statuses, not fresh run results. “Done” means real port source and a build target exist; it does not mean pixel equality, all original scenes, or all current CNA renderers. The plan itself records the instructive SimpleAnimation correction: an entry already marked done later revealed two CNA graphics defects when re-reviewed. A sample is excellent integration pressure precisely because its behavior crosses boundaries that unit tests may isolate away.

Every tracked sample’s missing.md explains whether it is complete, simplified, blocked, or deliberately scoped. These files record concrete asset substitutions, content-reader gaps, hardware fallbacks, and framework defects found during translation. They are better evidence than a single top-level ratio because they name the affected program and mechanism.

They also age. The pinned top-level plan still says XNB is unsupported, while CNA now has a real XNB stack. Some historical paths point to repositories or layouts that no longer exist. A placeholder must therefore be re-tested against current CNA before it is counted as still blocked. The right workflow is: read the old reason, locate the current API and test, then either port the sample or replace the reason with a new, evidenced boundary.

An official sample combines API calls in the order and lifecycle Microsoft taught users to rely on. That makes it good at finding defects such as default-state mismatch, model winding, component timing, asset transformation, or a renderer path that works in isolation but not in a whole game.

It is not automatically an independent correctness oracle. A C++ translation can misread the C# source, replace assets, skip a scene, or work around a CNA gap. The strongest use pairs the port with the original sample or another implementation, preserves inputs, and compares screenshots or traces. Only two entries in the plan have direct official MonoGame sample counterparts, so that differential opportunity is narrower than the catalog size suggests.

At commit fa0b49a, cna-examples contains one application with 13 areas, 79 categories, and 249 registered demo screens. A read-only run of its tools/check_catalog.py at that pin confirms every screen is defined, registered exactly once, and documented. Areas span framework, math, content, storage, diagnostics, input, audio, devices, networking, media, avatars, and 2D/3D graphics.

The application offers menu navigation, substring search, direct --demo selection, scripted actions, bounded frame counts, and screenshots. This makes a screen useful both to a human exploring the API and to a headless sweep. Global state restoration matters because all screens share one process; the Framework sweep explicitly checks that a resolution-changing demo returns the back buffer to its prior size.

The repository distinguishes several verification forms:

• •

  real hardware interaction for keyboard, mouse, and much of audio;

• •

  Xvfb screenshot/behavior sweeps for Framework and Media;

• •

  C++ claim programs for Math, CNJ, and XACT statements rendered on screen;

• •

  self-checking 3D screens that turn readback or occlusion results into a visible verdict;

• •

  graceful explanatory screens for unavailable controller, touch, sensor, camera, or dialog hardware.

This separation prevents a caught exception from painting a clean explanatory screen and being mistaken for a successful API demonstration. A screenshot checker can detect blank output or overflow; a claim program or self-check must decide whether the described operation was correct.

cna-examples predates CNA’s renderer terminology migration. Its README and build examples use the retired backend-named option with internal value EASYGL; current CNA uses CNA_GRAPHICS_RENDERER with OPENGLES3 or another public identity. The repository’s recorded 249-of-249 EasyGL sweep refers to the implementation family now selected publicly as an EasyGL- backed identity. It must not be copied as a current configure command.

The SDL-renderer sweep remains conceptually useful: its 2D-only capability causes 3D demos to explain their unavailability rather than throw. Yet the recorded sweep is a dated result, not a run performed during this book audit. Revalidation should update selector names first and retain screenshots plus tool output.

For learning, start with cna-examples: one build, searchable screens, current CNA-shaped code, and explicit evidence helpers. For migration risk, inspect cna-samples: original program provenance, per-sample scope records, and failures driven by realistic combinations.

For framework confidence, make the two disagree productively. If a CNA-native screen passes but an official port fails, inspect translation and lifecycle. If both fail across one renderer but pass another, localize the renderer. If both pass yet differ from XNA, bring in a real-XNA or FNA oracle. Examples demonstrate; samples integrate; tests and independent references decide.