you mean settings dialog?
how the LWJGL3 affect it 
it should not, right? i thought this dialog is in pure Java before executing any LWJGL functions.
Yea, you can’t open any AWT related code or it will crash lwjgl3. AWT is completely unsupported with lwjgl3. I built a settings dialog with Javafx as a result.
3 Likes
yep, thought the same, its just a dialog so can use different lib anyway.
but im really not sure why it crash LWJGL3 on ox.
so if any external Java App that use AWT will be runned, it will crash it too?
or is it internal packages related only.
I didn’t spend a lot of time looking into it to be honest. Since I couldn’t use the default settings dialog anyways I had to make my own so it wasn’t a big deal.
I can run the TestChooser + Settings Dialog fine with LWJGL3 as a jme3-examples dependency (Linux).
I feel like I read about this before, I believe it was an issue with using an AWT canvas, not a settings dialog in a totally different window. IIRC (which sometimes I do not 
)
We have JavaFX integration now, so if that’s all it is, not a big issue for me.
The issue seems to be with OSX only, not Linux.
1 Like
Which means when the default is 3, the examples basically won’t work on OSX.
…I mean, we could just stop supporting OSX. Then no worries.
2 Likes
I am loading the default settings with LWJGL2.
AppSettings s = new AppSettings(true);
Using
setRenderer(AppSettings.LWJGL_OPENGL2);
it diplays this info:
INFO: OpenGL Renderer Information
* Vendor: X.Org
* Renderer: AMD CEDAR (DRM 2.50.0 / 4.15.0-20-generic, LLVM 6.0.0)
* OpenGL Version: 3.0 Mesa 18.0.0-rc5
* GLSL Version: 1.30
* Profile: Compatibility
which ends up with
org.lwjgl.opengl.OpenGLException: Invalid enum (1280)
and using
setRenderer(AppSettings.LWJGL_OPENGL3);
it diplays this info:
INFO: OpenGL Renderer Information
* Vendor: X.Org
* Renderer: AMD CEDAR (DRM 2.50.0 / 4.15.0-20-generic, LLVM 6.0.0)
* OpenGL Version: 3.3 (Core Profile) Mesa 18.0.0-rc5
* GLSL Version: 3.30
* Profile: Core
which ends up with this error:
org.lwjgl.opengl.OpenGLException: Invalid value (1281)
the error happens in some of the examples not all of them.
While I know better than to take that too seriously, I enjoyed reading that line a bit too much.
Actually, wasn’t there some weird news about Apple deprecating OpenGL? (Seriously, what the hell Crapple?)
Yep - OpenGL on Apple devices (OSX + iOS) is going away in favor of Apple’s own Metal API (a low-level API similar to Vulkan).
Just for your information, oracle has started Project Lanai as macOS new graphics rendering pipeline using Metal:
Do not know if this also includes Java Swing or not.
1 Like
Yeah, i think we should drop apple, before they drop us.
3 Likes
There is also the idea of just leaving LWJGL2 as default.
Yes, exactly.
Just note that a settings dialogue with JavaFX might pull in a whole more bunch of dependencies and stuff in (some jvm’s/jdk’s even already need you to download openJFX separately).
It’s no good argument but: For odd platforms it’s much easier to support AWT than JavaFX (which starts with Codecs, Animation and all that stuff).
It depends. For a finished game, one might build a launcher in electron featuring the latest news-feed from the homepage, fancy settings, xml configuration files, etc.
But for anything else and inbetween (and even every other game which doesn’t like to configure settings beforehand but in-game), you don’t want a complex dialogue. Just setting the Resolution, Fullscreen, maybe a preset and a designated display is all. Also just think of a steam game - Usually you launch it and change stuff in game or via the Properties. Only Standalone Games come with big launchers usually.
[However we could rework the settings dialogue anyway, e.g. because of said problems with fullscreen windows on linux]
@sgold can add to this if he has more reasons, but I figured the reason to consider switching the default to 3 would be to improve “test” coverage, so that we discover any issues now (rather than at a later point when a move from 2 is forced, with less preparation). It also would slightly ease support if 2 were able to be dropped.
If that’s not a big enough concern, and sgold doesn’t have other reasons, it would seem that 2 is fine to leave as default.
2 Likes
I haven’t got much of an agenda when it comes to LWJGL v2 versus v3. I just figured that v3 was the future, and that JME would eventually go there.
I almost committed the change without consulting anyone. I’m very glad I didn’t.
I found the discussion enlightening. So many undocumented issues!
Party on.
3 Likes
Never hurts to ask. I have no horse in this race either, I guess we’re leaving it at 2 then.
1 Like
Regardless of that we should definitely go ahead, fix all v3 issues and if it runs smooth as butter then we can safely use v3 as the default I guess.
However OS X Support will still be a tricky problem…
2 Likes
Probably, leave 2 the default until Apple removes OpenGL support completely and permanently breaks JME. Then we can blame Apple and just drop OSX support.
…or someone will write a Metal wrapper that looks like OpenGL and we use that for OSX. If that’s not lwjgl3 then the problem is also solved, albeit with added build complexity.