Hello Guest

Recent Posts

Pages: 1 ... 8 9 [10]
91
OpenAL / Re: Can't get sound to work (LWJGL 3.2.1 build 12, Win10 64-bit)
« Last post by spasi on February 16, 2019, 11:52:00 »
Hey Cas,

A few things to try:

1. Pass NULL to alcOpenDevice:

Code: [Select]
alcOpenDevice((ByteBuffer)null)
2. Print the list of the available devices with:

Code: [Select]
List<String> devices = ALUtil.getStringList(NULL, ALC_ALL_DEVICES_SPECIFIER)
and use one of those names with alcOpenDevice.

3. Enable OpenAL Soft's logging by setting the ALSOFT_LOGLEVEL=3 environment variable. More info here. Anything interesting in the output?

4. Use the OpenAL Soft shared library that comes with LWJGL 2. You can do that easily with -Dorg.lwjgl.openal.libname=<path_to_OpenAL64.dll>. Does that resolve the issue?
92
OpenAL / Can't get sound to work (LWJGL 3.2.1 build 12, Win10 64-bit)
« Last post by princec on February 15, 2019, 17:28:50 »
Try as I might... no sound. LWJGL2.9 works, of course.

My init code:
Code: [Select]
String defaultDeviceName = alcGetString(0, ALC_DEFAULT_DEVICE_SPECIFIER);
LOGGER.finer(() -> "Default OpenAL device: " + defaultDeviceName);
long device = alcOpenDevice(defaultDeviceName);
if (device == 0L) {
throw new IllegalStateException("Can't open device " + defaultDeviceName);
}
int[] attributes = {0};
long context = alcCreateContext(device, attributes);
if (!alcMakeContextCurrent(context)) {
throw new IllegalStateException("Context cannot be made current");
}
alcCapabilities = createCapabilities(device);
alCapabilities = createCapabilities(alcCapabilities);

Prints "Default OpenAL device: OpenAL Soft", as expected. No errors seem to be raised with alGetError (and why should they - the rest of my code is unchanged from 2.9)

Cas :)
93
Bug Reports / RFE / Re: VerifyError at glfwInit
« Last post by princec on February 15, 2019, 11:31:55 »
The jars are ... now ... working fine on the classpath.

This is the sort of random shit that Eclipse / JDK11 is pulling on me constantly. Nothing seems to work properly for no well-explained reason. If I go and make a cup of tea, something else breaks, or something else starts working. Eclipse is proving infuriating and I'd ditch it if I weren't already so totally fluent in using it in every other way. Looks like I'll have to wait a couple of years for them to get their act together.

Cas :)
94
Bug Reports / RFE / Re: VerifyError at glfwInit
« Last post by spasi on February 15, 2019, 10:50:57 »
It's very likely that the issues you faced were caused by Eclipse itself. I don't know if there's been a recent release that's supposed to fix the support for modules, but so far Eclipse has been a constant source of trouble since Java 9. Things that are easy and simple with modules, become impossible in Eclipse because of bugs in the IDE. My recommendation has been: configure the Eclipse project to use the classpath for everything and maybe build releases of your program with Maven/Gradle/etc., if you need jlink or the (theoretical?) benefits of modules.

In general, I would also recommend exploring the various new java/javac parameters and new utilities (jdeps/jlink/etc.) that come with the JDK. There are many ways to diagnose issues that haven't been yet exposed in any IDE afaik.

I still can't get it to work with just the native jars in the classpath - I have to extract and use -Djava.library.path - but I'm fine with that and honestly I think it's a better solution.

Extracting the natives is fine if it matches your workflow and build process. However, using the classpath is very convenient and I haven't heard of issues related to the automatic extraction lately. Could you please try again with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugLoader=true and attach the output here?
95
Bug Reports / RFE / Re: VerifyError at glfwInit
« Last post by princec on February 15, 2019, 09:05:24 »
Hmm yes. So I went down the whole route of trying to make all my projects in Eclipse into JDK11 modules again and ... the module system just doesn't work. It just does not work. It's obscure, complex, and opaque. One can no longer simply browse stuff to see how it fits together. I think it's the worst thing to have happened in the entire history of Java, solving a problem only a tiny, tiny minority of developers actually had at the expense of making a huge, complicated problem for everybody else.

I've reverted back to the released LWJGL and removed all the module bullshit, and I've finally got it to run at 2am. It must have been picking up some strange classpath stuff somehow but as I've never installed LWJGL3 on this machine before I am baffled as to how it was getting mixed up versions. Four hours just to get a window to show!

I still can't get it to work with just the native jars in the classpath - I have to extract and use -Djava.library.path - but I'm fine with that and honestly I think it's a better solution.

Thanks for the reply Spasi... probably going to have a few more questions over the next week or so as I finally migrate 15-year old tech...

Cas :)
96
Bug Reports / RFE / Re: VerifyError at glfwInit
« Last post by spasi on February 15, 2019, 08:19:01 »
Hey Cas,

This can only be explained if there are multiple versions of LWJGL in the classpath/modulepath.
97
Bug Reports / RFE / VerifyError at glfwInit
« Last post by princec on February 15, 2019, 00:07:32 »
What's this all about then...
Code: [Select]
Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    org/lwjgl/glfw/GLFW.glfwGetError(Lorg/lwjgl/PointerBuffer;)I @8: invokestatic
  Reason:
    Type 'org/lwjgl/PointerBuffer' (current frame, stack[0]) is not assignable to 'org/lwjgl/system/CustomBuffer'
  Current Frame:
    bci: @8
    flags: { }
    locals: { 'org/lwjgl/PointerBuffer' }
    stack: { 'org/lwjgl/PointerBuffer', integer }
  Bytecode:
    0000000: b200 0f99 0008 2a04 b800 192a b800 1ab8
    0000010: 001b ac                               
  Stackmap Table:
    same_frame(@11)

at spgl3.game.Display.init(Display.java:83)
at spgl3.game.DisplayTest.main(DisplayTest.java:7)

Running OpenJDK11 (Zulu 11.2.3) on Windows 10 64-bit, LWJGL, LWJGL 3.2.2 SNAPSHOT build 1.
Basically it's the first thing I've tried to do and it ain't working. With -noverify it gets past this problem but then I get this, using the various windows-natives jars on the classpath:

Code: [Select]
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:122)
at org.lwjgl.system.Library.loadNative(Library.java:338)
at org.lwjgl.system.Library.loadNative(Library.java:322)
at org.lwjgl.system.Library.loadNative(Library.java:239)
at org.lwjgl.system.Library.loadNative(Library.java:205)
at org.lwjgl.glfw.GLFW.<clinit>(GLFW.java:673)
at spgl3.game.Display.init(Display.java:83)
at spgl3.game.DisplayTest.main(DisplayTest.java:7)
Caused by: java.lang.SecurityException: sealing violation: can't seal package org.lwjgl: already defined
at java.base/jdk.internal.loader.BuiltinClassLoader.getAndVerifyPackage(BuiltinClassLoader.java:852)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineOrCheckPackage(BuiltinClassLoader.java:817)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.defineOrCheckPackage(ClassLoaders.java:211)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:789)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:700)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:623)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at org.lwjgl.system.MemoryStack.create(MemoryStack.java:85)
at org.lwjgl.system.MemoryStack.create(MemoryStack.java:74)
at java.base/java.lang.ThreadLocal$SuppliedThreadLocal.initialValue(ThreadLocal.java:305)
at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:195)
at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:172)
at org.lwjgl.system.MemoryStack.stackGet(MemoryStack.java:764)
at org.lwjgl.system.MemoryStack.stackPush(MemoryStack.java:773)
at org.lwjgl.system.windows.WindowsLibrary.<clinit>(WindowsLibrary.java:23)
... 8 more

So finally I extract the natives from the jars myself and point at them directly with -Djava.library.path and eventually get to...
Code: [Select]
Exception in thread "main" java.lang.SecurityException: sealing violation: can't seal package org.lwjgl.opengl: already defined
at java.base/jdk.internal.loader.BuiltinClassLoader.getAndVerifyPackage(BuiltinClassLoader.java:852)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineOrCheckPackage(BuiltinClassLoader.java:817)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.defineOrCheckPackage(ClassLoaders.java:211)
at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:789)
at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:700)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:623)
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
at org.lwjgl.opengl.GLCapabilities.<init>(GLCapabilities.java:6318)
at org.lwjgl.opengl.GL.createCapabilities(GL.java:466)
at org.lwjgl.opengl.GL.createCapabilities(GL.java:322)
at spgl3.game.Display.init(Display.java:117)
at spgl3.game.DisplayTest.main(DisplayTest.java:7)

A similar problem to before, and it looks distinctly like something to do with JDK11's brainf*ck module system.

Cas :)
98
Lightweight Java Gaming Library / Re: Is there a replacement for Sys.openURL()?
« Last post by princec on February 14, 2019, 16:46:12 »
Oof, that's a bit of crazy looking code! Thanks for helping me out there, it doesn't look like something I would just dream up overnight...

Cas :)
99
Lightweight Java Gaming Library / Re: Is there a replacement for Sys.openURL()?
« Last post by spasi on February 14, 2019, 15:07:14 »
Hey Cas,

No, there isn't. You could copy the Linux & Windows implementations from LWJGL 2, they're pure java. The macOS implementation depends on the com.apple.eio.FileManager API, that has been removed from JDK 9+ afaik. A solution based on Desktop would be problematic with GLFW, because it initializes AWT. I don't know how BrowserLauncher works.

One solution for macOS would be to launch a separate Java process that uses Desktop (or anything else that depends on AWT) to open the browser, then die immediately.

A solution based on LWJGL 3 would be to use the Obj-C Runtime bindings:

Code: [Select]
long objc_msgSend = ObjCRuntime.getLibrary().getFunctionAddress("objc_msgSend");

// Implements the following Obj-C code using the Obj-C Runtime:
// [[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString: @"https://www.lwjgl.org"]];
try (MemoryStack stack = stackPush()) {
    long string = CFStringCreateWithCStringNoCopy(NULL, stack.UTF8("https://www.lwjgl.org"), kCFStringEncodingUTF8, kCFAllocatorNull);

    long sharedWorkspace = invokePPP(objc_msgSend, objc_getClass("NSWorkspace"), sel_getUid("sharedWorkspace"));
    long url = invokePPPP(objc_msgSend, objc_getClass("NSURL"), sel_getUid("URLWithString:"), string);
    int result = invokePPPI(objc_msgSend, sharedWorkspace, sel_getUid("openURL:"), url);
    System.out.println("SUCCESS: " + (result != 0 ? "YES" : "NO"));

    CFRelease(string);
}

Tested with LWJGL 3's Gears sample, appears to be working fine.
100
Lightweight Java Gaming Library / Re: Is there a replacement for Sys.openURL()?
« Last post by kappa on February 14, 2019, 15:01:50 »
Don't think there is a method in LWJGL3 yet, for an AWT free method just use Runtime.exec (see link for example).
Pages: 1 ... 8 9 [10]