Hello Guest

Recent Posts

Pages: [1] 2 3 ... 10
1
OpenGL / Re: GLFW under Wayland problem
« Last post by spasi on October 30, 2020, 17:07:58 »
Hey Aisaaax,

The missing symbol is indeed a bug in LWJGL's Wayland build. It will be fixed in the next nightly. Thanks!

Missing window decorations is expected on Wayland, since it doesn't support decorations natively. For this and other issues related to Wayland, please see GLFW's issues. Afaict, there's quite a bit of activity on Wayland support.
2
OpenGL / Re: GLFW under Wayland problem
« Last post by Aisaaax on October 30, 2020, 04:30:45 »
I'm using GLFW jars that come with LWJGL.

Tried running the program with this key:
-Dorg.lwjgl.glfw.libname=libglfw_wayland.so
Also tried doing that in code:
Configuration.GLFW_LIBRARY_NAME.set("libglfw_wayland.so");

But it does not compile, because it doesn't have some functions/symbols available:
Code: [Select]
Window init() started
[LWJGL] Loading library: libglfw_wayland.so
[LWJGL] Module: org.lwjgl.glfw
[LWJGL] Loaded from org.lwjgl.librarypath: /tmp/lwjgl<myusername>/3.2.4-build-6/libglfw_wayland.so
/home/<myusername>/bin/jdk1.8.0_231/bin/java: symbol lookup error: /tmp/lwjgl<myusername>/3.2.4-build-6/libglfw_wayland.so: undefined symbol: __wrap_memcpy

So I thought OK. I found the needed symbol and compiled the .so containing it from sources. Then added it to LD_PRELOAD
LD_PRELOAD=./libwrap_memcpy.so

It kinda runs, but there are several bugs. For one thing, the window is undecorated, even if I specify the GLFW window hint as Decorated=true
For another, the rendering frame is for some reason smaller than the window. It's clearly proportional to that, but smaller (see attachment).
You can also notice that despite me not specifying any position, the window is created with some offset from the upper-left corner of the screen, which seems a bit weird.
https://ibb.co/VqvkGT8

Finally, it gives out a couple of errors into Debug log, which for now don't seem to prevent anything from working, but are still worrysome:
Code: [Select]
Window init() started
[LWJGL] GLFW_FEATURE_UNAVAILABLE error
Description : Wayland: The platform does not support setting the input focus
Stacktrace  :
org.lwjgl.glfw.GLFW.nglfwCreateWindow(GLFW.java:1884)
org.lwjgl.glfw.GLFW.glfwCreateWindow(GLFW.java:2059)
view3d.Window.Init_GLFW(Window.java:257)
view3d.Engine.init(Engine.java:59)
view3d.Engine.run(Engine.java:37)
java.lang.Thread.run(Thread.java:748)
[LWJGL] Loading library: libEGL.so.1
[LWJGL] Module: org.lwjgl.egl
[LWJGL] libEGL.so.1 not found in org.lwjgl.librarypath=/tmp/lwjgl<myusername>/3.2.4-build-6
[LWJGL] Loaded from system paths: /lib/x86_64-linux-gnu/libEGL.so.1
[LWJGL] Loading JNI library: lwjgl_opengles
[LWJGL] Module: org.lwjgl.opengles
[LWJGL] Loaded from org.lwjgl.librarypath: /tmp/lwjgl<myusername>/3.2.4-build-6/liblwjgl_opengles.so
[LWJGL] Loading library: libGLESv2.so.2
[LWJGL] Module: org.lwjgl.opengles
[LWJGL] libGLESv2.so.2 not found in org.lwjgl.librarypath=/tmp/lwjgl<myusername>/3.2.4-build-6
[LWJGL] Loaded from system paths: /lib/x86_64-linux-gnu/libGLESv2.so.2
Window handle created 140244037407328
EGL DisplayHandle 140244037251008
EGL caps created
Current context: 3.2 rev 0, Client_Context: 196610
CLES caps created
Current context: 3.2
[LWJGL] GLFW_FEATURE_UNAVAILABLE error
Description : Wayland: The platform does not support setting the input focus
Stacktrace  :
org.lwjgl.glfw.GLFW.glfwShowWindow(GLFW.java:2694)
view3d.Window.Init_GLFW(Window.java:293)
view3d.Engine.init(Engine.java:59)
view3d.Engine.run(Engine.java:37)
java.lang.Thread.run(Thread.java:748)

Any pointers on how to solve all that?
I also gotta say that if I don't specify any library, it still works through wayland on my PC - and it creates a good decorated window and posts no errors.
But on the ARM device it tries to go through X11 -> XWayland, and because there's no X11 hardware support on that device it causes an exception in wayland compositor. So I HAVE TO tell it specifically to use wayland libs.

I'm not sure if it's an LWJGL problem, but I suspect that it's at least partially so because of the symbol lookup errors that suggest that your build might not include something critical.
3
Bug Reports / RFE / LWJGL's AWTGLCanvas displaying half size
« Last post by Jakes on October 30, 2020, 01:56:09 »
Hello everyone,

I'm having this issue on a different machine, where the canvas is being displayed only half the height of the frame canvas area.
So basically if I set the canvas to have 500 x 500, it will only display the 500 x 250 (the bottom half).

this is my code for the frame:

Code: [Select]
frame.setSize(width, height);
frame.setAlwaysOnTop(stayOnTop);
frame.getContentPane().add(canvas, BorderLayout.CENTER);
frame.setUndecorated(false);
frame.pack();
frame.setVisible(true);

this issue only seems to happen on a computer with windows 10, x64

is there any known issue regarding this component?

many thanks in advance,
regards,
Jakes
4
OpenGL / Re: GLFW under Wayland problem
« Last post by Aisaaax on October 29, 2020, 10:07:38 »
Yeah, I did that, but for some reason it just crashes on the very first GLFW call. Like, it doesn't even throw or catch exceptions - just immediately goes to execute the "Finally" block.
very weird.
5
OpenGL / Re: GLFW under Wayland problem
« Last post by spasi on October 29, 2020, 08:31:02 »
Hey, yes, you need to set Configuration.GLFW_LIBRARY_NAME (or the "org.lwjgl.glfw.libname" system property) to "libglfw_wayland.so".
6
OpenGL / GLFW under Wayland problem
« Last post by Aisaaax on October 29, 2020, 04:52:44 »
Hello. I have a system that supports only wayland (there's no x11 graphics drivers at all), and I know that GLFW should have no problems working unter it.
But when I run the jar on that system - it still attempts to go through X11 - Xwayland. And that simply doesn't work (we tried).
I've downloaded the latest LWJGL build and confirmed that all wayland-native .so files are present for GLFW. But it still chooses to attempt to go through X11 versions.

Is there some kind of variable that I'm missing?
7
OpenGL / Re: GLSL UBO indexing
« Last post by CDnoMlqko on October 28, 2020, 11:16:05 »
This looks like a good option. Thank you!
8
OpenGL / Re: GLSL UBO indexing
« Last post by KaiHH on October 28, 2020, 08:01:16 »
Not with UBOs, however if you are targeting at least OpenGL 4.3, then you can use Shader Storage Buffer Objects, that have much more flexible access rules, such as completely dynamic (not just uniform) indexing.
9
OpenGL / Re: GLSL UBO indexing
« Last post by CDnoMlqko on October 28, 2020, 07:31:14 »
I added that and this is the error I get:
Code: [Select]
Fragment info
-------------
0(133) : error C7559: OpenGL requires constant indexes for unsized array access(materials)

Is there any workaround other than making the UBO to have a limited size?
10
OpenGL / Re: GLSL UBO indexing
« Last post by KaiHH on October 27, 2020, 20:54:07 »
...but no error log is produced by glGetShaderInfoLog().
glGetShaderInfoLog() is only to query the logs of shader objects, not of program objects. Linking applies to the program object and would only cause program logs to be generated, which must be queried via: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGetProgramInfoLog.xhtml
Pages: [1] 2 3 ... 10