LWJGL v2 versus v3

Development
81

And that’s where the command line example is problematic. We’re not talking about Steam’s Run Options here, but trying to launch a jme3-test (or some code from the hub) and trying to find the correct gradle file for each example and hard-code the launch flags there (if one knows on top of the head how to add flags to Applications Run task)

Now assume a co worker also wants to launch the example from the same repo. He needs to do this changes as well, but might prefer a different resolution. Sounds complete fun to me…

82

Maybe the application can be modified to read settings from system properties and environment variables instead of commandline args? Then the gradle script can be modified to pass all the system properties?

83

The fundamental issue with LWJGL2 is that’s unsupported. If a Windows update breaks it, you either fix (the library) yourself, or you’re screwed.

I do think that the launcher should be easier to decouple. Like, the JMEContext (or whatever it is called) that uses AWT should be plugged in the application (With the settings, windows for error etc), with the current default added if the developer don’t specify another one that he made.

So that you can do:

app.setContext(MySWTContext());

or

app.setContext(MyElectronContext());

or

app.setContext(MyOSXContext());
1 Like
84

That doesn’t change much. Like if you pass env variables versus command line arguments.
And it’s fundamental. I always like to run my code at 30 FPS, especially examples (VSynced), whereas others run their stuff at 30914872145 FPS (CPU waste for me). Also I run all my projects in 1280x720, as that’s a comfortable window size on FHD. That’s not FHD Fullscreen.

How I have to change these settings in a user-unfriendly way, doesn’t matter.

You “can” already. Just disable the Settings Dialog and execute your Settings before app.start(), voila.
Also if you’re going for Electron you want electron to launch your app (which is a different usecase), because there you can also set JVM Flags such as GC Algorithm and Max Memory.

85

So as there seems to be controversy on what to do, let’s agree on one thing:
Fixing LWJGLv3 issues is a priority now, at one point it will be the future.

For this, please create Issues on github and add them to the lwjgl v3 milestone (or mention it, so that we can).

THEN we need EVERYONE to Test these issues (so one might set up a sample project), because for these kinds of issues we need many platforms and iterations.

For instance, @RiccardoBlb found a solution where he thinks could solve the RenderBadPicture Exception, which was happening on LINUX before. It IS the one related to AWT, but we added a HACK with System.GC(), but that doesn’t seem to work all the time.

(On the other hand now reading that GLFW has problems with us using the AWTLoader for Textures, that would require a completely different thing (fixing their code), but noone ever had that problem so far, which is strange)

Especially I’d like to invite everyone with foreign keyboard layouts to test the issue with keyboard layouts (as this is happening for 3 people but not for 1, so we need more evidence).

2 Likes
86

I don’t know, i use vscode and i can configure all that very easily, but i guess that there is an easy way to set at least system properties in most ides, it would make sense since they are used for logging and other stuff.
This would also be cleaner than passing them as application args, since they won’t mix with possible application (and buildscript?) specific args.

87

Per default you only pass them to the gradle daemon then, so it filters them.
Still you have to configure it instead of just using the well known dialogue.

However we don’t even have to discuss about that: If there are problems even with the AWT Texture Loader, we cannot work around this bug like this.

88

We can use stb_image as suggested in the issue linked by @the_leo

https://github.com/LWJGL/lwjgl3/blob/master/modules/samples/src/test/java/org/lwjgl/demo/stb/Image.java

89

The work-around solutions seem like too much pain for… what gain exactly?

90

appology for the ignorance but 99% of the time during i develop my app this settings dialog is set not to show. My opinion just remove the settings dialog migrate to the newer version and put knowhow on forum and wiki, leave lowest resolution supported by default.

91

Well, 99% of the time I use the app settings dialog.

So now we cancel each other out in the “anecdotal poll”.

2 Likes
92

I think the AppSettings is very important. Its target audience is especially those just trying to discover JME. Trying out demos and their first code. Stripping it out would make these first steps very difficult.

1 Like