Using Haxe with Unity3D | Hacker News Reader

Using Haxe with Unity3D

blog.proletariat.com

33 pointsjdk13 comments

Haxe is kind of a spiritual successor to ActionScript, as envisioned by OCaml developers (the compiler is written in OCaml). It was originally aimed at Flash, but these days it compiles to everything under the sun, and there are libraries like OpenFL (sic) and HaxePunk to take advantage of this for cross-platform game development. That includes native code generation, via C++, for desktop and iOS targets. It's a neat piece of tech.

The previous post on the blog actually talked about WHY we picked Haxe to do client/server development so we didn't have to write a ton of duplicate code. As a bonus, it's just a great language with a good community and active developers.

I'm going to fiddle with that benchmark[1] later this weekend. I have an inkling that some of the languages could have better performance. There is also a difference between a web based game and a traditional application server game.

[1]: http://blog.juiceboxmobile.com/2012/11/20/benchmarking-web-f...

That 20% speed boost on iOS through inlining seems more than reason enough. Can you go in to more detail? Why isn't the C# compiler smart enough to do this?

C# chose to leave this up to the JIT/VM to implement, rather than compiler. Both Microsoft and Mono's .NET runtime will choose to inline functions based on some heuristics. (see http://stackoverflow.com/questions/473782/inline-functions-i...).

However, the (old, forked) version of Mono used by Unity does not appear to inline functions - at least not when using the ahead-of-time compilation required to run on iOS.

Since Haxe looks like it was made with cross-platform gaming in mind, how does it deal with GC issues? How hard is it to use when you have to go into that "no create or destroy" main-loop? I assume this varies depending on target platform.

Haxe is a garbage-collected language, and in general, it uses the GC of the target platform (the C++ target includes a runtime with a conservative collector). So you'll run into the typical issues with writing game code in a GC language - being careful about allocations and deep reference hierarchies, pooling/reusing objects, etc. Haxe doesn't really change anything here.

Haxe does expose some platform-specific features that help though, such as C# structs and pointers/unsafe code, as well as platform-specific API's for interacting with the garbage collector (e.g. http://api.haxe.org/cpp/vm/Gc.html). You can take advantage of these while still writing cross-platform code with the usual tricks of conditional compilation.

GC is required for all Haxe targets. As you suggest, in some cases it's provided through default haxe libraries (on C++), and in other cases it's provided by the runtime (flash, js, etc.)

I've never had it remove something that I needed to rely on via the main loop. It's almost always the opposite (it doesn't remove things or doesn't remove them fast enough, and I have to use object pooling, etc.)

The most important part of this post is the github repository: http://github.com/proletariatgames/HUGS

"This library includes Haxe externs for Unity and .NET frameworks, generated via the cslibgen utility. It also includes the HUGSWrapper "using" class, which includes various things to work around Haxe/C# translation issues, as well as make working with Unity easier."

I FUCKING HATE when the trailer doesn't show ingame play, but useless rendered cgi.

What trailer? How is this relevant to Haxe?

The trailer of the game they are developing using Haxe. The comments doesn't have to be relevant to Haxe. If you go at their homepage you can see the trailer.

Since their goal is to sell the game i think my comment is relevant (maybe harsh by looking at the votes).

Here is the demo we showed at PAX Prime back in August: http://www.youtube.com/watch?v=rj4aa9dhKdo

Reply on news.ycombinator.com