Login

1

Vulkan / Re: Vulkan AWT view impossible on Mac Osx

« Last post by spasi on September 14, 2019, 15:00:42 »

I have created the objc-test branch to get you started. See the CoreAnimation.kt template and how the generated code is used in CoreAnimationTest.

2

Vulkan / Re: Vulkan AWT view impossible on Mac Osx

« Last post by Graou on September 13, 2019, 13:59:31 »

I agree to try this track.

However, I think I will probably need some help. My development environments are now limited to Java, PHP, Javascript all under Eclipse. As for Objective-c, I'm just starting.

At first I will try to build lwjgl3 locally hoping to get there alone.
But I think I'll need to be guided on how to proceed. For example I see how to do the JNI with a proprietary library (even in Objective-c). But what I could explore in the inter-system exchange tools lwjgl3 seems a little too advanced for the moment.

3

Vulkan / Re: Vulkan AWT view impossible on Mac Osx

« Last post by spasi on September 13, 2019, 13:17:17 »

Yes, clone and build lwjgl3 locally. Apply the changes you need, test the resulting build locally, then open a pull request so that the official build incorporates the new bindings.

There's no licensing issue. Using ObjC for ObjC APIs is simply easier/safer than doing the same thing in C with the ObjC Runtime.

4

Vulkan / Re: Vulkan AWT view impossible on Mac Osx

« Last post by Graou on September 13, 2019, 10:17:47 »

If I understood correctly you propose to me to recover some of the sources lwjgl3 locally to integrate directly the functionalities that I need?

As a result, it can directly implement the methods in objective-c. Is it to test or to be potentially definitive because in this case is there not a problem of license with Apple?

If we are talking about the same thing, this proposal interests me.

5

Lightweight Java Gaming Library / Re: joml.jar troubles if I run my project from command line

« Last post by sc on September 13, 2019, 10:08:16 »

You only have a single jar file (OGL_Engine.jar) in the classpath. Do you shade all jars into this OGL_Engine.jar file or do you use the "Class-Path" MANIFEST.MF entry to specify all other (LWJGL and JOML) jars?

I'm afraid you lost me there ...

If I open up the OGL_Engine.jar, I can see that there are no other jars included. (Out of curiousity : how would I do that ?) But, there is a manifest.mf file.
No other dependencies specified though.
I'll Google some more to find out how to add everything. Somehow, I thought the IDE was going to do that for me ...
Thanks for steering me in the right direction !

6

Vulkan / Re: Vulkan AWT view impossible on Mac Osx

« Last post by spasi on September 13, 2019, 08:28:32 »

A simpler approach would be adding the necessary bindings to lwjgl3 directly. Like we did recently for the CoreGraphics robot functionality. You may also be able to use Objective-C directly (let me know if the build process is giving you trouble), instead of going through the ObjC Runtime. Simply submit a PR when you have everything you need.

Instructions for building/testing locally:

Code: [Select]

export JAVA_HOME=<path to JDK 8+>
export LWJGL_BUILD_OFFLINE=true
ant compile-templates compile-native
// either use the compiled classes/dylibs directly, or
ant release -Djavadoc.skip // to produce the LWJGL jar files

7

Lightweight Java Gaming Library / Re: joml.jar troubles if I run my project from command line

« Last post by KaiHH on September 13, 2019, 08:25:21 »

You only have a single jar file (OGL_Engine.jar) in the classpath. Do you shade all jars into this OGL_Engine.jar file or do you use the "Class-Path" MANIFEST.MF entry to specify all other (LWJGL and JOML) jars?

8

Vulkan / Re: Vulkan AWT view impossible on Mac Osx

« Last post by Graou on September 13, 2019, 08:01:18 »

Okay, thank you again for your responsiveness.

I think that while waiting LWJGL 3.3 I will try to make a small temporary library to answer this need.

My short-term goal is to verify that Vulkan rendering is possible and satisfying in a JavaFx panel via AWT on Mac Osx.
Although it is a great pleasure for me to make my modest contribution to lwjgl3-awt, the issue is still something that could thwart the future of my project on Mac Osx.

9

Lightweight Java Gaming Library / joml.jar troubles if I run my project from command line

« Last post by sc on September 13, 2019, 07:08:21 »

I've started using lwjgl a couple of weeks ago, and everything was going well until I wanted to run my project from the command line.

I get the error :

Code: [Select]

D:\nb\OGL_Engine\dist>java -jar OGL_Engine.jar
Exception in thread "main" java.lang.NoClassDefFoundError: org/joml/Vector3f
        at be.tpfc.Game.<init>(Game.java:40)
        at be.tpfc.engine.Engine.<init>(Engine.java:48)
        at be.tpfc.Main.main(Main.java:24)
Caused by: java.lang.ClassNotFoundException: org.joml.Vector3f
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        ... 3 more
... as if it cannot find the joml.jar ?

I'm using Netbeans10 on Windows10 with lwjgl-release-3.2.3 (and joml.jar from that release) and AdoptOpenJDK\jdk-11.0.4.11-hotspot.
I've spent a couple of hours on it already, but I have no idea what I'm doing wrong ...

10

Vulkan / Re: Vulkan AWT view impossible on Mac Osx

« Last post by spasi on September 12, 2019, 17:46:54 »

I'm afraid dynamically calling functions that return or accept structs by-value is not currently possible with LWJGL. There is an API for structs in dyncall, but there's no support in the implementation. It is one reason I'm considering restoring the libffi bindings in LWJGL 3.3.

LWJGL 3.3 will also feature a new system for bindings. The org.lwjgl.system.JNI class will be removed and a new API will be available that will allow users to create custom bindings dynamically (in the same way that LWJGL will do it internally). It is very likely that structs by-value will be supported out of the box in that new API (i.e. will be simple and easy to call any function, regardless of signature). There will also be tinycc bindings available for advanced use-cases.