Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Example project #1

Closed
czyzby opened this issue May 23, 2016 · 27 comments
Closed

Example project #1

czyzby opened this issue May 23, 2016 · 27 comments

Comments

@czyzby
Copy link

czyzby commented May 23, 2016

It would be great if you provided some documentation and an example project using Gradle. I'm curious if you can just include another backend to an existing LibGDX application and run it out of the box. A Gradle script/plugin with multiple prepared tasks (runDesktop, distDesktop, runHtml, etc.) would be nice.

May I ask if Java reflection API is supported on every platform, including JavaScript/HTML5? This is necessary for multiple libraries and LibGDX functionalities to work properly.

@soywiz
Copy link
Contributor

soywiz commented May 23, 2016

I still have to create a Gradle plugin: I will try to create it this week: jtransc/jtransc#36

Right now the supported way for building is maven. You can find information here: https://github.com/jtransc/jtransc/wiki/Available-Maven-Options

There is a target configuration for the maven plugin that allows you to choose the target. So I suppose it would be possible to add those tasks to gradle.

Note: right now, Javascript target fully works, but C++ target seems to be working, but doesn't display anything, just shows glClear. I'm going to try to fix that ASAP too.

And yes. Java reflection works everywhere including Javascript. The default behaviour is to include reflection information for everything, but you can opt-out per class and per member. ( https://github.com/jtransc/jtransc/wiki/JTransc-Annotations#general @JTranscInvisible and @JTranscInvisibleExternal)

@czyzby
Copy link
Author

czyzby commented May 23, 2016

Gradle plugin would certainly be appreciated, as LibGDX setup tool generates Gradle-based projects. Using Maven seems like a huge step backwards, so I can imagine people (including myself, to be honest) would be reluctant to switch from Gradle.

JTransc (is that how you should write that?) seems like a great alternative to GWT and I'd like to include it in our alternative gdx-setup tool.

It would be nice if you ran some benchmarks - I'm really curious about the performance. If Haxe/Lime turns out to be faster than Java, maybe we could let go of some official platforms in our new projects. How's the native APIs interface though - can you easily access native methods on Android, iOS and HTML5?

What about Windows Phone? I know that people tried to use GWT platform to generate Windows Phone apps, but its WebGL implementation seems to be problematic. If Lime supports Windows Phone, this would potentially be the best way of creating Windows Phone apps with LibGDX.

@soywiz
Copy link
Contributor

soywiz commented May 23, 2016

Great. I'm working on the gradle plugin already and then I will check the C++ black screen.

Yep I usually write JTransc or just jtransc that is ok too.

I didn't know about the gdx-setup alternative. I will check it!

Regarding to performance:
I didn't run benchmarks yet.
For runtime performance I still have to improve the "relooper", or just use gotos when targeting haxe-C++. So right now there is overhead here right now. But this will improve in coming weeks.
JTransc provide some APIs for cross-platform fast memory, and will support SIMD eventually on supported targets (including javascript when available).
Startup time should be fast, since it is an AOT.
Lime is just a layer of multiplatform rendering. So it ends calling raw OpenGL/GLES/WebGL calls in just a two or three native calls, so the overhead here should be negligible.

Regarding to native interoperability.

You can add include and call C/Objective-C files:
https://github.com/jtransc/jtransc-examples/blob/master/cpp/src/example/Test.java

For native android or ios: you can also include Haxe code and use cooked haxe libraries. For example a facebook library for android and ios. Or use lime-provided JNI calls:
https://github.com/jtransc/jtransc-media/blob/master/jtransc-media-lime/resources/HaxeLimeLanguage.hx
We were going to do that.

You can also use JNA for desktop and node.js (not tested on mobile): https://github.com/jtransc/jtransc-examples/blob/master/ffi/src/main/java/BeepExample.java

The idea is to support native calls just with annotations similar to JNA or how C# works. But it is still not the case.

@czyzby
Copy link
Author

czyzby commented May 23, 2016

Looking great so far. I'm eager to check it out with my existing LibGDX projects. Let me know when you're done with the Gradle plugin and a (somewhat) stable version is uploaded, so I can include it in gdx-setup.

@soywiz
Copy link
Contributor

soywiz commented May 23, 2016

I have already added gradle support:
https://github.com/jtransc/jtransc/wiki/Gradle

Still not checked the black screen part. Going to do that now.

I do not have too much experience on gradle, so if you can provide feedback about it. It would be great.

The approach I followed:

A plugin:

apply plugin: "jtransc"
buildscript { dependencies {  classpath "com.jtransc:jtransc-gradle-plugin:0.2.5" } }

The plugin requires applying "java" and "application" plugin.
The plugin provides a extension "jtransc" that allows to configure as maven plugin does.

jtransc {
    minimizedNames = true
}

There are a couple of generic build tasks "JTransBuildTask" and "JTransBuildAndRunTask" for building and building and running. So you can do this (and necessary since JTransc support arbitrary targets that can be defined later):

task windows(type: JTransBuildTask) {
    target = "haxe:cpp"
    outputFile = "program.exe"
    minimizedNames = false
}

task runWindows(type: JTransBuildAndRunTask) {
    target = "haxe:cpp"
    outputFile = "program.exe"
    minimizedNames = false
}

I have defined some generic tasks:
js, swf, cpp, neko, php for building to those targets.
And jtransc that will get the target from jtransc { ... } extension. Also allows to provide target and outputFile as parameters.

Then for running:
runNodeJs, runSwf, runCpp, runNeko, runPhp
And runJtransc ditto from above.


What do you think about it? Good enough for you? Any feedback about this?

@czyzby
Copy link
Author

czyzby commented May 23, 2016

I suggest refactoring js, swf, cpp, neko, php to compileJs, compileSwf or distJs (and so on). Java already defines compile task, and this prefix seems to be used by multiple plugins, including Kotlin (compileKotlin). dist might be more appropriate, as it builds the complete application and would match the distribution plugin (distTar, distZip). Leaving the choice up to you.

I think there's a typo:

    // tittle = "App Title"

Other than that, I don't really have time to look through your plugin code, but the public API looks OK. Would be nice if you made a similar wiki page on this repository and basically excluded the tasks and fields that don't really affect LibGDX applications and are specific to JTransc in general. For example, I don't imagine LibGDX can be run using PHP. (Can it though?)

As for gdx-setup, I think that the black screen bug might be a little discouraging and we should wait until you push a new release.

Either you overlooked my question or I missed your answer - what about Windows Phone? Is it supported?

soywiz added a commit that referenced this issue May 23, 2016
Added build.gradle example for cuboc
soywiz added a commit to jtransc/jtransc that referenced this issue May 24, 2016
Float.floatToIntBits was optimized wrong just when targetting C++ (and sadly C++ target is not being tested on travis so never noticed)

#34
jtransc/gdx-backend-jtransc#1
@soywiz
Copy link
Contributor

soywiz commented May 24, 2016

Fixed black screen too on C++. Also, did the refactoring you said.

This should work on the cuboc demo.

gradle runHtml5
gradle distWindows
gradle distAndroid

runXXX generate debug builds by default
and distXXX generate release builds by default

runHtml5 says that it has failed, but should generate build\jtransc-haxe\export\debug\html5\bin folder.
If you run a http_server in there, you should be able to get it working on the browser.

Haxe C++ debug builds are slow as hell, and it is known. Release builds are much faster.

I was able to generate cuboc for javascript, windows and android sucessfully with the gradle plugin.

Please, test it and provide feedback, PRs are welcome too.

@czyzby
Copy link
Author

czyzby commented May 24, 2016

I'll try including JTransc backend in gdx-setup ASAP and run our project templates.

@czyzby
Copy link
Author

czyzby commented May 24, 2016

I suggest focusing on platforms that are somehow flawed or unavailable for LibGDX. Being able to compile your Java application to native code on desktop is a nice touch, but it also adds another layer of complexity - and all this for something that we already have. 2D games - at with LibGDX is arguably the best - are already blazing fast on desktop, so I'm not sure if a new platform is really needed there. Especially since you can use Kotlin (and so on) there without any problems.

Anyway, I don't think Flash matters anymore, but being able to use different JVM languages and reflection, and yet still target JS/HTML5 seems amazing. On the other hand, from what I can see Android applications are already pretty easy to port to Tizen, so there's not much incentive there. To be honest, I would personally use JTransc only for WebGL and maybe the iOS platforms (because of the whole mess with RoboVM).

Being able to create LibGDX applications for Windows Phone would certainly bring you a lot of users. I know it's most likely too late to switch Haxe framework now, but is there any possibility that JTransc could target additional platforms?

@czyzby
Copy link
Author

czyzby commented May 24, 2016

As for the example project - I tried running it, but I keep on getting this error:

* What went wrong:
Execution failed for task ':runNeko'.
> java.io.FileNotFoundException: /home/mj/.m2/repository/com/jtransc/jtransc-rt/0.2.6/jtransc-rt-0.2.6.jar (No such file or directory)

Should the jar be on Maven Central or should I add some other repository? That's kind of weird error, as Gradle seems to keep its own dependencies in another folder and does not rely on Maven cache. Are you sure you don't reference it directly somehow? (And yes, this error appears when trying to run other tasks as well.) Or maybe should I go through some setup before using JTransc?

Anyway, Gradle script does not work in its current state because of this line: https://github.com/jtransc/gdx-backend-jtransc/blob/master/cuboc-demo/build.gradle#L24
ext.jtranscVersion = "0.2.6" is ignored in buildscript block, as buildscript is evaluated first and seem to have its own variables. You can resolve this by duplicating ext.jtranscVersion = "0.2.6" line and putting it in buildscript or adding gradle.properties file and removing the variable from Gradle file altogether:

jtranscVersion=0.2.6

Maybe I should have started with this - what exactly do I need to start using JTransc? Haxe, some Lime dependencies? A short tutorial with some links where to download what should be great.

@soywiz
Copy link
Contributor

soywiz commented May 24, 2016

First part:
Sure, desktop target doesn't have too much use. But since haxe/lime already handles them, supporting them is for free. Also to test C++ targets, is easy to test before on desktop and then in mobile.

We are still using flash. And we need it to be able to do some integrations with legacy code. It would be great if flash was dead, but that's not actually the case. Also there is Adobe AIR. Though Actionscript3 is pretty bad, not not the case if using haxe or a jvm language.
Not sure about tizen. I know that lime supports tizen and webos. But also I think supports (at least internally) xbox/one, ps3/4 and wii u. Not tested myself.

Lime started to do some tests with angle for WP: https://github.com/openfl/lime/wiki/Windows#future

There is also kha for haxe: http://kha.tech/
That supports more stuff including WP. But it has a different approach. Gdx relies heavily on OpenGL API. Kha is much more portable. Maybe I will investigate it in the future for https://github.com/jtransc/jtransc-media

Now I want to focus on ensure things are working and optimizing.


Second:

Sh** I forgot that jtransc tries to get the RT from local maven repository (and the maven plugin ensures it download it). In gradle I should tell it to download it from mavenCentral and get rt and core jar paths.

Do you know how to do that?

I will try to test it on travis to avoid problems on clean machines. Since I have it installed on my local maven repository it worked for me.

I will follow the gradle.properties indications.

soywiz added a commit to jtransc/jtransc that referenced this issue May 25, 2016
Try to fix gradle downloading and using jtransc-rt and jtransc-rt-core
@soywiz
Copy link
Contributor

soywiz commented May 25, 2016

It should be fixed already jtransc/jtransc@4ee667d . Tomorrow I will release 0.2.7 so you can test it again.

@soywiz
Copy link
Contributor

soywiz commented May 25, 2016

I have released 0.2.7 version. That includes gradle fixes + #2

It will be available soon in central: http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22gdx-backend-jtransc%22

Please, can you try gradle runHtml5? It should open a browser with cuboc running.
That should work for runWindows, runAndroid and so on.

Also note that right now jtransc requires haxe to be previously installed. In next versions I will try to download it if not installed.

Please, let me know if you find any additional issues with gradle. Since just tested on my machine.

Also not implemented the whole GDX stuff yet, so test other demos/games and report any issues.
Also note that right now jtransc uses a custom RT and not all classes are included, so report that too in the case something fails because misses some classes. That will improve greatly in a near future after implementing this: jtransc/jtransc#27

@czyzby
Copy link
Author

czyzby commented May 26, 2016

It would be great if LibGDX was transpiled to Haxe/Kha and run on pretty much anything there is, but I understand that's a lot of work.

I'll look into the examples today.

@soywiz
Copy link
Contributor

soywiz commented May 26, 2016

The "problem" with kha is that it is platform agnostic, while libgdx depends on a opengl-like api to be available. And specific -> platform-agnostic is hard.
I could create a library to leverage kha, but that wouldn't work with gdx libraries and with existant code.

The other approach is to emulate shaders and have a state-machine, like I'm going to try here: #3

That could work.

Also having a pure-java parser for GLSL would allow me to target to flash or even to kha/directx. Maybe there is already a lighweight GLSL pure-java parser out there?

BTW:

@czyzby
Copy link
Author

czyzby commented May 26, 2016

I have installed Haxe. I'm trying to run the Cuboc example and I'm still getting some errors.

  • runCpp:
Error: Could not find haxelib "hxcpp", does it need to be installed?
ERROR (30542) (1)
:runCpp FAILED
  • runNeko:
Uncaught exception - std@module_read
ERROR (35563) (1)
:runNeko FAILED
  • runNodeJs is not defined, seems like to misspelled task name in gradle.build comments or forgot to add it.
  • runPhp:
Error: "php" is an unknown target
ERROR (200) (1)
:runPhp FAILED
  • runSwf:
src/HaxeLimeGdxApplication.hx:166: characters 16-18 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:167: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:175: characters 15-17 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:176: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:177: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:167: characters 40-42 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:168: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:168: characters 40-42 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:169: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:170: characters 8-10 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:147: characters 21-23 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:148: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:148: characters 16-18 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:161: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:161: characters 16-18 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:161: characters 43-45 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:182: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:182: characters 12-14 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:183: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:185: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:186: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:187: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:187: characters 11-13 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:187: characters 33-35 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:189: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:189: characters 13-15 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:190: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:190: characters 13-15 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:191: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:192: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:193: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:193: characters 15-17 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:193: characters 24-26 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:193: characters 33-35 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:194: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:194: characters 17-19 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:195: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:197: characters 12-14 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:199: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:200: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:200: characters 16-18 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:202: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:205: characters 3-5 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:210: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:211: characters 2-4 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:211: characters 16-18 : Unknown identifier : gl
src/HaxeLimeGdxApplication.hx:212: characters 2-4 : Unknown identifier : gl
ERROR (8609) (1)
:runSwf FAILED

Execution failed for task ':runSwf'.
> com.jtransc.error.InvalidOperationException: Process exited with code 1

Most tasks print these warnings:

WARNING haxe_gen.writeMethod:Can't find method AstMethodRef(com.badlogic.gdx.utils.BufferUtils,newUnsafeByteBuffer,(I)Ljava/nio/ByteBuffer;) while generating com.badlogic.gdx.graphics.glutils.KTXTextureData::prepare
WARNING haxe_gen.writeMethod:Can't find method AstMethodRef(com.badlogic.gdx.utils.BufferUtils,disposeUnsafeByteBuffer,(Ljava/nio/ByteBuffer;)V) while generating com.badlogic.gdx.graphics.glutils.KTXTextureData::disposePreparedData
WARNING haxe_gen.writeMethod:Can't find method AstMethodRef(com.badlogic.gdx.utils.BufferUtils,newUnsafeByteBuffer,(I)Ljava/nio/ByteBuffer;) while generating com.badlogic.gdx.graphics.glutils.ETC1$ETC1Data::<init>
WARNING haxe_gen.writeMethod:Can't find method AstMethodRef(com.badlogic.gdx.utils.BufferUtils,disposeUnsafeByteBuffer,(Ljava/nio/ByteBuffer;)V) while generating com.badlogic.gdx.graphics.glutils.ETC1$ETC1Data::dispose
WARNING haxe_gen.writeMethod:Can't find method AstMethodRef(com.badlogic.gdx.utils.BufferUtils,newUnsafeByteBuffer,(Ljava/nio/ByteBuffer;)Ljava/nio/ByteBuffer;) while generating com.badlogic.gdx.graphics.glutils.ETC1::encodeImage
WARNING haxe_gen.writeMethod:Can't find method AstMethodRef(com.badlogic.gdx.utils.BufferUtils,newUnsafeByteBuffer,(Ljava/nio/ByteBuffer;)Ljava/nio/ByteBuffer;) while generating com.badlogic.gdx.graphics.glutils.ETC1::encodeImagePKM
WARNING haxe_gen.writeMethod:Can't find method AstMethodRef(com.badlogic.gdx.graphics.Pixmap$Format,toGdx2DPixmapFormat,(Lcom/badlogic/gdx/graphics/Pixmap$Format;)I) while generating com.badlogic.gdx.graphics.PixmapIO$CIM::write
WARNING haxe_gen.writeMethod:Can't find method AstMethodRef(com.badlogic.gdx.graphics.Pixmap$Format,fromGdx2DPixmapFormat,(I)Lcom/badlogic/gdx/graphics/Pixmap$Format;) while generating com.badlogic.gdx.graphics.PixmapIO$CIM::read

I did, however, managed to run the JS/HTML5 version with runJs task. It works nicely.

@soywiz
Copy link
Contributor

soywiz commented May 26, 2016

haxelib install hxcpp

Another commands if required:

haxelib run lime setup windows

I will embed haxe in futuree versions

@czyzby
Copy link
Author

czyzby commented May 26, 2016

(I'm not using Windows, haxelib run lime setup linux seems to work fine though.)

@czyzby
Copy link
Author

czyzby commented May 26, 2016

OK, after installing the additional dependencies, the runCpp works as expected (although it does not set the application icon to LWJGL logo like Java version does and the compilation is terribly slow). runPhp still fails (no PHP target - and, to be honest, I have completely no idea that it's supposed to be... An alternative JS/HTML5 backend?). runSwf and runNeko still fail due to the same exceptions.

As a complete Haxe/Lime newbie, I'd appreciate a simple tutorial showing you how to set up your environment and how to compile your application to each platform. Do I need a Windows build slave to target Windows? Is Mac required to target iOS? How to run and test Android application? These kind of questions might seem obvious to you, but as a new user I honestly wouldn't even know where to start - a wiki page would be appreciated and would certainly help current LibGDX devs to use your backend.

EDIT: distCpp seems to be even slower than runCpp. Total time: 10 mins 17.013 secs - that's slower than GWT 2.7.0.

Anyway, now that I think about it, every supported platform should come with a tutorial describing these things:

  • What are the exact additional dependencies, except for the libraries and Haxe/Lime? (For example: you need a Mac to compile to the iOS platform.*)
  • How to run the application? Is there a Gradle task you can use? (Use runJs to compile the sources and set up a simple HTTP server at localhost:3000, which will host the application.)
  • How to distribute the application? Any useful Gradle tasks? (Run distCpp to prepare a native executable file for your desktop platform at build/jtransc-haxe-cpp folder.)
  • How to debug the application?
  • How to add platform-specific code?
  • Is compilation in incremental mode possible to speed up development?
  • Are there any limitations or additional features on this platform?

(* - examples might be incorrect or outdated.)

It think you should answer these questions for Windows, Linux, Mac, Android, iOS, JS/HTML5 and Tizen. Code samples, links and screenshots are most welcome.

@soywiz
Copy link
Contributor

soywiz commented May 26, 2016

I'm not setting icon correctly, so that's expected.
runCpp generates a debug version, which size is between 2x~4x times bigger and it's slow as hell (about an order of magnitude slower). But it allows to debug and generates proper stacktraces.
First compilation takes some time, but later it will just recompile files that have changed and it is much faster.
Though I don't know why is that slower. But that's expected. distCpp generates a release version which should be much better in both size and performance.

PHP target is not intended to be used with gdx-backend, but plain console apps not using gdx-backend-jtransc. gdx-backend-jtransc uses lime. The same goes for flash.
Right now flash is not supported. But I will try to support it later.

lime available targets: (haxelib run lime help)

  android -- Create an Android application
  blackberry -- Create a BlackBerry application
  emscripten -- Create an Emscripten application
  flash -- Create a Flash SWF application
  html5 -- Create an HTML5 canvas application
  ios -- Create an iOS application
  linux -- Create a Linux application
  mac -- Create a Mac OS X application
  tizen -- Create a Tizen application
  tvos -- Create a tvOS application
  webos -- Create a webOS application
  windows -- Create a Windows application

They all should work but flash one, that doesn't support opengl and will require a special treatment.


Regarding to tutorial I'll add a wiki page. For now:

You have to install haxe from http://haxe.org/ Haxe 3.2.1 should mostly do the work.

Haxe has two relevant commands: haxe and haxelib. Haxe is the compiler itself. Can compile from haxe sourcecode to other's language sourcecode.
Some languages require a runtime library. That's the case when generating C++ ( https://github.com/HaxeFoundation/hxcpp ), C# ( https://github.com/HaxeFoundation/hxcs ) and Java ( https://github.com/HaxeFoundation/hxjava ). Javascript, flash and php languages doesn't require any extra library.
In order to install a haxe library you use haxelib install search. It works like npm or maven. Haxe libraries are installed in a common space like maven. Haxelib list of libraries: http://lib.haxe.org/

So for setup to use with lime: you have to install haxe, and probably haxelib install hxcpp.

Generally you would need to install lime too, but it is installed automatically because of this annotation: https://github.com/jtransc/gdx-backend-jtransc/blob/master/gdx-backend-jtransc/src/com/jtransc/media/limelibgdx/LimeApplication.java#L50
(Maybe I could add hxcpp here too).

Lime itself require a small setup per platform (except, again, for javascript). It has to download the official platform SDK if not installed already and uses the C++ toolchain.

Haxe is the one that transforms Haxe code into C++, but lime is in charge of compiling and linking that C++ code, and it does it using the proper C++ toolchain that you are required to have installed. lime setup platform simplifies that setup.

Lime requires a project.xml file that is generated by gdx-backend-jtransc with this template:
https://github.com/jtransc/gdx-backend-jtransc/blob/master/gdx-backend-jtransc/resources/program.xml
The documentation for that xml file is here: http://www.openfl.org/documentation/projects/project-files/xml-format/

That information from the xml is used to generate required project files on Android, iOS etc.

lime test platform would call haxe compiler and instruct it to generate C++/javascript/swf. In the case of C++ lime determines which C++ toolchain to use (NDK in the case of Android).

So yes, it is required to have a mac with xcode to compile mac/ios or a windows machine to compile the right stuff. Though probably you could use wine or something like that for windows.

You could also generate a flash SWF, and then use Adobe AIR to generate a iOS application in a linux or window machine. But SWF is not supported with gdx-backend-jtransc right now. But we have tried with jtransc-media that supports flash target, and the adobe air approach works. But again it doesn't have the Gdx API, so no luck here.

@czyzby
Copy link
Author

czyzby commented May 26, 2016

I think you should create GitHub issues for missing features. I went through some gdx-backend-jtransc code like LimeGraphics and a lot of methods seem to return mock-up values or throw exceptions. I'm not sure if the class itself isn't a mock-up implementation replaced by more specific implementations unique to each platform, but being able to inspect current progress on this backend would certainly be helpful. I'm wondering if it's actually production-ready and what missing features I should expect. (Also, leaving some // TODOs in the code wouldn't hurt at this point, as it will be harder to track missing features later. For example, the returned density in LimeGraphics is way off and you should use something like 96f/160f if you really want a working mock-up value - even though it's a temporary implementation, it seems that you did not mark it in any way to correct it later.)

@soywiz
Copy link
Contributor

soywiz commented May 26, 2016

Sure. I have created this issue:
#6

Feel free to add issues for things you know that are missing.
It would be great to have tests to check it is working or at least have examples that I can run to determine that those features are working.

@czyzby
Copy link
Author

czyzby commented May 26, 2016

Running multiple LibGDX example projects would certainly be a start, although as far as automated tests go, it's hard to implement unit tests for graphical applications. Sometimes you need an actual human to see the subtle differences and graphical bugs on each platform. I suggest running these.

As far as issues go, I'd probably have to go through the whole codebase to point each feature that seems to be missing and currently I don't feel comfortable enough with Haxe/Lime to judge your code. ;) I can only point out some simple (missing) features that I noticed - I can create a similar issue to the one you posted discussing Graphics.

@czyzby
Copy link
Author

czyzby commented May 27, 2016

What's the difference between runHtml5, runJs and runJtransc tasks? They all seem to target the browser with JS/HTML5 code.

I'm unable to run Tizen-related tasks. I installed Tizen SDK and run haxelib run lime setup tizen, but I keep on getting this error:

Error: Source path "/home/mj/haxelib/lime/2,9,1/ndll/Tizen/lime.so" does not exist

Is there some additional setup?

About the Android run/dist:

 - Link : libApplicationMain-v7.so
/opt/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld: Warning: /opt/android-ndk/platforms/android-9/arch-arm/usr/lib/crtbegin_so.o: Unknown EABI object attribute 44
Buildfile: /mnt/shared/Projects/Workspace/public/jtransc-examples/libgdx/invaders/build/jtransc-haxe/export/release/android/bin/build.xml

-set-mode-check:

-set-debug-files:

-check-env:
 [checkenv] Android SDK Tools Revision 24.4.1
 [checkenv] Installed at /home/mj/Android/Sdk

-setup:
     [echo] Project Name: Invaders
  [gettype] Project Type: Application

-set-debug-mode:

-debug-obfuscation-check:

-pre-build:

-build-setup:
[getbuildtools] Using latest Build Tools: 23.0.2
     [echo] Resolving Build Target for Invaders...

BUILD FAILED
/home/mj/Android/Sdk/tools/ant/build.xml:538: Unable to resolve project target 'android-19'

ERROR (1967230) (ProcessResult2(exitValue=1, out=, err=, outerr=))
:distAndroid FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':distAndroid'.
> com.jtransc.error.InvalidOperationException: Process exited with code 1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 33 mins 3.274 secs

Oh, well... (I know, I should have checked which version to target. I'm rerunning the task with 23 API set in manifest, but it still shouldn't take THAT long.)

@czyzby
Copy link
Author

czyzby commented May 27, 2016

I keep on getting this error on Android, even though I changed the targeted version in manifest.xml and Gradle files:

/home/mj/Android/Sdk/tools/ant/build.xml:538: Unable to resolve project target 'android-19'

I think you're using a fixed Android API version somewhere.

ghost pushed a commit that referenced this issue Jul 5, 2017
@ghost ghost closed this as completed in 0f47f33 Jul 5, 2017
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants