LWJGL v2 versus v3

Development
41

I guess the whole dialog made more sense 5 or 10 years ago, when OpenGL 2 compatibility was more of an issue, so that if the game crash on start, you could tweak the settings and hope to get the thing running (and update the graphics driver in between).
In 2019 is nice but we can safely assume that the user has the required hardware and driver, so maybe also overkill and don’t justify holding back the lwjgl3?

THAT would be quite an upgrade! How about putting a news feed about JME (assuming that somebody take the effort of actually writing it, that is) Might just point to http://jmonkeyengine.org/ :slight_smile:

42

But what would the default be? 1280x720 windowed? Full screen? (non-starter for me… simple test app goes full screen, I delete it.) Which AA settings? None?

To me, better to drop OSX than the settings dialog in the test apps. It’s super important for quickly testing different settings.

Or just leave 2 the default until the landscape changes.

2 Likes
43

well, im not sure how many % of just OSX users are players, i seen it was little %.

Anyway its OSX that make problems. i belive they will support openGL anyway, because they might loose players.

if they gonna do same as Internet Explorer doing own solutions, they gonna loose users, thats all.
Or maybe they gonna do games themselves to fill lack of osx games :wink:

I just want to see great games working on both linux and windows and osx users ask, why not osx? its very similar to linux, so why not? and the answer would be simple “osx make problems”

44

Yes and no, fun starts with Intel integrated graphics and then you still have the problem for OpenGL4.4 and more. And what Paul said. Fullscreen, Windowed Mode, Borderless Window…

That’s project specific and NOT what jme should have I think. It’s like 1 GB RAM and 3 GB Game Size just to have Electron, all the 3124712378123 modules, which have to keep updated etc for something most games might not want (again: relevant for standalone games only, because steam already provides updates etc)

Yes, but also because jme doesn’t care about OSX and because it exposes problems: OS X forces a 3.1 Core Profile, whereas the other OSes run in compatibility mode and just ignores several issues shaders have.

To me, one of the biggest stand outs of java is to be cross-platform. When I choose jMonkeyEngine, I expect it to at least run on all known desktop platforms, maybe the pi, maybe iOS and certainly Android.

Currently it only runs fine on Windows, for that I could choose a DirectX 12 Engine or something.
Linux has issues with fullscreen and I guess keyboard mapping, maybe more.
Mac OS X is a complete problem,
iOS is a real pain and only works proof of concept like
Even Android is a bit of a mess with NBAndroid or installing AndroidStudio, Fighting ProGuard, messing with Bugs/Shaders/openGLES etc.

Re: Dropping Support for OSX:
Apple has “deprecated” OpenGL in favor of Metal, which however means that openGL will still be around at least a few years, so you can safely use it. Along the same lines: Apple “deprecates” C++ so you use Swift/Objective-C. Did they remove C++?

Even WHEN that happens, there are still MoltenGL | Metal performance with OpenGL ES and MoltenVK | Run Vulkan on iOS and OS X

2 Likes
45

Let’s see if I got this straight: we can’t drop LWJGL v2 because v3 won’t run on macOS after showing the settings dialog, which is AWT.

So what keeps us from using JavaFX instead?

1 Like
46

That oracle removed JavaFX from their JDK, e.g. You need to download it as separate “openJFX”, not sure when/how this will happen for the JVM and also a thing to consider: We cannot use Swing as it’s based on AWT. Does anybody know if JavaFX doesn’t ever rely on AWT for anything?

47

Can someone explain me in short why awt is a problem with lwjgl3?

48

According to Oracle, no, JavaFX does not rely on AWT.


(image from Oracle’s Understanding the JavaFX Architecture)

Can’t we pack OpenJFX with jME as we do to LWJGL? According to the site OpenJFX.io, it is licensed under GPL with class path exception, which means we are protected from having to release derivative projects under regular GPL.

2 Likes
49

x2

While I’m always an eager advocate for JavaFX where possible, I don’t think we’ve yet determined exactly why using AWT in an entirely separate window is an issue with LWJGL3. I at least haven’t seen any evidence that it is.

Is it not simply an issue with integrating an AWT canvas + LWJGL3 in the same window? (Which is kind of a “who cares” since we have jme-jfx.)

50

^ Experimenting LWJGL3

Using AWT is an issue. I have seen this happening at random. We have a Swing dialog running before the app. And we also implemented this garbage collect hack (JME has it also because of the settings dialog), but it is not working always, as you would expect given the nature of the hack. The crash happens on Windows and Linux at times. There is no telling.

1 Like
51

Wow, nasty stuff. :weary:

On the bright side, maybe it’ll show some of the benefit of splitting JavaFX away from the JDK, if it can get fixed easier as a result.

52

as i see this also OSX related issues. because i create Font(lwjgl3) and both windows and linux no problems.

well when i start using this engine i also thought it will be all platform working, but looking at OSX now, idk if i would like to develop on it ;p im Glad Windows/Linux dont have that problems.

53

So now it seems the choices are:
-keep lwjgl 2 around a while longer
-have no settings dialog
-import ALL of JavaFX for a settings dialog

I know which one I’d vote for.

It’s really too bad that the “other community at large” seems unable or unwilling to fix the AWT bug in the first place.

1 Like
54

i think the settings dialog is important. Dont use JavaFX myself but if it works fine then why not, but someone might need rebuild it and fix this 2 other issues for osx.

55

I mean, I don’t know how big JavaFX is in practice but it seems like a big dependency to suck in just for a settings dialog so that we can work around a problem on a platform that is already hostile to our underlying libraries.

2 Likes
56

got it, fact the more dependencies the more to worry. But since this settings window cause so many problems… sounds like could be exception to use it.

57

And there are separate jfx builds for java 8/9/10, 11 and 12. I guess that continues along the trend for future releases.

58

Ok. How about making the launcher a separate executable, and have the jme SimpleApplication to accept commad line parameters that replaces the launcher? Like:

MyGame display=windowed,1280x720 AA=disabled

1 Like
59

If the assumption that this is caused by some sort of improper X sharing between awt and lwjgl3 is correct, then i can see how the System.gc fix might work. Calling the gc will likely free whatever resource is causing this issue, but this approach is not very reliable.
My guess is that in some circumstances, the gc runs after jme is starting the initialization and this causes the issue to pop up randomly even with the gc fix.
So a possible solution could be to wait for all the awt threads to exit (that should happen when every awt component has been disposed) and maybe also terminate manually the thread that handles the X interoperability.

This is the code i’ve come up with (that works on my system that runs Ubuntu 18.04, i have no way to test this on osx)

I know it is a pretty bad hack, but if this works, maybe we can figure out something better.

EDIT: Also, it’s worth noting that the issue (at least in my tests) never appear if the awt context is kept alive.

2 Likes
60

Consider opportunity cost - even if someone is willing to do some work on a workaround or a new dialog, instead they could have fixed a worse bug or improved something more important. Status quo isn’t so bad.

Another option - help out with this effort:
http://www.java-gaming.org/topics/lwjgl3fx-a-sneak-peek/38003/msg/363477/view.html#msg363477