Has anybody tried Cheerpj with JMonkeyEngine? It has a Chrome extension (not a plugin) to run applets with a Javascript JVM, it even supports Swing.
1 Like
Itās highly unlikely (read: almost certain) that that would not work with jME without extensive rewriting of the engine since the only way to access OpenGL in the browser is via WebGL, which is significantly different from stock OpenGL on the desktop. Even if it did run, odds are that it would be glacially slow - JS is usually significantly slower than Java running in Hotspot, and a VM layer in JS only adds overhead to that (and a very significant amount). A VM like that could easily be performant enough for some uses (I.e., non-realtime code), but it would likely struggle with anything but the lightest of jME games (and even that is a generous estimate).
1 Like
Wellā¦ yes and noā¦ js is slower yes, but there is a good chance that your 3D game/appās bottleneck is not the CPU, more the GPU. In that case, you could have a game running as fast in js and in Javaā¦or C++ or whatever you use for the CPU side. Iād say, if a game runs on a mobile phone, it can run in a browser with javascript, no problem, most of the time.
Also one of my coworker has already been surprised by Emscripten (C++ to js transpiler), producing faster code than he did. So IMOā¦those transpilers solution could workā¦ and better than we expect.
2 Likes
why is everyone focused on getting it to work using javascript? Surely trying to get it to work with wasm is better? Considering it is designed to be a compiler target it should be easier to port a jvm to it then to javascript? As for browser support, it should be good enough. Edge already has support for it but its behind a flag leaving just IE and opera mini that donāt support it. ( Can I use... Support tables for HTML5, CSS3, etc )
Having said that, after looking around a bit there doesnāt seem to be any projects for that yet. There is a compiler that goes the other way though (wasm to java bytecode) GitHub - cretz/asmble: Compile WebAssembly to JVM and other WASM tools .
2 Likes
Yes that is my observation with my stuff, if I would have no GPU stuff at all I would have capacity of nearly 2000+ frames per sec. With GPU it drops down to 1200+ frams per sec and with shadows it is around 300-400 frames per sec. I have a lot ECS systems running even with a lot entities it seems not beeing a problem CPU wise.
1 Like
Yeah, Iām not surprised that a transpiler produced code that was faster than handwritten code. For a lot of games, Iād guess youāre right and the GPU is the bottleneck. Anything that heavily taxes the CPU however (lots of physical entities, and/or graphics techniques that require per-frame CPU use I would expect to suffer pretty heavily.
WASM is still running in the JS VM. No matter what you do, youāre still going to pay that price, and running a JVM inside a JS VM is likely to be a pretty hefty cost for CPU intensive games. A better bet longterm is to wait for WASM to support garbage collection, at which point transpiling Java source to WASM code will be a more viable option. Porting the rendering pipeline to WebGL will still probably be tough (WebGL still has some rough spots), or at very least a big job. Also, I think a lot of shaders will need a rewrite for WebGL. Iām not sure of the specifics, but as I recall WebGL shaders arenāt 100% compatible with any of the stock GLSL versions.
With a WebGL rendering backend and WebGL compatible shaders, for now transpiling with something like JSweet would probably at least produce a functional result. As I remember, one of our forum members was working on just that a few months back. Havenāt heard any news on how far he got with that though.
I donāt think the biggest problem with porting to the web is language support or VM performance. The biggest problem is that JS and web tech are, by design, heavily restricted and a very, very different platform from the JVM. Things Java developers take for granted, like using background threads for disk I/O or raw network access, are either totally missing or exist only in heavily restricted and modified forms (I.e. WebWorkers and WebSockets) that often have an unstable API or differing levels of support on different browsers. Stability and support is improving for web tech, but it still has a TON of gotchas for native/JVM developers that cause all kinds of headaches. Itās better if youāre deploying to something like Electron where you only have one version of Chrome to support, but Electron is hardly a silver bullet and it has all its own headaches. It would be nice if there was a way to deploy jME games for the web, but Iād question the sanity of a monkey deploying a game to Electron instead of a desktop VM/proper mobile builds.
1 Like
WebGL is similar to OpenGL ES and JMonkeyEngine rendering code is already quite modern. I used JMonkeyEngine 3 with OpenGL ES (JOGL backend), I donāt claim that supporting WebGL is trivial but in my humble opinion, the problem isnāt the differences between full OpenGL and WebGL. I donāt deny that it would be probably slower than with a real JVM.
Moreover, the team behind Cheerp and Cheerpj looks at WebAssembly with interest too. We donāt know the future of WebAssembly, maybe it will get rid of Javascript.
@lenscas Unlicense (in Java) supports WebAssembly too.
1 Like
The author of Unlicense Lib is working on a conversion from Java bytecode to WASM:
https://bitbucket.org/Eclesia/un-lib/src/2357d3067b85989e80acd9f915e5eaa37c6d84b6/code/code-wasm/src/main/java/science/unlicense/impl/code/wasm/?at=master
1 Like
That would be great if someone got a sturdy Java runtime going on WASM. Iām not at all a fan of the āweb everythingā trend, but WASM is a big step in the right direction.
Youāre right that WebGL and OpenGL ES are similar. Sounds like the jME backend bit might be easier than my first estimation, but shaders (I think) are still problematic. As I recall, WebGL has some differences from stock OpenGL when it comes to GLSL. That probably means maintaining multiple versions of the same shader for WebGL and desktop/Android. Maybe shader nodes could help hereā¦ (not sure of the exact differences or whether shader node snippets would make it easier to keep a single shader source capable of running on stock OpenGL and WebGL).
It would be great if someone proved me wrong and came up with a good way to run jME in WebGL and WASM (or transpiled to JS), but Iām skeptical about how well that would jME would play out in the browser (pardon the pun!).
1 Like
Shaders are the easiest part, maybe there could be issues with the post processing, but it will be still usable since many people run their own post processing and shaders anyway.
1 Like
I guess shaders wouldnāt be too big an issue if they could be left as just another technique in a material definition.
1 Like