Its more about the internals of bitmapfont that makes you go insane 
Anyway a browser based game can easily just use a normal html div and css stuff for any font and overlay it.
1 Like
I am personally a bit heartbroken about this, given that an MMO I grew up on uses in-browser java, and one has to admit itās a good marketing stunt to make your game so easily available, without a traditional download/install process.
Though, to be fair, it doesnāt REALLY affect me, as they have a downloadable client option, so thatās alright.
What grinds my gears is the astounding amount of security concern against java in recent times. Sure I understand it might be vulnerable, but to completely block off users from running un-certified apps on their own risk is rather annoying. Itās one of the reasons Iāve not āupgradedā to Java 8 yet.
I even had to switch firewall at one point because it completely and utterly blocked all networking done by java (even outside a browser), purely because the JRE version seemed unkown to it (too new I guess?)
The funny part is, my firewall was not showing any sign of blocking it. Even when I temporarily ādisabledā it, Java was blocked from the net. Closing the firewall app suddenly made it work. Huh. Screw Agnitum!
Besides, itās not just my pet-peeve, my brother works as a computer-handyman (forgive my terminologic inaccuracy) at a big company, and has a lot of trouble getting old (but functional and essential) java apps to run because of the security nonsense.
1 Like
yep, same issues in my company. There are ways to get around this though. tell him to look for " java Deployment ruleset".
Thatās basically a white list of URL, telling what JRE to use for what URL, and that automatically promote any applet coming from these urls to secure applets, so you donāt have any security warnings.
Has anyone had a look into Dukescript yet? (http://dukescript.com/)
I donāt think performance of compiling java to javascript will be great, but it could be good enough for small games, showcases etc.
Yes I looked into bck2brwsr as well as TeaVM (both are Dukescript VMs). They have two primary issues:
- Lack of support for core Java APIs like Thread, EnumMap, etc.
- Require Maven based build to work. Our build system is based on ANT / Gradle which doesnāt integrate with Maven
Is Thread āreally reallyā needed to make JME work in a browser? Our team currently working on extracted concepts which are useful for a game in browser and rewrite parts of JME that doesnāt fit, so utilities in Asset system and Timer should be rewriten, and ehā¦ other partsā¦ Iāve tried DukeScript, and GWT.
Of course we only focus in a prototype that use a 2D (possible 3D) gui elements, but write in JME concepts and library in netbean. We not aim to a full 3d game and in fact I donāt have a clear view of what we can do and what already there. To make sure itās practically possible, we look into cocos2d-x and libgdx (both with a mistery x at the end) which bring 3d to android, web and ios at the same time.
threejs for example let developer make rapid developing so they can experiment their ideas very quick, they even make it interactive! Itās something I also want to do. Like, write java code in netbean, code immediately complied, translated into javascript, reload in browser and voila ā¦ Of course this is not JME problem but java to js problem, the workflow and technologies depends on the team and on the game its self.
I donāt think theres much use to try and squeeze the engine in such a context, simply using some engine/API thats made for these kinds of contexts makes much more sense. You wouldnāt be able to make games ājME-Styleā anyway, so why try and fit a square peg into a round hole?
Of course threads are not needed. It is possible to make jME3 completely single threaded ā¦ but the assumption that threads are supported by the OS is integrated deep within many parts of the engine - it requires going into each end and adding a check like
if (HAVE_THREADS)
createThreadsAndDoOtherThings();
else
doSingleThreadedThingy();
In some places it can make the code unnecessarily complicated. So yes, it is possible, but it would be a pretty big project (maybe could be good for GSoC 2015?)
The point is: JME become not just an engine but libraries and tools written for them. For the goods of writing āgood gamesā I would like to save some of my effort not to write ācodeā again and again. Thatās why I want to use Java, JME, and its tools. If I have to rewrite some parts, bear with me. At least, I know itās possible to do it. Itās only worth depends on your team and your company decision about the picked technologies.
@Momoko_Fan : Sorry, itās an āin-houseā thing at the moment. The part which is engine related, hopefully we will able to delivery as an independent library. As @Relic724 revealed, we bridge from Java to Js via DukeScript and write a new JME compatible renderer and asset loading as a folk of pixijs. Itās work ( somewhat a mess of technologies soup). The good thing and ideas weāve learn may envolve this tech soup into better form, I donāt know. In Javascript world, they are talking about Polymer, AngularJs with threejs components. What can be the result of this, as I said, I didnāt have a clear view yet!
Exactly and most of the stuff wonāt work anyway, especially your very extensive stuff which uses all kinds of libraries. Porting each and every one of them would not make much sense compared to just writing your app or whatever with the tools that are made for the target platform.
Those libs which interfere with low level will not work of course.
Those which use Shader and GLSL will have to convert part by part.
Those just build around concepts like Control and State will survive.
The AI lib for example will survive.
Tonegod gui work after modify those nasty anonymous classes and modify the shader source. We have to use another XML loading routines but for small example, itāve worked also.
It will be silly or even non sense to port a big game already written in one source to another. But with some company (such like mine), they do it for living 
It called porting. Itās the most saccrified job in the world. You be blamed for otherās codes, twiceā¦
P/s: Note that itās also a common job to rewrite shader code for developer like me. Itās a sad and obvious true that even if OpenGL sounds like cross platform is not work in all devices the same. So we ALWAYS have to re write packs of shader for each profile of devices with one kind of processors and memory. So write another dozen of GLSL sound simple for us, at least if the deadline still far to reachā¦
This is more like trying to make a desktop windowing system work on a mobile device.
Sounds like you would like to have a better Abstraction of Gaming Logic type Library to run off of.
jMonkeyEngine seems to be in the odd transitory state to you, then. It has several nice game abstraction libraries that have been developed to increase functionality for this situation: Java and OpenGL/OpenALās abstraction of low level graphics/audio. The situationās level of abstraction relies upon Javaās own ability to cover multiple platforms. I donāt think that you are so much requesting additional functionality of jMonkeyEngine, itself, but a clearer definition between the abstraction layers of jMonkeyEngineās collection of High-Level modules and jMonkeyEngine, itself. That way you could take the collection of High-Level modules and form a game around a different Base-Functionality engine, like WebGLā¦ or [BS Warning] even Assembler (should you wish to program for the latest stuff in DOSā¦ I <3 x286 chipset, VESA rulez!).
But thatās not my call, Iām just enjoying the engine for what it is, atm. It would be up to Nehon nā the Crew to make that call. The engine is in that cute Gosling stage, and feathers are flying everywhere. I know that Iām having fun playing with it, though. Yay!
1 Like
Well Javascript by its nature allows for asynchronous execution. IMO it would be possible to base all the threading we use on this.
Only thing that would be complicated would be to synchronize threads.
Also HTML5 spec has something called Web Workers, that are basically threads for HTML. Not sure itās supported on every browser, but I bet most of them do.
2 Likes
I would go so far and say that most smaller jme games dont need any multithreading at all.
Even many current Desktop games (like 90% produced with unity) have no multithreading at all.
So if you know about this limitation while writing the game there shouldnāt really be any problem.
Iām thinking about cases like Adventure Box
@roleary made this awesome voxel engine in JME3 Procedural voxel terrain and vegetation generation but his web-based voxel engine http://adventurebox.com/play-here/ is using Goo engine.
Due to the algorithmic nature of voxel worlds they donāt need huge client side data stores necessarily, but it would still be nice to be able to use the same code that natively targets desktop and mobile clients to run a browser version.
OK WebGL is limiting, but as weāve already mentioned, a lot of the big name engines already do run in the browser, so the limitations canāt be insurmountable. For example: http://beta.unity3d.com/jonas/DT2/ and Mozilla and Epic Preview Unreal Engine 4 Running in Firefox - The Mozilla Blog
The announce of WebGL support by unity and UE4 are one year old, and nothing new since. And support of web is like a lie, because there are lot of restriction (like some linux support in unity) because some feature are made for DirectX or for xxx. And downgrade to web is too costly for a bad result.
I agree with @normen: use the optimal tool for the job. Last year I prototype webgl game, and I prefer to use tech made for the web (in my case I used Dart language, home made engine, physics, ā¦ after playing with threejs, box2d (javascript and dart)). Physics are very limited on web (do some search about perf). Webgame need lot of tuning that are often impossible by transpiler from language not made for web.
@nehon, web worker can access DOM and they are restricted, you can communicate with them by message passing (like actor) where you have to copy data.
To be back to the original question, my suggestion is to not use java for webclient. But you can use jme on server side to serve data (or image) for a 3D webgl client a āsimpleā viewer.
As Momoko_Fan suggested, I have checked the GWT library for some days. But the WebGL integration into JME3 using GWT seems to be a really big taskā¦ too much big for me !
Currently, I use JME3 to generate complex 3d scenes, with other libraries like JTS and Geotools. But, when the generation process is finished, the rendering step is really simple: just draw lots of triangles, without physic, audio or AI. Moreover, generated scenes are static.
So, I think I will keep my current development into the server-side and just use GWT + parallax to display data in the Web-browser (to continue with the Java language). These data (about 500 Ko to 4 Mo) will be sent during the initialisation step, for example using a personal JSON format. And thatās all for the renderer. For the GUI, I will use the GWT widgets.
Again, thanks for your responsesā¦
and I think the discussion is not really finished ! 
We have also been using applets for the past three years to visualize our 3D world and it seems to become harder every year. Which is unfortunate.
From a technical perspective I agree that normal desktop applications are much better, but from our user perspective (gouvernments, large businesses) applets are easier/lighter to use and often do not require administrator approval to install them.
So I would no be happy to stop using applets, as for WebGL I have also seen a lot of demoās but it is not jet as complete. Anyway, I am currently at the GDC in SF and I will keep an eye open for discussions relating to this subject.
1 Like