neoGFX: a C++20 app and game engine built around a GPU, still in progress

A framework for apps whose interface is a GPU workload

neoGFX is described as a C++ app and game engine and development platform aimed at app and game developers who want to leverage modern GPUs for performant application user interfaces and game graphics. That framing is the interesting part, because a conventional desktop toolkit treats the interface as a tree of widgets the CPU composites, and neoGFX is built around the idea that the interface is a graphics problem like any other. The feature list for version 1.0 describes a clean modern C++ design leveraging C++20 with full exception safety and support for various widget allocation patterns, including stack, member variable or free store, and standard non-proprietary data types with UTF-8 strings and standard library containers. The stated design principle is no baggage, since the framework is meant to contain only the GUI and graphics functionality needed for apps and games, and the project is GPL-3.0 licensed with the LICENSE and LICENSES directories at the root.

RJSON for the interface, CSS3 for the styling, skins for the theme

The user interface side is where neoGFX differs from a widget library of the 1990s. The full library of widgets and layout managers is specifiable in an RJSON, a relaxed JSON derived declarative UI description language, and that description is drag and drop editable using the included design tool, neoGFX Design Studio. Styling is CSS3 style sheet support with support for custom skins, and there is a simple window style for specifying that a window is nested rather than being a separate native desktop window, with optional MDI support using those nested windows. Several widgets are described in enough detail to show the intent, including a text_edit widget that supports multiple fonts, text colours with optional gradient effects, colour emojis and rendering text in columns, and a GPU shader rendered CSS3 compliant gradient with optional gaussian smoothing. Sub-pixel text rendering is also on the list.

ECS, a scripting engine and assets packed into the binary

The architecture described for games and apps is built on a pure ECS, an entity component system, which the feature list says is usable by both games and apps, along with MVC related classes for app design, and support for 2D, 2.5D and 3D game work covering sprites, objects and physics. Scripting is planned as neos, an engine that will support a wide range of scripting languages, with neoscript, JavaScript and Lua listed for release. Asset management is described as flexible, with texture images such as PNGs stored in zip archives that can optionally be embedded inside the program binary and accessed using simple URLs, which is a real solution to the packaging problem of shipping many textures. Rendering support is listed for OpenGL, DirectX and Vulkan, with a PBR-based 3D rendering pipeline, plus audio with a mixer, frequency shifting and algorithmic oscillators, a tween based animation system, and an animation and audio sequencer. There are also Green and Arcade modes intended to cut CPU power consumption.

The progress table is the honest part of the README

Most of the README is a feature list, but the implementation progress table is what tells you whether any of it exists yet. It is a long per-widget breakdown, and the numbers are revealing. Several widgets are complete, including Message Box, Menu, Tabs, Layout Managers, Label, Button, Line Edit, Spin Box, Check Box, Radio Button, Group Box, Tool Tips, Status Bar, Colour Gradient Selector, Colour Picker and Text Edit at 100 percent, with Table View, Tree View, List View, Text Edit, Slider and Combo Box in the mid to high nineties. Others are clearly unfinished, with MDI and Date/Time at 0, UI and Resource Description at 40, the design tool at 40, Skins at 40, Multi-monitor at 50, Docks and Drag and drop at 75, HID game controller support at 80, Scene Graph at 90 and Window at 95. The table also lists the remaining work per item, such as drop shadow for the Window, selection for Table View, undo and redo for Text Edit, and glob and regex filters for the Combo Box.

The roadmap uses When It's Done plus an offset

The roadmap table is small and unusual in how it schedules. Version 0.99 is marked WID, with Windows OpenGL and Vulkan, a feature complete widget library and the UI design tool. Version 1.00 is WID plus three months, adding Linux OpenGL and Vulkan and the scripting engine. Version 1.10 is WID plus six months with Android support and the physics engine, and version 1.20 is WID plus twelve months with macOS support. The footnote defines WID as When It's Done. Read literally, that means the only dated item is the interval between milestones, not the milestones themselves, and it also means the platform support order is Windows first, then Linux, then Android, then macOS, with no macOS build before roughly a year after the first release. For a project with no published releases, that is a reasonable way to avoid dates it cannot keep, and it is also a signal about how to plan around it.

Building it, and the one platform that is covered

The README does not give a command line for building the project, and the repository layout says where to look instead. There is a BUILDING file at the top level, a build directory, a 3rdparty directory for third party code, an include directory, a src directory, an examples directory with a games example and a mod_tracker example, a testing directory, a tools directory, and a Doxyfile for documentation generation. The only build instruction the README gives directly is a constraint: neoGFX is still a work in progress and is not yet suitable for making apps or games, and it has currently only been built for and tested on Windows. That is the sentence to plan around. A cross-platform framework that runs on one platform is a framework whose portability claims are still a design intention, and the topic tags listing Linux and macOS alongside Windows describe the target matrix rather than a tested one.

Editorial conclusion

neoGFX fits a developer who wants a C++20 framework where the interface is described declaratively in RJSON, styled with CSS3 and rendered on the GPU, and who is willing to track an unfinished project. It does not fit anyone who needs a production framework today, because the README states plainly that it is not yet suitable for making apps or games, and only Windows is covered. Before investing time in it, read the progress table for the features you actually need, check the BUILDING file and the thirdparty directory for what the build expects on your platform, and treat the roadmap ETAs, which are written as When It's Done plus a fixed offset, as intentions rather than dates.

Frequently asked questions

Official sources

1. i42output/neoGFX on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README