[SOLVED] Application.restart() with LWJGL v3

Troubleshooting graphics
21

My issue isn’t the same one discussed back in June-July, since in my tests, reshape() is getting invoked.

To test whether my issue was the result a recent Linux, driver, or JVM change, I booted up an older version of Linux (Mint Linux 21.3 Virginia) and ran some simple tests. I didn’t notice any change in behavior.

However, I was able to work around my issue by going back to JME v3.5.2-stable . Apparently my issue relates to some change between v3.5.2-stable and v3.6.0-alpha1.

1 Like
22

Using bisection, I traced my issue back to PR 1752, which changed the default renderer from OpenGL compatibility to OpenGL 3.2 core.

Adding settings.setRenderer(AppSettings.LWJGL_OPENGL2); to my test app solves the issue.

1 Like
23

For posterity, here is the test app I ended up with, including the fix:

public class Main extends SimpleApplication {

    public static void main(String[] args) {
        Main application = new Main();

        AppSettings settings = new AppSettings(true);
        settings.setRenderer(AppSettings.LWJGL_OPENGL2);
        System.out.println(settings);
        application.setSettings(settings);
        System.out.println(
                "start() threadId=" + Thread.currentThread().getId());
        System.out.flush();
        application.start();
    }

    @Override
    public void simpleInitApp() {
        inputManager.addMapping("restart", new KeyTrigger(KeyInput.KEY_P));
        ActionListener listener = new ActionListener() {
            @Override
            public void onAction(String name, boolean keyPressed, float tpf) {
                if (keyPressed) {
                    AppSettings settings = new AppSettings(true);
                    settings.setRenderer(AppSettings.LWJGL_OPENGL2);
                    System.out.println(settings);
                    setSettings(settings);
                    System.out.println("restart() threadId="
                            + Thread.currentThread().getId());
                    System.out.flush();
                    restart();
                }
            }
        };
        inputManager.addListener(listener, "restart");
    }
}
2 Likes
24

If you have time to spare could you outline your workflow to trace down the pr in question? I always find it quite time consuming and you seem to be very quick at this.

1 Like
25

the reshape() issues was fixed, but then in the same thread @tonihele mentioned another issue they had but I couldn’t reproduce with my setup, I still believe is the same problem you had, which I also couldn’t reproduce.

Glad you found the cause. But I’m confused, should it not work regardless of the renderer chosen? Specially the default, I suspect there was a good reason to make 3.2 the current default.
How would someone with a newer opengl requirement fix this?

1 Like
26

I start by checking out a known-bad commit of the jmonkeyengine repo. I write a simple test app and add it to jme3-examples. Then I git checkout a known-good commit and make sure the test passes, by performing a fresh build and running the test app.

Then I select a Git commit roughly halfway between the the known-good and known-bad commits. I check out that commit and build and test it. If that passes, it becomes the new known-good commit. If it fails, it becomes the new known-bad commit.

I repeat the select-and-test process 7 or 8 times to determine the earliest bad commit. Usually the commit message points me to the relevant PR.

This procedure is a special case of the binary search algorithm.

3 Likes
27

You guys might find this interesting:
https://git-scm.com/docs/git-bisect

3 Likes
28

But I’m confused, should it not work regardless of the renderer chosen?

Some very old graphics drivers don’t support OpenGL 3.2 . I’ve seen that issue on my Raspberry Pi.

In this particular case, my graphics driver probably supports OpenGL 3.2, but it either doesn’t do so very well, or else there’s a bug in GLFW, LWJGL, or JMonkeyEngine.

I suspect there was a good reason to make 3.2 the current default.

You can read the official rationale at PR 1752.

How would someone with a newer opengl requirement fix this?

If your app can determine in main() which OpenGL profile to use, you can autoconfigure using setRenderer() prior to start(), as I did in the test app.

If your app can’t automatically determine the best profile, then you might need to provide a command-line option and/or a display-settings screen. The display-settings screen should itself be displayed using the safest settings (perhaps a 640x480 window with LWJGL_OPENGL2 for Linux and LWJGL_OPENGL32 for MacOS).

Both the Acorus project and the jme3-utilities project provide examples of display-settings screens.

1 Like
29

I see, thanks for clarifying! Strangely your driver (version 550.120) was released as recent as September 2024 (Torvalds meme never gets old heh).

Indeed. I made my settings menu based on your great examples, thank you very much for making them! :smiley: