I want to understand a bit more about how JME architecture works. I wanted to know where in the code would I have to look if I wanted to implement a browser layer for webgl. I want to see if its something I can tackle as Im a decent javascript developer and I also dabble a bit with java coding. Ive played around with GWT a little as well.
Im thinking there’s probably a “platform” layer somewhere that can use lwjgl or android or whatever. Then there must also be some kind of layer for the asset manager system to work on different platforms. Probably the same for the audio system as well. I know bullet has been ported over to javascript with emscripten so Im thinking that could work in the browser as well. Any thoughts on the way forward?
I have a 3d project coming up and I think JME in the browser would be a good solution for me. That way I can support both desktop and browser targets.
For assets, assumed that the current code can be compiled (?) correctly to javascript, you will only need to make an AssetLocator that opens streams to whatever a javascript/webgl app is supposed to load assets.
libGDX (open source java game engine) use GWT for deploying on web. It may be a good idea to see how does it handle the web part.
some quick googling :
The version in question has been ported from a Java port of Quake 2 that already existed called Jake2. The team used Google Web Toolkit, the Canvas API, WebGL, and WebSockets to recreate the game in its HTML 5 form.
So it is theoretically possible, it just needs an insane amount of work.
Thx for all the pointers guys. Im first gonna try getting jme-core compiled with Gwt and see how many things Gwt complains about. Then I’ll have a clearer idea of what we looking at for the rest of the modules.
Just wanted to put this here for future reference.
From the little bit Ive researched into getting JME built with GWT, getting everything working in the browser could be quite a lot of work. GWT is only a compiler framework converting from java code to javascript. For classes in the java standard library that you want to use, you would have to implement them and then tell GWT to use them at compile time. There is a small subset of emulated JRE std library classes in the standard distribution. However, some of the more important ones like java.lang.Thread are not there.
The libGDX guys got around this by implementing a substantial amount of the JRE classes themselves. So any effort for JME could use some of that code, I suppose.
Its not impossible, it will just be a lot of work. I think some changes will be needed in the core as well to mitigate any existing dependence on multithreading, if that’s even possible. I dont know to what extent JME uses or requires multithreading. So at least some support from the core team will be required, even if its just moral/advisory support.
Also, integration with native bullet will probably need bullet to be compiled with emscripten (not difficult) and then have the glue code written in native GWT methods to bind everything together. Im also not sure if the
There is one thing, though. The future of GWT seems a bit uncertain. Google is still using it for things like Google Developer Console and Google Adwords and stuff like that. But development on the project does appear somewhat stagnant. But it is quite solid and robust.
Those following this thread may find www.teavm.org interesting. They’re translating Java bytecode, not source. The project does seem to have an active community, and they are working on implementing the standard runtime classes in a way that will function with their emulator.
Disclaimer: never used it myself, just something that I stumbled across.
I’ll have a look at these. Also, is there any specific procedure for adding a new platform?
