Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finish LWJGL 3 backend and request for testing #3673

Open
badlogic opened this issue Dec 28, 2015 · 101 comments

Comments

@badlogic
Copy link
Member

@badlogic badlogic commented Dec 28, 2015

LWJGL 3 backend

I just committed the first iteration of the new LWJGL 3 backend. Going forward, i hope this can largely replace the old LWJGL 2 backend, especially on Mac OS X where we have a lot of problems with LWJGL 2. The new backend is also prepared for multi-window environments, altough respective methods in Lwjgl3Application haven't been exposed yet.

The LWJGL 3 backend is structure the same way as the LWJGL 2 backend, including the main module in backends/gdx-backend-lwjgl3 and a test module in tests/gdx-tests-lwjgl3. Everything is wired up with Maven and Eclipse projects so you can test things. I also wired it up with our Ant build, haven't tested that one at all.

It would be amazing if you guys could help test this. I already build snapshots for the new backend, and all the code is merged with master. You can easily switch out the LWJGL 2 backend for the LWJGL 3 backend in Gradle. In your core projects dependencies, change:

compile "com.badlogicgames.gdx:gdx-backend-lwjgl:$gdxVersion"

to

compile "com.badlogicgames.gdx:gdx-backend-lwjgl3:$gdxVersion"

Make sure gdxVersion is set to the latest snapshot version 1.7.3-SNAPSHOT. In your desktop launcher, simply replace LwjglApplicationConfiguration and LwjglApplication with Lwjgl3ApplicationConfiguration and Lwjgl3Application. That's it.

Not implemented yet

  • Window refresh callback for nicer resize
  • HDPI support. Works out of the box on mac os x, but need to scale mouse coords accordingly. They are reported in logical coords, whereas Graphics reports framebuffer size now.
  • Screen mode change related functions in Lwjgl3Graphics. Just haven't gotten around implementing those. Note that when changing the screen mode (e.g. window -> fullscreen), GLFW returns a new window handle. Lwjgl3Input and Lwjgl3Graphics need to re-register all the GLFW callbacks in that case with the new window handle.
  • Clipboard support without AWT on Mac OS X
  • Fix fullscreen toggling. On Mac OS X, the first windowed -> fullscreen switch fails in weird ways, e.g. clearColor has an effect, but rendering doesn't. Subsequent fullscreen -> fullscreen switches work as intended (but those use glfwSetWindowSize instead of creating a new window). On Window (10) fullscreen switching doesn't work at all on HDPI monitors, need to test on normal monitors. Bug for Windows, Bug for Mac OS X. Should be resolved in GLFW, libGDX side does the proper thing.
  • Custom cursors in Lwjgl3Graphics. Haven't checked how to do that yet.
  • Application icon support. This needs to be covered via tools like PackR
  • Platform-specific multi-window API (Lwjgl3Application#newWindow(ApplicationListener, int width, int height)/newWindow(ApplicationListener, DisplayMode)).
  • Controller support. GLFW comes with its own controller API, should be simply to add that to the controllers extension. There's a bug on Windows in GLFW, where all gamepads are reported by the same name. This makes mapping controller types impossible.
  • OpenGL 3.0 support. We should only need to add that to Lwjgl3Application#createGlfwWindow. The Lwjgl3GL30 implementation is prepared, except for Lwjgl3GL30#glGetBufferPointerv
  • Mac OS X (potentially Windows and Linux too): glfwSwapBuffers doesn't block in windowed mode if app window is fully behind other window or minimized. Bug with GLFW. Could "fix" it in our own code.
  • Lwjgl3Input#getTextInput(), can't call into Swing/AWT
  • Non-continuous rendering in Lwjgl3Graphics. It's a bit of a bitch. Lwjgl3Input will already call Graphics#requestRendering() in case new input events arrive
  • Make OpenALAudio thread-safe, put the update on a separate thread

Known Issues

  • LWJGL 3 is based on GLFW. GLFW and AWT don't play nice with each other. Calling Swing/AWT stuff is thus not possible at the moment.
  • On Mac OS X, you need to pass the JVM argument -XstartOnFirstThread when starting your app. We may be able to fix both things to some extend.
  • If you use the multi-window API, understand that any Runnable you post via Gdx.app.postRunnable() may be executed in such a way that the statics in Gdx, like Gdx.graphics may point to a window other than the one for which the runnable was posted.
@intrigus

This comment has been minimized.

Copy link
Contributor

@intrigus intrigus commented Dec 28, 2015

We should ensure that this bug is fixed or we should try to fix it.
glfw/glfw#608

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 28, 2015

We can fix that on our end by checking if the reported position has changed since the last time.

@piotr-j

This comment has been minimized.

Copy link
Contributor

@piotr-j piotr-j commented Dec 28, 2015

I've had a go at it, besides documented things:

  • no fps options in config
  • resize never gets called, related to screen mode stuff probably
  • no way to get Display.getPixelScaleFactor() ie if hdmi is in effect

Seems to be working fine on Win10

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 28, 2015

Resize isn't supposed to get called on startup. Does it get called when you resize the window?

The fps options in config are a very bad idea imo. It's either vsync or not. Limiting fps by sleeping the main thread is a terrible thing and results in jank.

I can see what i can do about exposing whether you are running in HDPI mode or not.

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 28, 2015

Regarding HDPI: we actually now report the real resolution of the framebuffer instead of the logical resolution via Gdx.graphics.getWidth()/getHeight(). A specific flag that says "This is 2x retina" doesn't make a lot of sense imo. You have to accomodate a lot of different screen sizes anyways, which will just work for the 2x retina case as well.

@intrigus

This comment has been minimized.

Copy link
Contributor

@intrigus intrigus commented Dec 28, 2015

Does Clipboard work? It shouldn't work on mac, because it uses AWT.

Will PRs that implement missing features be merged or will you implement the features anyway?

@piotr-j

This comment has been minimized.

Copy link
Contributor

@piotr-j piotr-j commented Dec 28, 2015

After some more investigation, resize is called for each frame while window is being resized. Viewports dont like this for whatever reason and stuff is all kinds of broken.
Yeah sleeping to reduce fps is jank, but some way to throttle would be nice if possible.
If real resolution is reported, a flag is not needed indeed.

@Darkyenus

This comment has been minimized.

Copy link
Contributor

@Darkyenus Darkyenus commented Dec 28, 2015

Regarding HDPI: we actually now report the real resolution of the framebuffer instead of the logical resolution via Gdx.graphics.getWidth()/getHeight(). A specific flag that says "This is 2x retina" doesn't make a lot of sense imo. You have to accomodate a lot of different screen sizes anyways, which will just work for the 2x retina case as well.

Please reconsider, I'd very much like to know in my app whether the hi-dpi mode is active and if it is - what the pixel/point ratio is (to use Apple terminology). For example, I have a 100% UI app. With lwjgl2 backend I launch it on my retina primary monitor and set up the viewport to be in "points", not in pixels (I just divide it by two for now), because otherwise, all UI would be ridiculously small. This works and everything is crisp. But when I drag the window to my secondary, non-retina, monitor, everything is huge, because I can't tell whether or not is the hi-dpi mode active. Graphics already has some Ppi and Density methods, but these don't help much in this case. Something like getLogicalPixelScale() (with less terrible name), which would return 1f on non-retina, 2f on retina, etc. would be very useful and appreciated.

But I may have misunderstood or overlooked something.

@billy1380

This comment has been minimized.

Copy link

@billy1380 billy1380 commented Dec 28, 2015

I am testing on Linux; getting this exception:

LwjglApplication: Couldn't initialize audio, disabling audio
java.lang.NoSuchMethodError: org.lwjgl.openal.AL.create()V
    at com.badlogic.gdx.backends.lwjgl.audio.OpenALAudio.<init>(OpenALAudio.java:72)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:85)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:66)
    at xxxxxxxx.desktop.DesktopLauncher.main(DesktopLauncher.java:38)
Exception in thread "main" java.lang.ExceptionInInitializerError
    at com.badlogic.gdx.backends.lwjgl.LwjglInput.<init>(LwjglInput.java:93)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:93)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.<init>(LwjglApplication.java:66)
    at xxxxxxxx.desktop.DesktopLauncher.main(DesktopLauncher.java:38)
Caused by: java.lang.SecurityException: sealing violation: package org.lwjgl is sealed
    at java.net.URLClassLoader.getAndVerifyPackage(URLClassLoader.java:388)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:417)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
    at org.lwjgl.input.Keyboard.<clinit>(Keyboard.java:265)
    ... 4 more

not getting as far as rendering :(

@Osaris31

This comment has been minimized.

Copy link

@Osaris31 Osaris31 commented Dec 28, 2015

billy1380, that's likely because you didn't replace LwjglApplicationConfiguration and LwjglApplication with Lwjgl3ApplicationConfiguration and Lwjgl3Application everywhere in your desktop launcher.

@billy1380

This comment has been minimized.

Copy link

@billy1380 billy1380 commented Dec 28, 2015

Thanks @Osaris31

@Osaris31

This comment has been minimized.

Copy link

@Osaris31 Osaris31 commented Dec 28, 2015

Nice work @badlogic ;) I tested in my game (I edited Lwjgl3Graphics to add OpenGL3).
It works pretty well, no FPS change from the previous backend, no crash.
A couple issues: my InputAdapter doesn't seem to receive mouseMoved anymore, as well as a few keys (Tab, /, ...), but for exemple WASD and touchDown are still received.

@billy1380

This comment has been minimized.

Copy link

@billy1380 billy1380 commented Dec 28, 2015

Works very nicely... seems to have sorted #3527 too!

@mbrlabs

This comment has been minimized.

Copy link
Contributor

@mbrlabs mbrlabs commented Dec 28, 2015

@Osaris31 i can confirm this (on Linux). The middle button of the mouse is also not working...but polling via Gdx.input.isButtonPressed works fine.

Everything else works great so far.

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 29, 2015

Awesome feedback everyone. I'll try tl stabilize it over the next few days! Please keep the feedback coming. I'll think about a solution for HDPI reporting as well.

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 29, 2015

Oh, and if you report further issues, please always state what OS you are on!

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 29, 2015

@mbrlabs what flavor of Linux are you on using which window manager?

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 29, 2015

@Osaris31 what operating system and version? Fullscreen or windowed?

@Osaris31

This comment has been minimized.

Copy link

@Osaris31 Osaris31 commented Dec 29, 2015

@badlogic Win10, windowed

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 29, 2015

@Darkyenus here's how i fixed HDPI support. Pending minor changes.

  1. Added Graphics#getBackBufferWidthand Graphics#getBackBufferHeight. These report the physical dimension in pixels of the back buffer we render to in OpenGL. These are the sizes you need to use with glViewport and glScissor, as they expect back buffer coordinates. I added a class called HdpiUtils that you can use to keep working in logical coordinates, even when calling glViewport and glScissor.
  2. Graphics#getWidth and Graphics#getHeight as well as all mouse coordinates are always reported in logical screen coordinates, just like the operating system would report them to you. You can check if you are in HDPI mode by comparing the logical width/height to the back buffer width/height.
  3. ScissorStack and viewports of stage2d have been modified to use HdpiUtils instead of directly calling glViewport and glScissor. Your scenario of dragging a window from a HDPI to a normal DPI monitor and back now works flawlessly without any manual scaling or orther stupid stuff.
  4. If you dislike the impedance mismatch between logical and back buffer coordinates, you can enable HDPI reporting via Lwjgl3ApplicationConfiguration#useHDPI. Everything will then be reported in back buffer coordinates, e.g. Graphics#getWidth() and mouse coords, no logical coordinates to be found.
@intrigus

This comment has been minimized.

Copy link
Contributor

@intrigus intrigus commented Dec 29, 2015

LwjglGraphics.GetWidth() doesn't return the logical size (as stated in the javadocs), it returns the frame buffer size, or did I miss something?

@mbrlabs

This comment has been minimized.

Copy link
Contributor

@mbrlabs mbrlabs commented Dec 29, 2015

@badlogic Arch Linux with Cinnamon and windowed

@mbrlabs

This comment has been minimized.

Copy link
Contributor

@mbrlabs mbrlabs commented Dec 29, 2015

@badlogic alright, i guess i figured it out. I am using the touchDragged of the InputProcessor. I tought it's not called because my camera was not moving (but actually it is). It's simply that screenX and screenY are always 0. In the update method of the Lwjgl3Input you are setting the delta values always to zero. Is that intened? Because if i remove these two lines, it works again

@mbrlabs

This comment has been minimized.

Copy link
Contributor

@mbrlabs mbrlabs commented Dec 29, 2015

@badlogic it's actually just Gdx.input.getDeltaX() and Gdx.input.getDeltaY() which are not working correctly...screenX and screenY of the InputProcessor callbacks are fine

@Darkyenus

This comment has been minimized.

Copy link
Contributor

@Darkyenus Darkyenus commented Dec 29, 2015

@badlogic Perfect thanks! So now the "hi-dpi" mode is active by default? i.e. with default settings, when running on retina display, getWidth and getBackBufferWidth will differ? That might break some applications as this behavior (or what we have now) is opt-in in in lwjgl2 backend. Also, the useHDPI for using "most pixels available" is IMO a bit misleading name, because it is not really hi-dpi anymore, it is just making things "small".

What about solving both of these problems with enum setting:

enum HDPIModes {
    NO_HDPI, //Current default lwjgl2 behavior, default and simple, UI is never small, but not crisp on retina
    HDPI, //Your solution, getWidth differs from getBackBufferWidth on retina, for apps that know how to handle it
    FORCE_HDPI; //(or better name), similar to HDPI but getWidth always returns getBackBufferWidth. I am not sure what would it be good for, but somebody will probably find a good use.
}

That way, with NO_HDPI as default, non retina-aware games won't break down when launched on retina display, but others can still use it. Maybe I am overthinking it though.

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 29, 2015

@mbrlabs thanks for figuring it out. DeltaX/Y should work, i'll look into it!

@Darkyenus i think we need to educate users on HDPI. As such, i prefer the correct way of doing it, that is separate logical resolution from physical resolution, which is option 2 in your enum. GLFW introduced this, and i think it's a good way to go about things. The not crispyness of option 1 needs to die. And again, the only thing people need to watch out for in option 2 is glViewport, glScissor and glReadPixels. Something pretty much no libGDX user uses manually anyways. Any usage inside of the core libs will be Hdpi aware.

@badlogic

This comment has been minimized.

Copy link
Member Author

@badlogic badlogic commented Dec 29, 2015

@mbrlabs thanks for reporting, this is fixed now (together with other polling methods).

@mbrlabs

This comment has been minimized.

Copy link
Contributor

@mbrlabs mbrlabs commented Dec 29, 2015

great! i will keep an eye on this backend.
The multi-window support looks very interesting.

@Darkyenus

This comment has been minimized.

Copy link
Contributor

@Darkyenus Darkyenus commented Dec 29, 2015

@badlogic Ok, that will lead to (hopefully) better applications, but has steeper learning curve. In that case, do we need the useHDPI flag at all? Hi-DPI is always enabled, so the name is a bit confusing and I am not sure if it is worth having, same effect can be achieved by just calling different methods, so it only adds internal complexity for no real benefit. At least I can't see any use case.

@FortressBuilder

This comment has been minimized.

Copy link

@FortressBuilder FortressBuilder commented Dec 30, 2015

  • In Lwjgl3Application#loop: It is probably better to reuse the closedWindows array instead of creating it inside the loop every frame.
  • The callbacks should be release()d once they are not used any more and GLFW should be glfwTerminate()d. You can run the program with -Dorg.lwjgl.util.DebugAllocator=true to have the location of memory leaks reported.
  • In Lwjgl3Application#createGlfwWindow: Instead of parsing the GL_VERSION and using glfwExtensionSupported you can use the GLCapabilities instance returned by GL.createCapabilities() to check for supported versions or extensions.
  • In Lwjgl3Application#initializeGlfw: You create a glfw error callback but don't ever set it with glfwSetErrorCallback. This should be done before glfwInit so initialization errors are reported as well.
@raeleus

This comment has been minimized.

Copy link
Contributor

@raeleus raeleus commented May 22, 2016

Has there been any success with solving the following:

Can't load IA 32-bit .dll on a AMD 64-bit platform

Unfortunately my project depends on gdx.tools and LWJGL3. Combining the two doesn't seem to mesh as mentioned earlier:

The SharedLibraryLoader probably extracts the dlls to the same folder. Both (lwjgl-backends) have a lwjgl.dll as a dependency. Since they are exported to the same folder it doesn't work. The solution may be to rename lwjgl.dll to lwjgl3.dll. The 32bit on 64bit windows errors are thrown, because in lwjgl 2 there was a lwjgl.dll (32bit) and a lwjgl64.dll . Lwjgl 3 has a lwjgl.dll (64bit) and a lwjgl32.dll.

Refreshing the gradle cache seems to have no effect on this issue.

@cypherdare

This comment has been minimized.

Copy link
Contributor

@cypherdare cypherdare commented May 25, 2016

For the checklist, will we be picking this (native file dialogs)up? I suspect it's what you were referring to on the LibGDX blog as something to add to LWJGL3Window.

@intrigus

This comment has been minimized.

Copy link
Contributor

@intrigus intrigus commented May 25, 2016

@cypherdare this should be available, when #4104 has been merged.

@piotr-j

This comment has been minimized.

Copy link
Contributor

@piotr-j piotr-j commented May 25, 2016

Since 1.9.3 window resizing doesn't work on osx. Minimising or attempting to change the size of the window causes resize(0, 0) to be called immediately. 1.9.2 works fine.

@cypherdare

This comment has been minimized.

Copy link
Contributor

@cypherdare cypherdare commented May 26, 2016

@piotr-j Are you using window size limits? I just discovered a couple days ago that on OSX only, if you set any of the four limits to something besides "don't care" it will do what you described. Leaving all of them as "don't care" did not trigger the issue. Setting them all to some value (even 0 or 9999) fixed it so there's a work around we could put in.

@piotr-j

This comment has been minimized.

Copy link
Contributor

@piotr-j piotr-j commented May 26, 2016

@cypherdare i have no idea what those are, so probably not. Where are the settings for that?

@cypherdare

This comment has been minimized.

Copy link
Contributor

@cypherdare cypherdare commented May 26, 2016

@piotr-j It's in the Lwjgl3ApplicationConfiguration. Try setting config.setWindowSizeLimits(0, 0, 9999, 9999) and see if it affects the issue.

@kotcrab

This comment has been minimized.

Copy link
Contributor

@kotcrab kotcrab commented May 26, 2016

@piotr-j I reported the same thing here #3673 (comment) but on Windows it's only called with 0 when window is being minimized.
I've used if (width == 0 && height == 0) return; in resize(...) as simple workaround.

@piotr-j

This comment has been minimized.

Copy link
Contributor

@piotr-j piotr-j commented May 26, 2016

@cypherdare @kotcrab setting the window size limits to non default values fixes the problem. Perhaps it helps on windows as well? Looks like its a bug in GLFW.

@kotcrab

This comment has been minimized.

Copy link
Contributor

@kotcrab kotcrab commented May 26, 2016

@piotr-j config.setWindowSizeLimits(0, 0, 9999, 9999) doesn't help on Windows.

@cypherdare

This comment has been minimized.

Copy link
Contributor

@cypherdare cypherdare commented May 26, 2016

@piotr-j @kotrab I think we might be talking about two different issues. One where an unnecessary resize(0, 0) call is made when minimizing in Windows, and one where the window is actually physically resized to 0, 0 when manually resizing a window on OSX. The second issue is the one where config.setWindowSizeLimits(0, 0, 9999, 9999) seems to help.

@CreamyCookie

This comment has been minimized.

Copy link
Contributor

@CreamyCookie CreamyCookie commented Jul 18, 2016

@badlogic I've found 2 small issues:

  1. Lwjgl3ApplicationConfiguration has no addIcon function.

  2. When I start Hiero (from GDX-tools) I get this (it works with LWJGL 2):

Exception in thread "AWT-EventQueue-0" java.lang.SecurityException: sealing violation: package org.lwjgl.opengl is sealed
    at java.net.URLClassLoader.getAndVerifyPackage(URLClassLoader.java:399)
    at java.net.URLClassLoader.definePackageInternal(URLClassLoader.java:419)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:451)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.setVSync(LwjglGraphics.java:557)
    at com.badlogic.gdx.backends.lwjgl.LwjglCanvas.initialize(LwjglCanvas.java:123)
    at com.badlogic.gdx.backends.lwjgl.LwjglCanvas.<init>(LwjglCanvas.java:68)
    at com.badlogic.gdx.tools.hiero.Hiero.<init>(Hiero.java:182)
    at com.badlogic.gdx.tools.hiero.Hiero$21.run(Hiero.java:1579)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)


I'm using gdxVersion = '1.9.4-SNAPSHOT' on Ubuntu 16.04
Java is /usr/lib/jvm/java-8-openjdk-amd64/bin/java

btw. Thanks for your work! 👍

@xGnoSiSx

This comment has been minimized.

Copy link

@xGnoSiSx xGnoSiSx commented Oct 19, 2016

I may be a total ass for reporting this here, but I just tried the gdx-tests-lwjgl3 starter app on a new libgdx cloned repo (latest & greatest version) and got the below. Are these not changed or implemented just yet?

[LWJGL] GLFW_INVALID_VALUE error
Description : Invalid window size limits
Stacktrace :
org.lwjgl.glfw.GLFW.glfwSetWindowSizeLimits(GLFW.java:1968)
com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createGlfwWindow(Lwjgl3Application.java:415)
com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:366)
com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.(Lwjgl3Application.java:107)
com.badlogic.gdx.tests.lwjgl3.Lwjgl3TestStarter.main(Lwjgl3TestStarter.java:45)

@cypherdare

This comment has been minimized.

Copy link
Contributor

@cypherdare cypherdare commented Oct 20, 2016

@xGnoSiSx Try setting applicationConfig.setWindowSizeLimits(0, 0, 9999, 9999);.

There is a GLFW bug (fixed here) that has not trickled down to an LWJGL release yet.

@magicgoose

This comment has been minimized.

Copy link
Contributor

@magicgoose magicgoose commented Oct 31, 2016

regarding useHDPI:

How do I get real screen density? The Gdx.app.graphics.density is the same value regardless of useHDPI value.

Also, contrary to #3673 (comment), I get doubled pixels when useHDPI is false. (running on a rMBP with OS X 10.11.6)

I'm testing it with libgdx 1.9.5-SNAPSHOT

@ghost

This comment has been minimized.

Copy link

@ghost ghost commented Dec 11, 2016

There is a bug with controller support. It doesn't exist(I think)

Exception in thread "main" com.badlogic.gdx.utils.GdxRuntimeException: Error creating controller manager: com.badlogic.gdx.controllers.lwjgl3.Lwjgl3ControllerManager
	at com.badlogic.gdx.controllers.Controllers.initialize(Controllers.java:105)
	at com.badlogic.gdx.controllers.Controllers.addListener(Controllers.java:52)
	at com.qookie.ludumdare.LDMain.create(LDMain.java:74)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.initializeListener(Lwjgl3Window.java:275)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.update(Lwjgl3Window.java:242)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop(Lwjgl3Application.java:138)
	at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:107)
	at com.qookie.ludumdare.desktop.DesktopLauncher.main(DesktopLauncher.java:13)
Caused by: com.badlogic.gdx.utils.reflect.ReflectionException: Class not found: com.badlogic.gdx.controllers.lwjgl3.Lwjgl3ControllerManager
	at com.badlogic.gdx.utils.reflect.ClassReflection.forName(ClassReflection.java:30)
	at com.badlogic.gdx.controllers.Controllers.initialize(Controllers.java:102)
	... 7 more
Caused by: java.lang.ClassNotFoundException: com.badlogic.gdx.controllers.lwjgl3.Lwjgl3ControllerManager
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:264)
	at com.badlogic.gdx.utils.reflect.ClassReflection.forName(ClassReflection.java:28)
	... 8 more
@BSVogler

This comment has been minimized.

Copy link

@BSVogler BSVogler commented Apr 18, 2017

@badlogic: I understand your argumentation on the limitFPS/vsync but I think you miss something. What if I don't want to enable v-sync because of the one-frame lag but still don't want my CPU or GPU to run at 100%? There is no need for 300 FPS on a 60 HZ monitor. As far as I can see this is currently not possible with the new API.

@thekeenant

This comment has been minimized.

Copy link

@thekeenant thekeenant commented Jun 12, 2018

There seems to be really bad input lag for text fields with the lwjgl3 backend only when vsync is enabled. I created a small test and it demonstrates the issue on my machine (ubuntu 16.04). The key typed callback is really slow - key up and down are normal. Also, the lwjgl backend is fine, just lwjgl3.

  • video demo: the output to the screen is just tied to an input processor, you can see how the key typed one lags behind the others if you type fast. Once I disable vsync it is fixed.
  • source
@Darkyenus

This comment has been minimized.

Copy link
Contributor

@Darkyenus Darkyenus commented Jun 12, 2018

@thekeenant That looks pretty severe. Does this still happen when you turn off vsync but "simulate it" by putting Thread.sleep(1000/60) (or more) into render()?

@thekeenant

This comment has been minimized.

Copy link

@thekeenant thekeenant commented Jun 12, 2018

@Darkyenus I get the same effect with vsync off and Thread.sleep(1000/60) . Hard to say if the effect is compounded with both vsync on and thread sleep on. updated this gist

Edit: Can't reproduce on Windows 10 with the same hardware.

@Darkyenus

This comment has been minimized.

Copy link
Contributor

@Darkyenus Darkyenus commented Jun 13, 2018

I can't reproduce it on OSX 10.11.6, even with high sleep times, so this is probably not libGDX but GLFW related. The closest thing I found on their issue tracker to this is this issue, but I'm not sure if it is the same problem.

@thekeenant

This comment has been minimized.

Copy link

@thekeenant thekeenant commented Jun 13, 2018

@Darkyenus Yeah I noticed that after I posted and it definitely looks related... Might try plain GLFW and see what happens. For now I can stick with good old lwjgl - thanks for the help!

@jpauty

This comment has been minimized.

Copy link

@jpauty jpauty commented Nov 20, 2018

I've opened the following PR #5443 . This is a fix for mouses with "continuous" wheels or osx touch pads. These devices can report scroll events that are lower than one. They also support acceleration and report scroll events greater than one. Without the PR the scroll is ultra fast, because small movements (e.g. a scroll of 0.1) are rounded up to scroll events of 1 unit.

This only fixes vertical scrolling. Horizontal could be better propagated from lwjgl to libgdx, but this would require some API changes.

Could anybody review this PR ?

@egordorichev

This comment has been minimized.

Copy link

@egordorichev egordorichev commented Dec 17, 2018

I can report that running default template project (generated without any extensions or other things) on macos with this backend causes crash:

java.lang.ExceptionInInitializerError
  at org.lwjgl.glfw.GLFW.glfwCreateWindow(GLFW.java:1647)
  at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createGlfwWindow(Lwjgl3Application.java:442)
  at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:391)
  at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.createWindow(Lwjgl3Application.java:379)
  at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:108)
  at org.rexcellentgames.burningknight.desktop.DesktopLauncher.main(DesktopLauncher.java:134)
Caused by: java.lang.IllegalStateException: GLFW windows may only be created on the main thread and that thread must be the first thread in the process. Please run the JVM with -XstartOnFirstThread. For offscreen rendering, make sure another window toolkit (e.g. AWT or JavaFX) is initialized before GLFW.

Tried running with -XstartOnFirstThread, getting the same result. Tried every possible fix found on web - no result.

@code-disaster

This comment has been minimized.

Copy link
Member

@code-disaster code-disaster commented Dec 17, 2018

Tried running with -XstartOnFirstThread, getting the same result. Tried every possible fix found on web - no result.

I've never seen this fail. Make sure you set this as a VM parameter, not as a command line argument.

@egordorichev

This comment has been minimized.

Copy link

@egordorichev egordorichev commented Dec 17, 2018

@code-disaster I'm not sure what in lwjgl3 backend causes it, but anyway, I tried every single possible way to fix it suggested online and dug up the source, yet did not find a fix. Had to roll my huge codebase back to lwjgl2 backed to get mac support working. It's not too bad, but I really miss some features :x

@electronstudio

This comment has been minimized.

Copy link

@electronstudio electronstudio commented Aug 2, 2019

@egordorichev If you are adding -XstartOnFirstThread to the launch options in IntelliJ it does not work. You have to add it to the run task.

task run(dependsOn: classes, type: JavaExec) {
    main = project.mainClassName
    classpath = sourceSets.main.runtimeClasspath
    standardInput = System.in
    workingDir = project.assetsDir
    ignoreExitValue = true
    jvmArgs '-XstartOnFirstThread'
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.