LumasSDK packages
One engine. Seventeen ways to call it.
Every package is the same native engine with the same documented API. What differs is the language you call it from and the platforms the licence covers. Pick the one that matches how you build.
Not sure? Start from what you are building.
Windows C/C++
The engine as a DLL, with the header and both bitnesses.
Windows on ARM64
A native ARM64 build of the engine for Windows.
Windows ActiveX / COM
A registered COM server, for hosts that cannot call a C DLL.
.NET (source P/Invoke)
The C# and VB.NET bindings as source, plus both engines.
NuGet package
One package, native engines for every runtime identifier.
Linux on Intel
Shared objects for 64-bit and 32-bit Intel Linux.
Linux on ARM
Shared objects for 64-bit and 32-bit ARM Linux.
macOS
One universal dylib covering Intel and Apple Silicon.
Android
Shared objects for all four Android ABIs.
PHP
A pure-PHP binding over FFI: no compiled extension to match.
Python
A ctypes binding: no compiled module, no build step.
Delphi / Object Pascal
Two bindings: the flat DLL unit and an object wrapper.
ASP.NET Core
A self-contained web sample with the package bundled.
Flutter
A dart:ffi package with natives for five platforms.
Node.js
A JavaScript binding with TypeScript declarations included.
TypeScript
The Node binding with a typed surface and a TS example.
Why a package per platform, and not one big download
A package is not a marketing category. The licence key carries which one you bought, and the engine refuses that key on a platform the package does not cover — so the download and the licence always describe the same thing. It also means you are not paying for six platforms to ship on one.
Every platform list on this site is generated from the engine and the release artifacts, which is why they occasionally disagree with each other in public: where a download contains a binary the licence does not authorise, the page says so rather than choosing the flattering half.