search

LWJGL / lwjgl3

LWJGL is a Java library that enables cross-platform access to popular native APIs useful in the development of graphics (OpenGL, Vulkan, bgfx), audio (OpenAL, Opus), parallel computing (OpenCL, CUDA) and XR (OpenVR, LibOVR, OpenXR) applications.
https://www.lwjgl.org
BSD 3-Clause "New" or "Revised" License
4.83k stars 640 forks source link

Kotlin Multiplatform bindings #448

Open Dico200 opened 5 years ago

Dico200 commented 5 years ago

Hello!

I have worked with LWJGL for about a year now using Kotlin, and I ended up creating kotlin multiplatform stubs for various libraries available in LWJGL. That means I create expect declarations for most of the functions and constants, followed by delegating them to actual definitions in JVM targets.

It is a lot of work to do this, especially when you then have to do the same actual definitions for native targets as well as javascript libraries such as WebGL2.

I wonder if the templates that power LWJGL can be used to generate the expect and actual definitions. I assume it would just require a different generator implementation. We could even generate actual definitions for native targets, as the bindings originate from C/C++ projects.

I would like to have some pointers for where to start. I think the best approach would be to have a separate project/repository which depends on lwjgl3 templates. But I don't really understand the system entirely. Let me know what you think of the idea.

Dico200 commented 5 years ago

It's a similar concept - LWJGL makes the raw C libraries easy to consume from Java. Kotlin multiplatform needs something similar. Currently, it is a cumbersome task to implement the stubs on each target in multiplatform projects.

Not to mention, the quality of the bindings would probably be a lot better and more robust, plus it could include documentation.

Spasi commented 5 years ago

Yes, making the generator produce Kotlin bindings is a long-term goal of LWJGL (the survey asks about it too). Of course, LWJGL is perfectly usable from Kotlin right now, but native Kotlin bindings would have significant advantages:

Generating the Kotlin bindings should be straightforward (needs a lot of work though) and can be done in the same code base.

The native multiplatform target would require a new core module, a different API (e.g. replacing NIO buffers with CPointer and such) and build scripts. This work could be done either in a fork (painful conflicts on every sync with upstream?) or in the same repository using a copy of the existing core & generator modules (features/fixes will need to be synced manually).

Dico200 commented 5 years ago

Yes, exactly. I am busy now but I would be interested in starting/contributing in some months time!

abouzerda commented 2 years ago

Yes, exactly. I am busy now but I would be interested in starting/contributing in some months time!

Any updates?

Dico200 commented 2 years ago

Yes, exactly. I am busy now but I would be interested in starting/contributing in some months time!

Any updates?

I haven't got updates.