LWJGL 3 - LMDB bindings

Engines, Libraries and Tools
#21

First off…a big thank you for all your effort on LWJGL3, its good to see the project continuing and that people will be using the library in countless different ways to solve their individual issues. Your categorisation of the modules is interesting. With issue 100 getting implemented I would actually group them up as :

Java Gaming : Core

  • OpenAL
  • OpenGL
  • OpenGL ES
  • EGL
  • GLFW (Display + input API replacement)
  • Vulkan (a good match for LWJGL and also the most user requested API)

Java Gaming : Optional

  • JAWT
  • LibOVR (Oculus SDK)
  • OpenCL

Java Gaming : Util

  • NanoVG
  • stb (image IO, font rendering, vorbis decoding, etc
  • NativeFileDialog
  • Nuklear
  • libstem_gamepad (in a branch, failed experiment, to satisfy concerns about GLFW’s gamepad support)

Java General : Optional

  • xxHash (tiny & fast non-cryptographic hash functions)
  • LMDB (post 3.0.0)
  • ODBC (mostly complete branch)
  • hwloc (incomplete branch)
  • SSE(3)
  • jemalloc
  • Misc system calls
  • dyncall (FFI + dynamically generated native-to-Java callbacks)
  • Basic system calls

I would see a sister project using the LWJGL name but having the G stand for General rather than gaming.

#22

i didn’t know you bound hwloc to java. thanks alot!

i will be, this is great. it’s pretty much what i am waiting for before leaving 2.9.4.

#23

Really, it’s none of my business - I’m just suggesting an even more modular approach to that which Spasi is already undertaking that might ultimately be to the benefit of the LWJGL project as a whole, by minimising the maintenance footprint and focusing on the critical requirements. When I saw that list of stuff in LWJGL just then my mind just boggled at the thought of trying to use it in 5 years’ time only to discover that it hasn’t been maintained for 3 years and no longer works etc etc.

So, hurrah for the concept of the “Core” of basic windowing, OpenGL, OpenAL, input, and now Vulkan. But the rest? I think they would flourish far better if allowed to evolve separately. Even if it is still just Spasi maintaining them for the next few years it will still be easier for him to divest himself of them and hand over these other projects to other maintainers who will have more time and energy.

Cas :slight_smile:

#24

Oh… Sorry for sparking this conversation. It’s deadly. Hey look im the minimalist I’ll just make a minJGL jar and minJAL jar or something. Update it as necessary. I think that will solve a lot of conflict.

#25

I disagree on this. It’s mostly a psychological issue. The more stuff is in a project, the bigger is the hurdle for others to dig into the detailes or take responsibilities.

So modularizing the project on repository and publication level would be a good thing. Other than that, stuff like lmdb would have a lot of use in enterprisy contexts, where disassociating them from a gaming library might have it’s benefits.

Having said that, it would also be a bigger effort to maintain multiple projects, their public visibility and communities. So in the end it depends on the effort you are able and willing to put into it - especially when you are not convinced :wink:

#26

Why do you keep repeating this like it has any sort of significance? Great, you lead a minimalist lifestyle. Please inform me why any of us need to know that, or be reminded every day?

#27

I think at this point it would be best to just ignore Hydroque.
It’s either a massively successful troll or an complete idiot, paying attention to it will not help either.

On topic:

Splitting LWJGL into many different projects simply sounds tedious. I don’t think anyone actually uses all the different functions that OpenGL provides, yet no one here wants OpenGL to be split into many different projects, so why should LWJGL be treated differently? There will almost always be functions in API that you never use, that does not mean they should be excluded from the project. If a part of LWJGL is useful to someone, then there is no reason for it not to be included in LWJGL.

[quote]There was recently also an idea to host a little web application on lwjgl.org where users could select which modules/dependencies they want, which then get bundled into a custom zip download or even an IDE/Maven/Gradle/… project folder.
[/quote]
This sounds great.

#28

Theres no reason be an ass. I am simply stating, as per me causing this thread to go wildfire, that if >I< want LWJGL to be in the image of someone who likes libraries compact and nothing I won’t use, that is my doing. I will do it. I am the minimalist, let me do it. It doesn’t matter how many times I say it. Even if i like to lead my projects that way. I’ve said minimalist only few times in about 3 or 4 different threads.

As per all the hate thrown towards me today, there really isn’t any reason. I am in no way being provocative, but please continue.

#29

i too think the splitting is not an issue on the user side. with enough willpower one can always come up with a gradle/maven/ant script to split/rip classes/binaries when building a distribution package.

on the developer side, if Spasi creates something to support that with convenience, everybody will appreciate it.

looking at the whole project (lwjgl) it is ofc. up to Spasi too to set the course - which can be a very complex issue.

the more native bindings lwjgl provides the better. it’s out-of-the-box-application is just getting more broad.

personally, i would love to see http://graphics.pixar.com/opensubdiv/, http://www.fmod.org/ and http://bulletphysics.org/ bindings sitting there too :wink:

#30

What’ll happen is that the world will largely divide into two camps, one camp being the World+Kitchen Sink camp (Spasi) and the other camp being the one-thing-done-well camp (me, and FWIW, Hydroque). We’re all just tips of icebergs when it comes to sentiments but what will eventually happen is the kitchen sink camp will suffer from Magic Kebab Syndrome* and implode under the weight of unmaintained natives, and there will be someone who goes “bugger this I’m a gonna fork this” and boom! Schism. LWJGL3’s core hives off and becomes a separate minimalist project and the whole effort is like watching waves break on the shore.

Cas :slight_smile:

  • Years ago, Chaz and I were horribly drunk and started speculating on what we’d like to eat, and eventually after many iterations we came up with the idea of a never ending kebab. That was fed to us by Michelle Pfeiffer. And so on. In other words, it was an endless spiral of additional fancies, each more improbable than the last.
#31

In the end, after years of wars, a World+Kitchen Sink boy will fall in love with a one-thing-done-well girl. Against all odds, through their love they bring peace to the world and everyone lives happily ever after.

Except Bob. f**k that guy.
[sup]really hoping no one here is called Bob[/sup]

Opens in cinemas 2019.

#32

Hey guys can I get some medals for bashing Hydroque too? It seems pretty trendy now… What a guy am I right? :persecutioncomplex:

Also, I believe LWJGL should be a super-library with bindings to everything game development… Honestly that’s easier to develop/maintain for than 20+ different libraries all shipping with native code

#33

Progress update:

Needs a lot more work, but all tests and demos run fine.

The resulting binaries are roughly 2x the original lwjgl.dll size, because the CRT is statically linked in every module. It shouldn’t be a problem if only a subset of them is used. Some may be merged into the core library, they’re tiny without the CRT. For example JAWT and jemalloc add about 1kb to lwjgl.dll, but are 83kb and 84kb standalone (note: this is just for the JNI functions, not the libraries themselves). The corresponding modules will still be optional.

#34

As part of issue #100 there is now a working Maven structure, supporting modules, their dependencies and even defining groups of frequently used modules as “starter” kits/bundles.
So, all LWJGL3 modules will be deployed to Maven Central with their module description.
In addition to allowing Maven/Gradle users to easily integrate LWJGL3 into their projects, this is also the groundwork for the LWJGL “Starter Kit” / “Initializr” application, allowing to fully automatically discover, download and repackage selected LWJGL3 artifacts/modules using the Eclipse Aether project. Tested this today with discovering, resolving/downloading and repackaging/flattening a group of artifacts into a single jar, for example for packing all platform natives of all selected modules into a single “platforms” jar file for faster/easier download or deployment.
Ultimately, users will be given a web UI to select modules and then all artifacts and bundles will be packaged into a zip file and streamed as download.

#35

Very cool! Keep 'em coming! 8)

#36

[quote]In addition to allowing Maven/Gradle users to easily integrate LWJGL3 into their projects, this is also the groundwork for the LWJGL “Starter Kit” / “Initializr” application, allowing to fully automatically discover, download and repackage selected LWJGL3 artifacts/modules using the Eclipse Aether project.
[/quote]
I know this isn’t on the side of development of applications/games, not on the side of actual build of LWJGL3, but…

I remember back when I was playing around with Panda3D using python.
I remember back when I was playing around with DirectX using C++.

These two had sample programs with information on how to things such as rendering, audio, FBO-like stuff, and more. It included all necessary assets and commented code. I’ve never seen one for OpenGL, let alone LWJGL as per its bindings.

Just an idea, though we do have a lot of online resources. I found that the offline resources were better… as per could actually run them. A lot of things now-a-days are outdated and the purpose would be demonstrating latest technique.

I think there is a pro to this when it comes to more things being distributed from LWJGL3. The so called “test” games, such as space invaders (which my jar never packaged the assets), was a good contribution. I am not entirely sure what samples there are packaged with LWJGL3, but I would want to, as per the dependency project goes, request a package containing such things and I would be happy to code the samples… yes without my “ideas”.

And don’t reply hate or discouragement. Only constructive discussion :point: :persecutioncomplex:

Tn5ywPFetAY

#37

I think your post can be summarized by:
“I would like to contribute examples to show how to use modern OpenGL.”
We could have a “starters” module that references all available example projects (which can be deployed by anyone anywhere on a Maven repository) to let the user choose from when bootstrapping a new LWJGL3 application. Managing the “starters” could be a way to centralize all possible LWJGL3 demos in the future, so that users would have less trouble finding LWJGL3/OpenGL examples on the internet. (formulated in issue #199 and issue #201)
When the user downloads a LWJGL3 build, the sources of the selected starter will then be packaged as part of the distributable.
Your example could be one of them! :slight_smile:

#38

Build 3.0.1 #6 is now available with modular artifacts. More details and progress update here.

This is what you get with the current structure:

267×803 88.1 KB

#39

Modular maven artifacts are now available in the snapshot repository. More details and a request for feedback, here (you may also reply in this thread if you prefer).

#40

sweet, just in time. thanks alot. :slight_smile: