Platform Support

Per-platform status, stated at the level it has actually been verified

Four separate axes

In 0.1.0-alpha.1, “backend” is too ambiguous to be useful. CNA makes four different decisions:

The platform implementation implements CNA::Platform::IPlatform and supplies narrow services to a renderer. It does not decide the renderer, audio implementation or target OS. This is also why the old public CNA::Platform enum became CNA::TargetPlatform: CNA::Platform now names the host-integration namespace.

Platform and audio implementations

# A display-free simulation that still uses SDL3 audio
cmake -S . -B build-headless \
  -DCNA_PLATFORM=HEADLESS \
  -DCNA_AUDIO_PLATFORM=SDL3 \
  -DCNA_GRAPHICS_RENDERER=HEADLESS

# Real SDL 2.30 host plus the low-level SDL2 audio-device selection;
# alpha.1 does not enable its high-level XNA mixer/playback facade
cmake -S . -B build-sdl2 \
  -DCNA_PLATFORM=SDL2 \
  -DCNA_AUDIO_PLATFORM=SDL2 \
  -DCNA_GRAPHICS_RENDERER=OPENGLES3

What "supported" means here

"Supported" is doing a lot of work in most framework documentation. This page avoids the word and names the level instead, because the difference between "there is code for it" and "someone ran it" is exactly the difference that costs you a weekend.

These levels do not imply each other. The repository contains MinGW/Wine paths, but the tag has no automatic MinGW/Wine workflow; the native-Windows lanes also require manual dispatch. macOS has automatic build coverage. Android has source/NDK wiring and no workflow.

Platform matrix

Linux

Linux is CNA's primary development platform and carries most of its CI. It is where the largest number of renderers can be selected, and where the project is developed on real hardware — the default renderer here is OPENGLES3, one of the five EasyGL profiles.

The Windows-gated renderers are also driven from Linux: they are cross-compiled with MinGW-w64 and executed under Wine, so a Linux workstation is in practice the machine where the Direct3D ladder gets exercised too. See Windows for what that does and does not prove.

Practical requirements: the sharp-runtime sibling checkout for every build, easy-gl plus meta-gl for the default renderer, and the FFmpeg development packages, which are mandatory here. Building has the exact commands.

Windows

Windows has the largest platform-exclusive renderer set in the project: 14 renderers refuse to configure anywhere else — the DIRECTX1 to DIRECTX12 ladder plus DIRECT2D, GLIDE and GDI. GLIDE additionally needs a 32-bit i686 toolchain. The default renderer on Windows is SDL_RENDERER.

Two further Windows facts worth knowing before you plan a release:

• There is no video on Windows. FFmpeg is not used on any Windows target and the video translation units are excluded from the build, so Video and VideoPlayer are missing symbols. Calling code compiles and then fails to link.
• The MinGW cross-build itself is not covered by CI. No workflow builds a MinGW target or runs anything under Wine; that path is exercised by hand.

Web (Emscripten)

The web target is real and has automatic browser lanes. Six renderers are Emscripten-only — WEBGL1, WEBGL2, CANVAS, HTML_DOM, SVG_DOM and PIXIJS — and WEBGL2 is the default. Multi-renderer Emscripten jobs also configure and link compatible browser sets.

Video is also absent here, for the same reason as on Windows: the video translation units are excluded from Emscripten builds, so Video/VideoPlayer compile and then fail to link. Networking discovery does not work on Emscripten either.

Serve the generated .html, .js and .wasm from a local web server; browsers block direct file:// access.

macOS

macOS carries the METAL renderer, which drives Apple Metal directly and uses SDL3 only for the window and CAMetalLayer. It is macOS-only, and it is built on a real macos-14 runner on every push and pull request — the one automatic non-Linux native CI job in the project.

Two caveats: METAL throws on custom ShaderEffect shaders, and the CI job is a build, not the full test suite. FFmpeg is a hard requirement on macOS exactly as it is on Linux, so the four development packages must be installed before configuring.

Android

Android is genuinely wired rather than aspirational: the NDK toolchain path works, the code paths exist, and the NDK sensor implementations are real — Compass and Motion are in fact Android-only and report NotSupported elsewhere. See Sensors.

iOS and tvOS

iOS support is experimental and deliberately narrow. The tag ships an iOS toolchain and allows only SDL_RENDERER by default. Apple CI final-links a device application and launches a simulator smoke application for one frame. That establishes configuration, link and simulator startup — not physical-device behavior, input/audio coverage or pixel correctness. CNA_APPLE_ALLOW_UNVALIDATED_RENDERER=ON merely permits experiments outside the allow-list; it is not a support claim. tvOS has no validated path.

What CI actually covers

The tag contains 21 GitHub Actions workflow files. They cover intended general tests, platform conformance, multi-renderer Linux and Emscripten builds, Apple/Metal, declared C API compatibility/release gates, and focused renderer/subsystem checks. Trigger and evidence still matter more than the raw file count. The intended unfiltered general job and two Input matrix rows pass the removed EASYGL value and fail during configuration; the C API final target independently fails its renderer-count assertion.

How to read the matrix

The release has much broader automated coverage than the earlier site snapshot, but a workflow is not universal proof:

• The Windows D3D and GDI lanes remain manual, so their existence is not an automatic merge gate.
• The iOS device lane final-links; the simulator lane launches one smoke frame. Neither establishes physical-device or full-game correctness.
• The Emscripten multi-renderer lane proves configuration and linking, while browser-specific workflows provide the runtime evidence for selected web renderers.
• Android has source and NDK wiring but no automatic workflow in the tag.

Stated plainly: CI exists and spans Linux, macOS and headless-browser jobs, but alpha.1 does not have an effective full-suite gate: its intended general job uses an invalid renderer identity. The GPU pixel/oracle matrix is also run locally, by hand. Verification & Known Issues covers the wider testing picture, and Graphics Renderers the per-renderer side of it.

Where video is available