Which language will perform better in Armory


#1

Which language should I use for better run time performance for games in Armory? Hex or Rust?


#2

It doesn’t matter, since the code you are typing is going to be compiled to your target’s platform’s language and there is no real/huge difference of run-time performance between Krom and C++, and the speed of html5 is good too.
HTML5 has multi-threading but i don’t think Krom and C++ has multi-threading support or do they? not sure


#3

It looks like C++ ( Kore ) has multi-threading:

I don’t think Krom does right now, but I would think that the potential is there if HTML5 supports it.

I think WASM has the potential to be better optimized than plain Javascript if the code you write takes advantage of the lower level control. The same if you could manage to bind Rust to Armory for Armory’s C target.


#4

Do I have to manually compile Rust to WASM or will it do it all automatically as soon as I click the play button? (sorry I am new I don’t understand much just yet)?


#5

You’ll have to do it manually. Check out this from the docs: Programming Armory in Rust.


#6

Can I summit a suggestion to make it all automatic?


#7

Sure, maybe just sum it up as a full Rust integration feature.


#8

Armory relies on the Haxe language to produce the final product, and Haxe can work in one of several ways. It can produce byte-code directly in some cases, whereas in others it produces source-code (e.g. in C++) that is then compiled using the native SDK for that particular “target.” Everything that you do in Armory is translated into Haxe. Let Haxe do the work of preparing your final game on whatever target you select.

“Performance” is often more a characteristic of how well your game is designed, than of what a particular target is. Even an “inefficient” target, e.g. JavaScript, actually has a comparatively fast implementation (and close, low-level integration with the graphics hardware) such that it probably won’t add much runtime to your game.


#9

Armory never produces bytecode, it only supports Haxe’s JavaScript and HLC targets. And JavaScript is the most efficient target last I heard.


#10

Armory only supports certain targets (now …), but the Haxe language itself supports many more, and for some of these it produces a binary rather than source-code output.

Of course, as you say, this doesn’t mean that you can simply send a particular application to “any target that you want,” especially in the case of something like Armory, since the requisite low-level interfaces (to hardware) do not exist or are not yet implemented in every case. Language designers and “porters” have to build-out the necessary foundations when “porting” something to a new target such that Haxe can then generate for it.

And yet, in most practical situations, targets such as JavaScript, NME, WebAssembly and so-forth work just fine, because the “overhead” of the runtime engine is negligible. The deliverable file is much smaller because “the runtime (and all its cruft) is already installed on the computer and so doesn’t have to be shipped,” as it would be with a purely stand-alone binary. SABs simply have no functional advantage. “If your game is slow, the problem’s probably in your logic, not the runtime.” JavaScript can be implemented very efficiently.