Project OutFox has always supported a wide range of hardware, but supporting many systems is not simply a matter of compiling the same renderer everywhere.

Graphics drivers differ between operating systems, vendors and generations of hardware. Even when two systems claim to support the same version of OpenGL, their behaviour is not always identical. Over time, those differences create extra work, platform-specific fixes and faults that can be difficult to reproduce.

To reduce that dependence on desktop OpenGL, OutFox now includes an OpenGL ES 2.0 rendering path.

OpenGL ES uses a smaller and more tightly defined graphics API. It is widely used on embedded systems, single-board computers and other low-power hardware, making it an important part of our support for Raspberry Pi systems and SoC-based devices.

This is not a reduced “mobile version” of OutFox.

The OpenGL ES renderer is part of the same engine and is expected to preserve the established rendering behaviour needed by themes, noteskins and game content. It gives us another supported graphics path for systems where traditional desktop OpenGL is unavailable, unreliable or unnecessarily heavy.

On Windows, we are also developing support through ANGLE.

ANGLE translates OpenGL ES rendering calls into graphics APIs provided more directly by the operating system. Our current Windows work uses Direct3D 11, giving OutFox an alternative to relying on the quality of a machine’s native OpenGL driver.

This matters because Windows OpenGL support is largely controlled by individual graphics vendors. Where those drivers are incomplete, inconsistent or no longer maintained, ANGLE gives us another route to the hardware.

ANGLE can also support other native graphics backends, including Vulkan and Metal. Those provide possible paths for future platform work, but they should not be confused with the backends currently completed and qualified in OutFox.

The aim is not to replace every renderer with one fashionable API.

It is to give OutFox several dependable rendering paths, each suited to the hardware and operating system beneath it:

• Desktop OpenGL for systems where it remains the right choice
• OpenGL ES for embedded, low-power and SoC hardware
• ANGLE through Direct3D 11 for improved consistency on Windows
• Additional ANGLE backends where they become useful and properly tested

For players, this work should be uneventful.

The game should start, render correctly and behave consistently without requiring players to know which graphics translation layer or driver path is being used underneath it.

For the project, however, it means less dependence on one graphics API, fewer vendor-specific surprises, and a stronger base for supporting both modern systems and unusual hardware in the years ahead.