Norx is my Nim binding for ORX, a 2.5D game engine written in C99. I wanted to make games again — the last time was on a C64 in the eighties — and ORX was the engine that fit: fast, portable, small, and with a friendly and capable maintainer. But C is not what I want to write game logic in, and ORX is small enough that wrapping it properly is realistic. So I wrapped it.
The wrapper is mostly generated. wrapper.nim comes out of the ORX headers
via Futhark, so it tracks the engine
automatically and covers everything the shared library exports. On top sit
hand-written modules — basics, vector, objects and the small subsystem
files — that add Nim types, overloads, templates and converters, so the
generated layer becomes pleasant to actually use. An annotation mechanism makes
it easier to spot when an upstream ORX change needs the hand-written layer
revisited.
norx.nim is the one module you import; it re-exports the rest, including the
low-level wrapper when you want to reach straight through to the C API.
- Mostly generated — the binding is derived from the ORX headers, so it stays current with the engine instead of rotting.
- Idiomatic on top — Nim types and macros over the C API, while the low level stays available.
- Data-driven like ORX — a lot of behaviour lives in readable
.inifiles rather than code. - Batteries included — ORX covers graphics, audio, input and physics in one library, under the zlib licence.
- No system install — tests and samples link and run against the in-repo
ORX build, with an embedded rpath, so nothing needs
sudo.