What are the difference of purpose between "hxcpp-cppia" and "HashLink-HL/C"?

Dragnalith · June 11, 2021, 7:48am

Hello,

I am working for a game studio and we are looking for a scripting solution to use with our internal engine.
We are looking for a solution to isolate and hot-reload gameplay code during development but to compile it in native code for release.

I did not dig into the detail yet, but it seems hxcpp and HashLink are offering a similar solution:

They both provide an haxe runtime written in C/C++
They both provide a way to compile haxe to C/C++
They both provide a way to execute haxe code dynamically (cppia and HashLink VM)
They both proved they can ship games
They are both official project from Haxe Foundation
They both provide IDE debugging feature

If two similar solutions exist, I guess it means they are chasing different purposes somehow. What are those different purposes?
Can I be comfortable to using one or the other solution? What information am I missing to prefer one to the other? (roadmap, maturity, long-term support, etc.)

Thank you

back2dos · June 12, 2021, 10:51am

For starters, please compare the compile times and runtime performance (for CPU bound operations) on targets relevant to the context of this question: Haxe formatter_noio benchmark

The answer as to why there are two solutions is grounded in history. IIRC way back when ShiroGames began shipping their first game (AFAIK based on what would later become Heaps) targeting Adobe AIR, which at the time was probably the best sweet spot between compile times and performance.

AIR itself was on its way out and didn’t perform that well. JavaScript would’ve been an option, either with WebGL in node-webkit/electron or nodejs + OpenGL bindings (or some such thing). WebGL is a bit of a moving target. And making OpenGl bindings for nodejs isn’t much fun either (also I’m not 100% Nicolas has overcome his skepticism towards nodejs). Neko was certainly not going to provide the necessary performance, because by design it was a runtime for dynamic languages (meaning all the strictness Haxe imposes goes to waste). I’m not sure how mature cppia was at this point (I suppose it was about 1-2 years old at the time). And last but not least: creating a VM specifically tailored for the language you’ve created must be a fun thing to do for people who enjoy that kind of work.

The results:

In HashLink, the interpreted mode’s runtime speed is reasonably close to compiled mode. AFAIK Shiro actually runs shipped games on it, because the difference is negligible enough, but using an interpreter has its own advantages.

In cpp+cppia the difference between compile times and execution speed are further apart. The intended use of cppia is to prebuild a “host” with cpp (that has all the performance critical code in it) and load cppia scripts into that. If done correctly, you can basically have the speed of cpp and the compile times of cppia (and again having an interpreter opens up various possibilities). And you can still compile the whole thing as cpp.

As for deciding for one over the other, it’s a matter of choosing an eco system:

HashLink is part of a rather tightly integrated stack centered around Heaps, which also offers its own editor. It definitely supports asset reloading and perhaps even for code (no idea though). OTOH I’m not 100% about native support for iOS and Android (see iOS and Android support · Issue #422 · HeapsIO/heaps · GitHub). That said, at least two high profile Heaps games have been ported to mobile, so it can’t be impossible.
HXCPP gives you access to the C++ eco system. You can use it with OpenFl and all the things built around it, or with Proletariat Games’ bindings for the Unreal Engine which allows live reloading Haxe code via cppia. There’s a gazillion of other stuff floating around, like Armory 3D based in turn on Kha which supports fancy things like shader debugging. This works by running Kha on JavaScript (no WebGL though), which should make live reloading easy enough.

So yeah: they are both fine. You’ll need to pick the tools (frameworks/editors/libraries/…) you want to use and then one runtime or the other will make for a better fit.

RobDangerous · June 12, 2021, 4:10pm

Little correction - Kha supports both but prioritizes HXCPP and Armory3D nowadays uses HashLink instead of HXCPP. Using HashLink you can also access the C+±eco-system, it’s just not as convenient or performant. Also of note - HashLink with Immix GC (aka the other HashLink thing on that benchmark page) is still rather crashy AFAIK.

nanjizal · June 12, 2021, 7:37pm

My thoughts following back2dos explaination.

I would suggest that they are two approaches developed for two different haxe toolkits by two haxe core developers, ie to allow rapid compile without requiring a full haxe C++ compile for thier game toolkit projects… essentially they do a similar task in different ways ( so different types of wheel! ).

Cppia was created by Hugh to help with NME, and is a script ( like txt file ) that is loaded into C++ at runtime and actioned.

HashLink was created by Nicolas to help with Heaps, conceptually it’s a static replacement for Neko, and is a VM along the lines of LLVM, so it actually uses reduced range of codes for number types compared to LLVM, so more low level?

github.com

HaxeFoundation/hashlink/blob/master/src/std/types.c#L44

    
      
          HL_PRIM hl_type hlt_abstract = { HABSTRACT, {USTR("<abstract>")} };

          

          static const uchar *TSTR[] = {

          	USTR("void"), USTR("i8"), USTR("i16"), USTR("i32"), USTR("i64"), USTR("f32"), USTR("f64"),

          	USTR("bool"), USTR("bytes"), USTR("dynamic"), NULL, NULL,

          	USTR("array"), USTR("type"), NULL, NULL, USTR("dynobj"),

          	NULL, NULL, NULL, NULL, NULL

          };

          

          static int T_SIZES[] = {

          	0, // VOID

          	1, // I8

          	2, // I16

          	4, // I32

          	8, // I64

          	4, // F32

          	8, // F64

          	sizeof(bool), // BOOL

          	HL_WSIZE, // BYTES

          	HL_WSIZE, // DYN

          	HL_WSIZE, // FUN

In theory you don’t have to choose one. For instance if you are just dealing with Maths you can use either very easily, here is an example of related hxml files that can be used for using the Test frameworks for Thomas’s math library.

github.com

nanjizal/hxmath/blob/dualQuaternions/test_cppia.hxml

-cp .
-main Test
-lib nanotest
-dce full
-cppia test.cppia
-cmd mkdir -p bin/cppia
-cmd mv test.cppia bin/cppia/test.cppia
-D EXIT_ON_FINISH

From my understanding OpenFL does not currently have any examples of using Cppia, and Hashlink seems to have some support, but sometimes broken, but depending on what you need from OpenFL you can just switch to NME easily with re-maps. Although I found this Stencyl version of Acadnme which may help with adding OpenFL Cppia?

Armory a blender plugin for Kha seems to use HashLink extensively, but seems more effort to use HashLink from Kha directly, since Kha tends to favour fast js ( Krom kind of like v8 ). Krom in theory could be used by all toolkits perhaps but nothing is setup, apparently it compares well.

NME seems to have quite good ios and android support and Cppia normally works where ever hxcpp works, so cppia probably also has rasberry PI support, or any toolkit that can use haxe c++. Officially you can’t use Cppia on apple IOS as they don’t allow scripts, because they like to have super control and cause developers headaches!

HashLink was not designed for multiple architectures so support can be more limited for aspect like PI, and you likely find it effort to setup on ios/android.

For testing android with NME toolkit you can send cppia scripts to ‘acadnme’ for running directly on the device. NME works well but does not seem to be a mainstream toolkit, but Hugh mac support seems good. Cppia suffers greatly on documentation and widespread use but I have normally found it works everywhere that haxe c++ does.

Likely you could also look at JVM target for android I am not sure if anyone has looked at possiblity of loading at runtime.

I guess the cool thing with Haxe is Cppia or HashLink can in theory both be used by any haxe toolkit just by adjusting the build files and tweaking the source files so you can use which ever seems most suited to your use ( either cpp core with cppia mods or HashLink running slightly behind c++, not sure of ease to load in hl scripts to hl project at runtime ), reality is that if you want to use NME then Cppia is great if you want to use Heaps HashLink is great. If you have good low level developer resources you could likely work on improving everything for all toolkits, there is no reason I know of that all toolkits could not support hashlink and cppia equally ( heaps used to support hxcpp ), they just don’t currently.

nanjizal · June 12, 2021, 7:44pm

Another option is hscript I believe there has been some extensions to allow it greater power.

nanjizal · June 12, 2021, 7:54pm

In terms of long term support:
NME uses Cppia extensively and Hugh is the main c++ developer so it is unlikely to disappear, even if only a handful of developers use NME successfully for games it’s development goes hand in hand with haxe c++.

Nicolas is inventor of Haxe, and HashLink is his replacement for his former Neko VM. Neko kind of predates Haxe I think evolving from the early days of mtasc2 compiler. Currently HashLink does not do Web like Neko so likely Neko will not disappear that quickly but its had atleast 15 years. So I think you could guess that HL may remain in a similar form for atleast a decade?

Since both are compiled from Haxe, long term support is not an issue, as backend alternatives should be suitable to swap easily. Apart from HashLink having no Tora option, HashLink can be easily swapped out for Neko so any code written originally in Neko runs fine in HashLink ( accept the mod_neko, mod_tora stuff ), and in theory you could compile heaps to Neko I am not sure if that is currently maintained, and perhaps you could create mod_hl_tora?

I suspect that longterm Haxe is a better bet than many mainstream languages driven by corporate entities, suspect Haxe will outlive both TS and Swift, which will eventually need reinventing by Microsoft and Apple, although I wonder if Haxe will ever reach same popularity. Neko was not discontinued but upgraded to HashLink, but both use virtually the same haxe code.

RobDangerous · June 12, 2021, 9:52pm

The paragraph about Armory and Kha was complete nonsense. Not sure about the other paragraphs.

nanjizal · June 22, 2021, 2:25pm

Sorry Dragnalith, my understanding and knowledge maybe out of date and not as factual as some would like, hopefully there is some ideas in there that are useful.

Likely your not interested in Kha; it seems largely irrelevant to your question, I shouldn’t have bothered bring it up.