That would work, but the point of this page is kinda also about having an alternative to opengl as it is not being supported as much over time. Glfw if Im correct only uses opengl and it is written in C so we would have to port it to java.
I think LWJGL uses GLFW under the hood, am I wrong?
2 Likes
Yes it supports glfw, but personally it still wouldn’t be as good as javafx, which is default java now and it comes with rendering all in one. Thereby we wouldn’t need lwjgl at all
You mean JavaFX’s graphics acceleration is better than LWJGL’s?
LWJGL3 uses glfw for window creation. If you look at the lwjgl3 code we call the glfw method calls. It isn’t just opengl since its a window toolkit but it’s pretty common to use opengl for it. I used glfw in one of my test projects with bgfx and was running metal not opengl. Javafx was split off from java as of java 11 so it’s now a separate project and since java 9 is no longer supported it would make more sense to use java 11 since it is LTS.
4 Likes
I think my question is, why does jme need stuff from lwjgl? If we use OpenGL and Al bindings from lwjgl, then we would need it, otherrwise, I think it would be easier to do something more native to java like javafx.
JavaFX provides a high level UI & graphical rendering toolkit. It does not provide access to the low-level APIs (OpenGL, and/or Vulkan, for jME 4) that jME needs.
2 Likes
What do think is a good api solution for jme4?
LWJGL3 is going to be the best bet - it provides Java wrappers around just about every low-level graphics API jME developers would want access to, plus some very handy extras. The wrappers are auto-generated, so they’re very stable and stay very close to the underlying C library interfaces, meaning documentation for the C libs is easy to use to write Java code.
1 Like
Ok, I’ll do research on a good solution. Thanks for your feedback.
1 Like
Yeah, never underestimate the ability to look at official OpenGL documentation to solve problems. They 100% apply to lwjgl with very little “to Java” translation.
2 Likes
So bringing this up again, is this going to be used as a complete replacement for openGL right away? Or will there still be opengl support for jme4
The idea is to maintain opengl support, while adding Vulkan support. LWJGL is a large set of bindings that contains low level wrappers for both. GLFW is a window tool kit that is utilized both iirc.
2 Likes
Ok. My plan is to rework openGL first, then add Vulkan, which yes both are supported by the window toolkit.
I’ve uploaded a few things to my github repository.
The zip file has compiled .jar libs, but the core jar is the one needing to be changed a lot.
The rest are finished though, and I’ll upload more over time.
https://github.com/tx672/jME-4
1 Like
what is this repo?
why it have Jars instead of just packages code?
i dont see purpose of this repo,
this one is more reasonable:
I think it would be better to not make new repos called jme4 for ongoing community projects on github, since it may cause confusion.
jme4 will be eventually hosted on the main repo, but we won’t do renaming or rebranding for now.
6 Likes
Ok, I’ll change that.
The purpose is to host the updated code like Trevor’s at least until I have reworked most of the jme3 libs.
The Java code for these will need to be renderer agnostic, compatible with both OpenGL & Vulkan. It should only make use of higher-level resource classes (mesh, textures, etc.). Shaders will either need to be forked (one shader for OpenGL, one for Vulkan) or take special care to be portable between renderers.
So are they already compatible and only shaders needs changed, or do they need to be made agnostic?
A refactoring of rendering APIs will likely result in changes to resource classes that may impact code that uses those classes. We won’t know until the renderers have been written what changes are necessary in the resource classes and how those changes will impact other classes. Ideally the changes to the resource class APIs would be minimal, but it’s impossible to say until the work is already done.
It’s a safe bet that shaders will definitely need some attention.