Showcase

Pixel-exact against real XNA

CNA maintains an XNA oracle corpus: 39 scenes (256×256, HiDef) under tools/xna-oracle/, with reference images captured by running the genuine Microsoft XNA 4.0 runtime — under Wine with DXVK on Linux, not on Windows. The repository records all 39 scenes as pixel-exact on the DIRECTX9 oracle path — the same Wine and DXVK stack at --tolerance 0, every RGBA channel of every one of the 65,536 pixels per scene.

This is the strongest correctness claim on the site: not "looks right", but byte-identical to what the original runtime produced — for these 39 scenes, on that host. The DIRECTX9 renderer exists largely to make this comparison possible — it uniquely targets pixel-exact XNA 4.0 authenticity. The boundaries matter: the last consolidated dated divergence report covers 31 of the 39 scenes and later per-scene notes record the rest, no 39-scene run was executed for this documentation, the result has not been repeated on native Windows, no CI workflow runs it, and no other renderer is held to this bar — EasyGL and Software have a CTest on two line scenes only (the EasyGL test fails on any pixel difference; the Software test only if a scene does not render), Software was measured at 18 of 39 byte-exact (30 within one channel value), and FNA3D's gate only requires that the scenes render. Seven further unbound-texture scenes and a 17-format channel-expansion table were captured the same way but are outside every diff denominator.

Differential testing against FNA

A real running FNA build lives under tools/fna-reference/ and dumps its observable behaviour as JSON. tools/cna-reference/ produces the C++ counterpart dump, and scripts/compare-fna-reference.py diffs the two — a manual developer workflow covering enums, render-state presets, PackedVector types and Viewport maths, not a CI gate. New since alpha.1: FNA-produced compiled-effect fixtures (reflection, state and 8×8 pixels for seven effects) that CNA's tests replay.

Where XNA's documented behaviour is ambiguous, this settles it empirically instead of by interpretation. A separate compile-time CNAEXT purity check turns non-XNA declarations into [[deprecated]] warnings under -Werror; today it is wired up for the Devices and Sensors namespaces, and a signature-freeze test pins the Input namespace's public API.

Real ported games

Separate projects drive CNA with real game code rather than test harnesses; their figures belong to the repository revision named, not to the documented snapshot:

• cna-craft — about 13,800 lines of C/C++ (cna-lab revision 49e3cd5b): a port of fogleman/Craft, a voxel game, onto CNA.
• cna-extended — about 102,000 lines (revision 5775ecc97): a C++23 port of MonoGame.Extended plus a non-upstream World3DEXT 3D scene layer.
• cna-samples — 91 of Microsoft’s XNA 4.0 samples and games ported to C++ (revision 5db32e6), 90 of them playable in the browser; see below.
• cna-dotnet-samples — the same Microsoft samples as unchanged original C# on CNA.NET: 84 programs built from byte-identical upstream source (revision 1e6d763).

Alongside them, CNA itself ships 25 cna_demo_* programs in its module example directories — 2D, audio, XACT, input, devices, avatar, GamerServices and networking demos — plus cna_house3d_demo and the new cna_inspector_demo.

More checks since alpha.1

The evidence set has grown around the oracle corpus: 32 renderer-neutral parity fixtures are registered for four renderer families (EasyGL, WebGPU, SDL_GPU and Direct3D 11), judged by the fixtures' own assertions rather than by real XNA; a Content Pipeline oracle in which genuine XNA pipeline assemblies produced a 128-type API inventory and a 152-case differential record; a glTF conformance corpus of 148 assets with renderer-owned goldens; and a bounded-memory test runner plus GPU-test isolation that make the very large suite runnable.

These are CNA-recorded results. They establish determinism and regression protection for the named renderers, not equivalence with a reference renderer, and none is run by the repository's workflows.

Port of the original XNA Game Studio 4.0 Primitives Sample demonstrating 2D primitive rendering: lines, triangles, rectangles, and circles drawn using SpriteBatch and procedurally generated textures.

Validates: SpriteBatch.Begin/End, pixel-texture creation, 2D coordinate mapping, and the basic game loop with variable-size window support.

Port of the original XNA Game Studio 4.0 3D Primitives Sample demonstrating 3D shape rendering: box, sphere, cylinder, torus, and teapot primitives rendered with BasicEffect lighting and per-object transform matrices.

Validates: BasicEffect with ambient/diffuse/specular lighting, VertexBuffer/IndexBuffer management, view/projection matrix setup, and the 3D rendering pipeline end-to-end.

Port of the original XNA Game Studio 4.0 Catapult Wars — a complete two-player turn-based artillery game with scoring, animated sprites, and game-state screens.

Validates: a full game loop end-to-end, not just an isolated API — sprite animation, input handling, scoring, and screen transitions working together.

Port of Microsoft's Game State Management sample: a reusable screen-stack framework (menus, gameplay, pause, transitions) used as the foundation for many of the other official XNA sample games.

Validates: a layered GameComponent/screen architecture on top of CNA's Game base class.

Ports of the XNA AI sample pair covering grid-based pathfinding and boid-style flocking/steering behavior, alongside related ports (ChaseAndEvade, WaypointSample, AimingSample, FuzzyLogic).

Validates: math-heavy gameplay code (vectors, steering forces, grid search) ported faithfully from C# to C++23.

Ports covering positional 3D audio playback and touch gesture recognition (tap, drag, pinch, flick) — the two least-graphics-focused corners of the XNA API surface.

Validates: SoundEffect3D-style positional audio and Microsoft::Xna::Framework::Input::Touch gesture handling outside of pure rendering code.