GL11.glGetInteger(GL30.GL_MAX_SAMPLES) returning incorrect value, but only within .exe

[joshsinger]

Just started using packr

My game uses an OpenGL3.0 / LWJGL libgdx feature multi-sample anti-aliasing. It uses the LWJGL's GLContext.getCapabilities().GL_ARB_multisample to check whether this is available, if so it sets LwjglApplicationConfiguration.samples according to the result of GL11.glGetInteger(GL30.GL_MAX_SAMPLES);

What I found is that if I launch the game from the .exe generated by packr, the MSAA capability is detected and the GL_MAX_SAMPLES query returns 32.

However, if I use the java.exe from within the minimised JRE produced by packr, and pass it the jar generated by packr, as its -jar argument, the GL_MAX_SAMPLES query returns 8.

If I try to use the value of 32 in LwjglApplicationConfiguration.samples, it breaks the MSAA feature, and appears as if it has been switched off, whereas if I use the value of 8, it works fine.

So, I have to conclude that the returned GL_MAX_SAMPLES of 32 is incorrect.

Any idea how I can get it to return an accurate value within the .exe ?

[Karl Sabo]

Packr doesn't necessarily use the same classpath as running java -jar, so maybe LWJGL is loading different shared libraries.

Turn on LWJGL shared library loading verbose logging and see if there's a difference between running from packr and running from java. https://github.com/LWJGL/lwjgl3-wiki/wiki/2.5.-Troubleshooting.

[joshsinger]

Thanks,

I'm actually on legacy LWJGL (2.x) -- I'll investigate moving to LWJGL 3 and see what happens.

[joshsinger]

Turns out moving to LWGJL 3, there's a different way to turn on MSAA and it includes handling the device capabilities, so the whole issue goes away.