It is another, smaller engine. I would say less featureful than Godot, but I imagine there are some overlapping use-cases?
Ed: and for something quite different - dragon ruby seems a lot of fun (not free, not open source, though): https://dragonruby.org/
The key aspect seems to be that there's a commercial entity behind the project who presumably has console development licenses.
AFAICT none of the console specific source is Open Source but the implication seems to be that the source is (freely?) made available to registered console developers due to the fact the developer of both is a licensed console developer and has decided to make it available to others.
Console development/distribution is mentioned in a couple of places in the documentation[0]:
"The hello.hl file contains bytecode that can be run with the HashLink virtual machine using hl hello.hl. It does give quite good performances and have been proven by successful commercial games such as Northgard or Dead Cells.
However, it is also possible to compile the HashLink code using a native compiler. This allows to compile for consoles and mobile.
This will create a directory out containing a lot of generated C code that needs to be built using a native compiler and linked to the same HashLink runtime[...]"
With regard to console support it says:
"... for Consoles (Nintendo Switch, Sony PS4, Microsoft XBoxOne), please contact us at nicolas @ haxe.org if you are a registered developer for one or several of these"
And here[1]:
"The final resulting shader will then be compiled to the target platform native shader language (HXSL currently supports GLSL for OpenGL, HLSL for DirectX 11+, AGAL for AdobeAir, and PSSL for Sony PS4)."
Also, this post[2] describes how the lower level parts (using Haxe/hashlink) integrate with native (i.e. console) platforms:
"The game gets compiled to a cross-platform .hl file that can be run with HashLinkVM JIT. It can also be compiled to C directly and compiled using any native compiler, which we are using for our console ports on PlayStation, Xbox and Nintendo Switch."
"We also have additional platform API libraries for Steam, as well as console integration libraries that are only accessible if you have a registered developer."
In the same post the Heaps.io console implementation is described:
"This architecture allows us to integrate new renderers or platforms by just porting a few classes given that the native libraries are been made available in HashLink. Heaps.io supports the following plaforms/renderer:
[...]
HashLink/C with NVN (Nintendo Switch SDK native graphics API)
HashLink/C with GNM (PS4 SDK native graphics API)
HashLink/C for Xbox One SDK"
[0] https://heaps.io/documentation/hello-hashlink.html
The exposed console functionality interface can be found via `hl_console`, `usesys` & `usegl` references:
* https://github.com/HaxeFoundation/hashlink/search?q=hl_conso...
* https://github.com/HeapsIO/heaps/search?q=usesys&type=code
* https://github.com/HeapsIO/heaps/search?q=usegl&type=code
The "interesting" pieces are all in some other codebase, e.g.:
* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf...
* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf...
And, if you're a weirdo like me that likes trawling for small console development details (e.g. they treated as ~BSD system) in the code base check out these:
* https://github.com/HeapsIO/heaps/pull/491 (fixes for Nintendo "NVN")
* https://github.com/HaxeFoundation/hashlink/commit/7af111a38f... (PlayStation related naming becomes generic "console" naming)
* https://github.com/HeapsIO/heaps/commit/0daba3517a7193566cd0... (More specific console -> generic changes)
* https://github.com/HaxeFoundation/hashlink/blob/4c4de37d49cf... (Console brand specific defines)
* https://github.com/HeapsIO/heaps/pull/349
I guess it's all sufficiently vague to not break any NDAs. :)
I think my curiosity is now satisfied. :D