C# FieldLookup and Haxe-generated DLL assemblies

[Dan Korostelev]

Hey guys!

I'm now using Haxe to create shared logic for our Unity-based game, so I'm talking about C# target.

I'm pretty happy with the current results, not counting the nasty Float comparison bug (https://github.com/HaxeFoundation/haxe/issues/2051), which took me some time to find. hope it will be fixed in a new Haxe release. For the time being, I copy-pasted Runtime.hx file from cs library and fixed it in my application.

Now to my main question. As far as I understood, when compiling Haxe to C# code, code generator finds usages of every field and creates an integer hash for it for fast field access and embeds it to the FieldLookup class. Which seems to be a nice optimization.

However I got a case where this gets in the way a bit: I tried to compile a DLL with basic Haxe runtime classes, with the intention of including this DLL in application, then compiling another DLL from Haxe-generated sources referencing that basic runtime DLL.

This way I could load Haxe-generated DLL (with game shared logic) with Assembly.Load and use classes without need for reflection (because all base classes, like HxObject, DynamicObject and Array are already there in the basic runtime DLL compiled in my application).

But unfortunately won't work, because Haxe-generated code relies heavily on the FieldLookup class and tries to find field name hashes in it. And because we use FieldLookup class from our basic runtime dll, it doesn't know anything about field names in the DLL assembly I am loading.

Probably there should be an option to generate field hashes for the code being compiled in some custom class and a method to merge them in FieldLookup at runtime if possible.

For now I am using reflection-based wrapper classes in my application which works as well, but using the classes directly would be much better for sure.

I actually created an issue first: https://github.com/HaxeFoundation/haxe/issues/2053, but then I thought it may worth a discussion, so I wrote here as well.

[Cauê Waneck]

Hi Dan!

2013/8/6 Dan Korostelev <nad...@gmail.com>

I'm now using Haxe to create shared logic for our Unity-based game, so I'm talking about C# target.

I'm really happy to see the C# target being used for Unity development! 

I'm pretty happy with the current results, not counting the nasty Float comparison bug (https://github.com/HaxeFoundation/haxe/issues/2051), which took me some time to find. hope it will be fixed in a new Haxe release. For the time being, I copy-pasted Runtime.hx file from cs library and fixed it in my application.

I'll take care of it for Haxe 3.1 :) 

I actually created an issue first: https://github.com/HaxeFoundation/haxe/issues/2053, but then I thought it may worth a discussion, so I wrote here as well.

 

I figured this would fail. Can you add a small reproducible case with the bug report, and I'll fix it for the next release. I think you're right, and it's probably just generating a unique class, which will register the hashes to FIeldLookup,

I've been receiving a lot feedback regarding using Haxe with Unity 3d, and I have all interest to best support it. Let me know any other suggestions that you might have.

Thanks!

Cauê

[Marcelo Serpa]

Exciting stuff!

-- 

Marcelo

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dan Korostelev]

вторник, 6 августа 2013 г., 20:46:46 UTC+4 пользователь Cauê Waneck написал:

I'm really happy to see the C# target being used for Unity development! 

In our case Haxe with its C# target turns out to be great help. We had JS-based logic, shared between client (unity with embedded native js interpeter) and server (nodejs), but on unity web player, we haven't found an efficient way to run our js as is. So we ported it to Haxe and compiling it directly to .NET assembly for the web player, and to JS for others (we are considering using assembly on all platforms that support dynamic loading). Works great so far, not to mention Haxe is so much better of a language than JS.

 

I actually created an issue first: https://github.com/HaxeFoundation/haxe/issues/2053, but then I thought it may worth a discussion, so I wrote here as well.

 

I figured this would fail. Can you add a small reproducible case with the bug report, and I'll fix it for the next release. I think you're right, and it's probably just generating a unique class, which will register the hashes to FIeldLookup,

I tried just now, but I must be doing something wrong, coz it works in my minimal example. But I'll prepare reproducible one and attach it to the issue sometime soon when I have time.

I've been receiving a lot feedback regarding using Haxe with Unity 3d, and I have all interest to best support it. Let me know any other suggestions that you might have.

Thanks for all your great work. I'll report any suggestions and issues for sure.

[Cauê Waneck]

Hi!

2013/8/7 Dan Korostelev <nad...@gmail.com>

In our case Haxe with its C# target turns out to be great help. We had JS-based logic, shared between client (unity with embedded native js interpeter) and server (nodejs), but on unity web player, we haven't found an efficient way to run our js as is. So we ported it to Haxe and compiling it directly to .NET assembly for the web player, and to JS for others (we are considering using assembly on all platforms that support dynamic loading). Works great so far, not to mention Haxe is so much better of a language than JS.

That's awesome! :)

I tried just now, but I must be doing something wrong, coz it works in my minimal example. But I'll prepare reproducible one and attach it to the issue sometime soon when I have time.

I'll put the issue on hold till we get an example going, ok?

Thanks for all your great work. I'll report any suggestions and issues for sure.

Great! ;)

Thanks!

Cauê