Haxe + Libgdx

[Laurent Bedubourg]

Hello there,

For those interested and for reference, here's a simple setup to write
your libgdx game in haxe:

http://labe.me/en/blog/posts/2014-05-05-libgdx-with-haxe.html


See ya
Laurent
--
Laurent Bédubourg
lau...@labe.me
http://labe.me

[j...@justinfront.net]

Oh well done I did not managed to use libgdx yet only the Slick2D and
LWJGL stuff.

I think Caue mentioned something along the lines of your code comment

// this is important,
// in haxe you cannot access java interfaces' static members,
// they are hidden inside a subclass CLASSNAME_Statics,
// must know trick, hope
// it will be fixed soon if not already fixed.

But I had not really understanding the implications in regard to getting
libgdx running.

I would like to avoid gradle dependency did you try running it with an
hxml file only?

Gradle seems a typical example of Java trying to make stuff simple and
ending up making more things to learn, maybe it's a lot better than
older approaches but still not a fan. I started looking at trying to get
a complex as3 Flashdevelop project to build with gradle and it's not at
all clear how to set stuff up.
But FDBuild ( a cross platform terminal tool from flashdevelop ) seemed
much simpler but I did not manage to call it from hxml file.

I was wondering if maybe a better haxe approach to adopting target
specific approaches might be to port FDBuild to haxe ( remove dependency
of Mono to allow it to be neko or... ) and make sure it can handle
libgdx etc... I notice FDBuild has a dependency on some classes in
ProjectManager, but ProjectManager is also full of visual non terminal
aspects - it would be ideal if they were abstracted out of
ProjectManager. Anyway I guess I should start a new thread.

Once again well done on Libgdx did you manage to get some haxe libgdx
running on mobile?

[Cambiata]

Cool!

[Cauê Waneck]

About the `_Statics` problem, I'm afraid there's not a good fix to that problem - Haxe doesn't allow statics on interfaces, while Java does. I think the actual way to "fix" it is to document this behaviour and naming on the manual.

--
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/d/optout.

[Laurent Bedubourg]

I made a few more tests today and encountered a similar problem with
java enums defined inside a class.

I had to import the enum like this to make haxe happy :

import com.badlogic.gdx.graphics.glutils.ShapeRenderer.ShapeRenderer_ShapeType;

No particular problem otherwise, things seems to work as expected.


Concerning gradle, as far as I am concerned, I prefer to keep things
as simple as possible and let the libgdx team do the hard work and
just put haxe on top :)

Because it's a command line tool, I didn't have any problem
integrating it inside my makefiles or even the build.hxml but I can
understand that some IDEs might need some kind of plugin to be happy.

The syntax is not worse than many dependency/build systems I
encountered. Of course it's java world and any process involving
libgdx will have to play with java one day or another. Best to accept
it if you go the haxe/java way I suppose :)

Laurent

[Laurent Bedubourg]

I wrote too fast, importing libgdx Skin class breaks haxe/java support :

import com.badlogic.gdx.scenes.scene2d.ui.Skin;

/Users/lbedubourg/.ivy2/cache/com.badlogicgames.gdx/gdx/jars/gdx-1.2.0.jar@com/badlogic/gdx/utils/ObjectMap$Entries.class:1:
character 0 : Field hasNext has different property access than in
java.util.Iterator (var should be method)
/Users/lbedubourg/.ivy2/cache/com.badlogicgames.gdx/gdx/jars/gdx-1.2.0.jar@com/badlogic/gdx/utils/ObjectMap$Values.class:1:
character 0 : Field hasNext has different property access than in
java.util.Iterator (var should be method)
/Users/lbedubourg/.ivy2/cache/com.badlogicgames.gdx/gdx/jars/gdx-1.2.0.jar@com/badlogic/gdx/utils/ObjectMap$Keys.class:1:
character 0 : Field hasNext has different property access than in
java.util.Iterator (var should be method)

Here's the doc :

http://libgdx.badlogicgames.com/nightlies/docs/api/com/badlogic/gdx/utils/ObjectMap.Entries.html

and the source :

https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/utils/ObjectMap.java

Also is there a way to get access to "MyClass.class" without using
Reflect.field(MyClass, "class") ?

[Laurent Bedubourg]

Do someone on the list know how to add a field using the pathTypes() macro ?

I tried to use

--macro patchTypes('haxe-gdx.patch')

With this:

// remove hasNext member from parent class
-com.badlogic.gdx.utils.ObjectMap_MapIterator.hasNext

// Add a function back? Maybe? Please?
com.badlogic.gdx.utils.ObjectMap_Entries.$hasNext : Bool;


But it did not worked as expected, it removed the var / function
conflict but also removed the hasNext() which is defined in the
Entries class :

Users/lbedubourg/.ivy2/cache/com.badlogicgames.gdx/gdx/jars/gdx-1.2.0.jar@com/badlogic/gdx/utils/ObjectMap$Entries.class:1:
character 0 : Field hasNext needed by java.util.Iterator is missing

(https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/utils/ObjectMap.java)

Thanks for any help
Laurent

[Laurent Bedubourg]

Ok, here's my evening results :

- out of the box haxe/java support: failed

- macro patchTypes: failed

- generating haxe externs from jar: not tested, should work but
current tools doesn't seems practical

- fixing haxe/java ocaml sources: failed (did not found where the
inherited field overwrites sub class method, following ocaml function
calls in the sources is not fun)

- fixing patchTypes ocaml sources: failed (my ocaml traces did not
lead to the result I expected, don't know why and where the hasNext
method disappear when parent hasNext field is removed, still not fun).

- hacking 10 lines of libgdx sources to rename the hasNext field, and
recompiles: success, no more crash

It is possible to use this modified gdx.jar only to make haxe happy
(-java-lib) and then use gradle to compiles with official libgdx.

It's quite unpractical right now but well, it works and should work
out of the box when haxe/java support will be fixed.

If someone wants to do some tests, I just put the jar on Dropbox :
https://dl.dropboxusercontent.com/u/5090326/gdx.jar


Best regards
Laurent

[Cauê Waneck]

Oh that's an annoying problem: even though Haxe/Java accepts overloaded methods, it doesn't support variables with same name as methods.
Normally I give preference to methods - so we avoid not being able to implement interfaces/abstract classes - but in this case I can't, since the hasNext/next functions are only declared on the subclass, so I don't know about that when processing the super class.

I can make it work with patchTypes, but I really would like -java-lib to be the most out-of-the-box as possible.

I could add support for variables + overloaded methods for java native classes, if @Simn and @ncannasse are okay with it. Thoughts?

[Laurent Bedubourg]

Thanks Cauê,

Just to resume, the java structure is the following:

interface Iterable {
function hasNext() : Bool;
}

class A {
var hasNext:Bool;
}

class B extends A implements Iterable {
function hasNext() : Bool;
}

The typer wants to ensure that B implements hasNext() but first
encounters A.hasNext.

What I did not understand yesterday in the ocaml sources is at which
point B.hasNext() is dropped / pushed after the field.

Also, I did not understand why the typePatch removes B.hasNext() but
maybe this method is dropped by the java class Reader ?

Regards
Laurent

[Cauê Waneck]

A lot of processing for java classes are done while a -java-lib class is read. The offending line is at https://github.com/HaxeFoundation/haxe/blob/development/genjava.ml#L2972 . In order to get patchTypes to work, we'd have to somehow check patchTypes info and apply it to this function already.
Of course the best way to deal with that would be to actually allow vars and functions with the same name for java native classes.