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

Some questions #13

Closed
nicolaichuk opened this issue Feb 20, 2017 · 6 comments
Closed

Some questions #13

nicolaichuk opened this issue Feb 20, 2017 · 6 comments

Comments

@nicolaichuk
Copy link
Contributor

nicolaichuk commented Feb 20, 2017

We are a gamedev team. We are looking for a replacement GWT in libgdx.

I would like to know:

  1. How often do you plan to release gdx-dragome-backend?

  2. Can use gdx-dragome-backend in production code?

@xpenatan
Copy link
Owner

1: When I have time I plan to keep it updated. Sometimes I need to wait for @fpetrola to fix some bugs I find. Building with gradle is in early stage. https://github.com/xpenatan/gdx-shadertoy is a example with gradle which I made a fatjar which packs dragomeSDK+dependencies and dragomebackend into 1 jar.
Bullet extension is a bit different from libgdx bullet. I manually create java/jni classes and js code block which calls javascript when its generated (not everything is done. Need time for this). You may ask why I just dont use the JNI generator libgdx is because its 2 much hack to do just a single change to config file to fix some memory leaks I found in java/jni gen. code.

2: Its apache 2.0 (same as libgdx) Do what ever you want =D

@nicolaichuk
Copy link
Contributor Author

nicolaichuk commented Feb 20, 2017

Thanks for the answer.

its 2 much hack to do just a single change to config file to fix some memory leaks

Possible detail please?

2: Its apache 2.0 (same as libgdx) Do what ever you want =D

I mean, how stable is gdx-dragome-backend for production use?

@fpetrola
Copy link
Contributor

Hi @nicolaichuk,

Thanks for the answer.

its 2 much hack to do just a single change to config file to fix some memory leaks

Possible detail please?

2: Its apache 2.0 (same as libgdx) Do what ever you want =D

I mean, how stable is gdx-dragome-backend for production use?

I can answer about Dragome in terms of generated code production use:

  1. Performance: generated code is as much faster as GWT performance, we've made several tests for example over jsurfer renderer GWT/Dragome versions, jbox2d, libgdx backends, gameengine.
  2. Memory leaks: there are no memory leaks detected for now.
  3. Distribution package size: It can be optimized using Proguard config for creating a very tiny version eliminating unused code.
  4. Obfuscation: It can also be configured (by proguard config) to obfuscate classes to avoid source code decompilation.
  5. Modules: As Dragome supports reflection it can supports modular addons to be develop by 3rd ones and be included in final app without core recompilation.

@xpenatan
Copy link
Owner

xpenatan commented Feb 20, 2017

Possible detail please?

There are methods that allocate objects every time you call them instead of caching them.
I figured it out when using jProfiler and profiling my editor. I tried to cache it but changing the config files wasn't easy so I preferred to manually code it so I know that every method is good. Its the same idea as gdx box2d wrapper where you use comment block to call JNI. I adapted it so I can add another block for javascript calls so it will generate/copy all classes using that block.

Obfuscation: It can also be configured (by proguard config) to obfuscate classes to avoid source code decompilation.

Obfuscation is possible ( I did it before) but we need to take a look at it to make it work again. it requires some change to the compiler execution order.

@nicolaichuk
Copy link
Contributor Author

nicolaichuk commented Feb 21, 2017

Thanks for the answer. I will think about it.

@nicolaichuk
Copy link
Contributor Author

konsoletyper/teavm#245

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

3 participants