Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (775)
Games in Android Showcase (230)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  LWJGL 3 - LMDB bindings  (Read 38045 times)
0 Members and 1 Guest are viewing this topic.
Online Spasi
« Posted 2016-05-02 19:10:05 »

There's a new lmdb branch in the LWJGL 3 repository that implements bindings to LMDB. It's an embedded key-value store that may be used for all kinds of persistence, from game settings to shaders, models and textures (binary values up to Integer.MAX_VALUE in size are supported).

See this presentation to understand what's special about LMDB.
See this LWJGL sample for a demo of the API and an example of zero-copy string persistence.

The nightly builds do not include LMDB yet, you'll have to clone LWJGL and build locally to give it a try. I'll decide what to do after the 3.0.0 release, but it's definitely small enough to embed in the standard LWJGL distribution. Please let me know if you're interested.
Online Spasi
« Reply #1 - Posted 2016-06-05 11:21:44 »

The first LWJGL 3.0.1 nightly build is now available and it includes LMDB.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #2 - Posted 2016-06-05 13:11:56 »

that is pretty awesome. tho' i'd be more intersted in LMDB stand-alone bindings.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Spasi
« Reply #3 - Posted 2016-06-05 13:44:44 »

tho' i'd be more intersted in LMDB stand-alone bindings.

That will be 3.0.1's primary feature.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #4 - Posted 2016-06-05 15:11:47 »

can't wait for it Smiley
Offline ziozio
« Reply #5 - Posted 2016-06-06 18:22:30 »

@spasi

Couple of things

1. This link doesn't work :

https://github.com/LWJGL/lwjgl3/blob/lmdb/modules/core/src/test/java/org/lwjgl/demo/util/lmdb/LMDBDemo.java
I think it should be
https://github.com/LWJGL/lwjgl3/blob/master/modules/core/src/test/java/org/lwjgl/demo/util/lmdb/LMDBDemo.java

2. I understand what the LMDB is, I can think of non gaming scenario's where this is very useful. But what do you see as the use case in a gaming sense for a database (and one that is super fast)?
Online Spasi
« Reply #6 - Posted 2016-06-06 18:31:53 »

1. This link doesn't work :

Thanks, fixed.

2. I understand what the LMDB is, I can think of non gaming scenario's where this is very useful. But what do you see as the use case in a gaming sense for a database (and one that is super fast)?

I mentioned some ideas in the first post. I often see game developers creating custom solutions for storing user settings, game saves, metadata for shaders/models/textures, game levels, etc. I think replacing all that with a robust, easy-to-use and very efficient database like LMDB would be useful. It can even be used to store binary blobs (meshes, textures, sounds, shader binaries).
Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #7 - Posted 2016-06-06 23:47:00 »

It seems to me that a lot of this shouldn't be included into core LWJGL. I am a minimalist and would love each sub library of LWJGL to be a separate .JAR or a plugin. I have checked out some of the posts from you Spasi, but I can't really follow along with what they say because they lack "this is what this is" but just "here is why we are doing this and whats to come of it." So I am not in the now, like you seen in another post.

I might never migrate to a newer LWJGL than before you added a bunch of stuff. I might actually rip a lot out of the jar if thats the case.

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Offline delt0r

JGO Wizard


Medals: 145
Exp: 18 years


Computers can do that?


« Reply #8 - Posted 2016-06-07 06:07:45 »

Looks really interesting. Def will check it out.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2016-06-07 09:11:01 »

I'm slightly shocked to discover I agree with something @Hydroque says! I'm really not at all sure how this fits in with LWJGL, either in a gaming context, a general purpose graphics context, or even in a Java context... I'm very reluctant to bind to native code to do stuff that Java code can do. The LWJGL was all about binding to native APIs that could not otherwise be done in Java - minimising the area of the native interface footprint to the bare minimum to get the job done - and it seems there's a bit of "kitchen sink" syndrome going on.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline KaiHH

JGO Kernel


Medals: 636



« Reply #10 - Posted 2016-06-07 10:03:46 »

I think that's the reason why Issue #100 exists, for users to be able to exclude what they don't need.
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.
At least I envision it much like the Spring Initializr site for the Spring framework.
Online Spasi
« Reply #11 - Posted 2016-06-07 10:16:32 »

This is why I waited for the 3.0.0 release before merging the LMDB branch. I expected some controversy and wanted to see if enough users would find it useful first. Currently LMDB only exists in a nightly build of 3.0.1. No harm has been done. This is also the 3rd time I have to mention in this forum that 3.0.1 will not be released without a solution for #100, which will break the LWJGL distribution in separate artifacts for each binding; you will be able to choose what you want or don't want in your application.

I'm really not at all sure how this fits in with LWJGL, either in a gaming context, a general purpose graphics context

Offering solutions for gaming and graphics has always been LWJGL's primary objective and what most people in this forum care about. But it's not only about that. Which makes sense since I'm (almost) the sole developer, I use it a lot in my projects and I don't make games.

I bet no more than 5 users have ever used LWJGL's OpenCL bindings, yet I find them super-important and have spent countless hours working on them. Why aren't there any complains about those?

or even in a Java context... I'm very reluctant to bind to native code to do stuff that Java code can do. The LWJGL was all about binding to native APIs that could not otherwise be done in Java

I don't agree with this either. Just because something can be implemented in Java does not mean it should. I've actually done it: JGLFW. It was a GLFW implementation written entirely in Java, using only bindings to OS functionality. It was an experiment to validate LWJGL 3's approach to JNI and I gladly deleted it when I became satisfied it worked nicely. Why?

- Look at the mess LWJGL 2 was in. There were dozens of bugs and no one to fix them. Who's going to write a decent windowing system in Java (or anything that touches lots of OS-specific APIs like GLFW and LMDB) and maintain it?
- A Java binding to a native library means that Java developers benefit from the existing community in many ways: more example code out there to get you started, more users testing the same code, more users contributing fixes. The existing community benefits too, Java developers can contribute feedback and fixes to the native library (there are many examples of that in GLFW already). Overall, the bigger the ecosystem around a library the better for everyone involved.
- Why reinvent the wheel?
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #12 - Posted 2016-06-07 10:26:00 »

LWGL has OpenCL bindings? Yum! I'll definitely be trying those out (in a non-gaming context) Smiley

Online Spasi
« Reply #13 - Posted 2016-06-07 10:33:53 »

I might actually rip a lot out of the jar if thats the case.

This is possible and some users do it. You can remove any binding package you don't need from lwjgl.jar and you can also delete the jemalloc/GLFW/OpenAL shared libraries. #100 will make it so that you don't have to do it manually and will also split the lwjgl shared library itself (which contains the core functionality + statically linked bindings).
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2016-06-07 11:37:43 »

This is why I waited for the 3.0.0 release before merging the LMDB branch. I expected some controversy and wanted to see if enough users would find it useful first. Currently LMDB only exists in a nightly build of 3.0.1. No harm has been done. This is also the 3rd time I have to mention in this forum that 3.0.1 will not be released without a solution for #100, which will break the LWJGL distribution in separate artifacts for each binding; you will be able to choose what you want or don't want in your application.
I think you're being a little defensive about my observations, Spasi! I'm quite aware of the 3.0.1 goals already. What I am questioning is that LWJGL is, as a whole, becoming quite a sprawling mess of functionality, and that (as you allude to below), it appears to be largely driven by you and your own personal needs and as such seems to me to have become a giant git repository with all of your open source work in it. This is an important observation, which I'll get to...

What it definitely isn't, modular or not, is a lightweight Java games/graphics library! It's no longer a lightweight project as it covers everything from GUIs to compute to audio to in-memory databases to hacking the Java language to get structs in. It's not Java any more as it now contains multiple binary libraries. It's not a single library now but a whole multitude of libraries. So there's that to think upon.

Quote
I bet no more than 5 users have ever used LWJGL's OpenCL bindings, yet I find them super-important and have spent countless hours working on them. Why aren't there any complains about those?

Because it still satisfies the original premise of LWJGL, which is the minimum and most direct binding to a native API possible to achieve something vaguely game-related. Personally I wouldn't have included it either, but I'll get to why in a mo...

Quote from: Spasi
Quote from: princec
or even in a Java context... I'm very reluctant to bind to native code to do stuff that Java code can do. The LWJGL was all about binding to native APIs that could not otherwise be done in Java
I don't agree with this either. Just because something can be implemented in Java does not mean it should.
There are many ways to implement functions, but the question is not which language something should be implemented in, but whether it should be implemented at all. The crux of the matter hinges on a comment you made about LWJGL 2:
Quote
- Look at the mess LWJGL 2 was in. There were dozens of bugs and no one to fix them. Who's going to write a decent windowing system in Java (or anything that touches lots of OS-specific APIs like GLFW and LMDB) and maintain it?

What LWJGL 3 is now is a vast collection of bindings, most of which are irrelevant to most people. What this means is that maintenance effort is going to be simply non-existent on it, and once you (eventually) grow tired of it, and you will, it'll just stagnate and get bitrot and become a large legacy which will distract people from otherwise creating separate efforts to solve specific issues.

I lost interest in maintaining LWJGL after a few years of developing on it, largely because it did everything I needed it to by that point, and also because I was seeing virtually no return on my efforts. I watched Markus accumulate two and a half billion dollars on the back of the literally months and months of effort I'd put in on the library he used to catapult himself into the realms of the unspeakably rich with barely so much as a thankyou, and that, for me, was the point at which I decided I couldn't be arsed with open source any more. I only have so much time left in the world and a lot of things I'd like to do, and making Markus richer wasn't on the list, so I diverted my efforts elsewhere. At some point, you too will find something more interesting and distracting, and you'll be leaving behind a huge, huge pile of stuff which no-one except you really cares too much about.

I strongly advise you to split LWJGL up into the bare minimum and then create separate, independent projects that build on top of or besides LWJGL for GUI libraries, structs, OpenCL, in-memory databases, vector math, etc.

Cas Smiley

Offline Gornova
« Reply #15 - Posted 2016-06-07 11:46:42 »

@princec: A pain to read as open source lover and believer Sad


Blog | Last game Drone Swarm
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2016-06-07 11:57:52 »

Don't get me wrong, I love open source and I'm proud of what little I managed to accomplish, but the expected returns never quite materialised for me.

Cas Smiley

Offline CommanderKeith
« Reply #17 - Posted 2016-06-07 14:50:15 »

It's a pity to de-motivate the project lead like that. The main currency in open-source projects is respect, fame and the warm feeling of being altruistic and you've painted a sorry picture of them all! 

Whether or not LWJGL is truly lightweight, it's open source and can easily be forked.
If it's also modular as promised, even better. Making separate Git projects out of it is another good solution and can always be done in the future.

I don't think that Spasi's additions do any harm and he brings up interesting libraries that I'd never heard of before since they're not in the java ecosystem, but appear to be best practice in the C world. Putting together a bare bones 'best practice' game dev library is useful. I imagine that it's also easier to manage build scripts and forums and what-not by combining all these projects into one, saving Spasi's and others' precious time.

The huge amount of work that Spasi has put into LWJGL3 and the sister-projects should be celebrated. It is judging by his medal count! It's a shame to criticise him for going even further beyond the call of duty by including extra interesting stuff.

Quote
What LWJGL 3 is now is a vast collection of bindings, most of which are irrelevant to most people. What this means is that maintenance effort is going to be simply non-existent on it, and once you (eventually) grow tired of it, and you will, it'll just stagnate and get bitrot and become a large legacy which will distract people from otherwise creating separate efforts to solve specific issues.

I lost interest in maintaining LWJGL after a few years of developing on it, largely because it did everything I needed it to by that point, and also because I was seeing virtually no return on my efforts. I watched Markus accumulate two and a half billion dollars on the back of the literally months and months of effort I'd put in on the library he used to catapult himself into the realms of the unspeakably rich with barely so much as a thankyou, and that, for me, was the point at which I decided I couldn't be arsed with open source any more. I only have so much time left in the world and a lot of things I'd like to do, and making Markus richer wasn't on the list, so I diverted my efforts elsewhere. At some point, you too will find something more interesting and distracting, and you'll be leaving behind a huge, huge pile of stuff which no-one except you really cares too much about.
That's a shame that you feel that way. I think you know there's more to life than cash and fame, you probably just had a rotten day.
Think of all the mathematicians, scientists, engineers and writers who did amazing things and didn't get paid a cent for their life's work. They're not losers for being hard working and altruistic, they toiled for a purpose above themselves which added to their sense of life fulfillment and contributed to better living standards for everyone.
I mean, why do you think that the super wealthy always create universities named after themselves such as Stanford, Yale and Duke? It's a cliche, but making a ton of money above the average income doesn't fulfill life's higher aims.
As a LWJGL dev you should be proud to have contributed to the sensation that was Minecraft. Markus wasn't obliged to reflect any cash or fame on the downstream tech that he used. From memory he did have a credits page on Mincraft.net which linked to LWJGL and generated much interest there and also here at JGO, promoting Spasi and princec and all the other LWJGL devs which will help them get work in the future on anything graphics and game-related, in addition to respect in the game-dev community.
I'm sure Markus will drop in one day to remember the good old times and thank everyone who made tech like LWJGL.
Thanks to all the devs who made and continue to make lwjgl, java, javagaming.org, libgdx, and all the other incredible projects  Cool

Online Spasi
« Reply #18 - Posted 2016-06-07 15:21:46 »

it appears to be largely driven by you and your own personal needs and as such seems to me to have become a giant git repository with all of your open source work in it.

Let's be fair here.

LWJGL 2 bindings that we ought to have in LWJGL 3:

- OpenAL
- OpenCL
- OpenGL
- OpenGL ES
- EGL

Bindings that were absolutely necessary in LWJGL 3:

- GLFW (Display + input API replacement)
- Vulkan (a good match for LWJGL and also the most user requested API)
- dyncall (FFI + dynamically generated native-to-Java callbacks)
- Basic system calls

Bindings requested by users:

- JAWT
- LibOVR (Oculus SDK)
- NanoVG
- SSE(3)
- Misc system calls

Bindings that I added without anyone asking, but everyone agreed were extremely useful:

- jemalloc
- stb (image IO, font rendering, vorbis decoding, etc)

Bindings that I added without anyone asking, are not that exciting, but try to solve real problems LWJGL users face:

- NativeFileDialog
- Nuklear
- libstem_gamepad (in a branch, failed experiment, to satisfy concerns about GLFW's gamepad support)

Bindings that I added without anyone asking, either from curiosity or because I needed them for personal work:

- xxHash (tiny & fast non-cryptographic hash functions)
- LMDB (post 3.0.0)
- ODBC (mostly complete branch)
- hwloc (incomplete branch)

I hope it's obvious that the majority of the work I did was driven by user needs. The only personal binding that made it to 3.0.0 is negligible compared to the rest.

What it definitely isn't, modular or not, is a lightweight Java games/graphics library! It's no longer a lightweight project as it covers everything from GUIs to compute to audio to in-memory databases to hacking the Java language to get structs in.

I would argue that it is indeed lightweight because it doesn't do anything. None of the APIs or functionality provided by LWJGL has been designed or written by LWJGL developers. The only thing the LWJGL core provides is a half-decent way to interact with native APIs and data from Java/JVM.

Also, why is any of the above an issue if #100 allows you to download LWJGL core, GLFW, OpenGL and OpenAL and nothing else?

It's not Java any more as it now contains multiple binary libraries. It's not a single library now but a whole multitude of libraries.

I don't get this. Why does it matter how many binaries there are? Deployment issues are a thing of the past with the SharedLibraryLoader. LWJGL 2 also had two native binaries (lwjgl + OpenAL Soft), now there are 2 more (GLFW and the optional jemalloc). How's that less Java than before?

What LWJGL 3 is now is a vast collection of bindings, most of which are irrelevant to most people. What this means is that maintenance effort is going to be simply non-existent on it, and once you (eventually) grow tired of it, and you will, it'll just stagnate and get bitrot and become a large legacy which will distract people from otherwise creating separate efforts to solve specific issues.

There is a very critical difference. Once Elias stopped working on LWJGL we were screwed, because there was no one with the experience to improve/fix the OS-specific functionality. There's no expertise required to maintain LWJGL 3. Someone has a problem with GLFW? Open an issue on their github and (if it's legit) elmindreda will fix it eventually. It's not our problem anymore.

I lost interest in maintaining LWJGL after a few years of developing on it, largely because it did everything I needed it to by that point, and also because I was seeing virtually no return on my efforts. I watched Markus accumulate two and a half billion dollars on the back of the literally months and months of effort I'd put in on the library he used to catapult himself into the realms of the unspeakably rich with barely so much as a thankyou, and that, for me, was the point at which I decided I couldn't be arsed with open source any more. I only have so much time left in the world and a lot of things I'd like to do, and making Markus richer wasn't on the list, so I diverted my efforts elsewhere. At some point, you too will find something more interesting and distracting, and you'll be leaving behind a huge, huge pile of stuff which no-one except you really cares too much about.

Oh, I do have something a lot more interesting to work on. Wink That's why I've put a huge effort into making LWJGL 3 easily maintanable.

On seeing a return on open-source efforts... I don't know, that's not what open-source is about I guess. I even removed the option to donate to LWJGL when I took over. Didn't feel right without having something to deliver. On the other hand, what we have been doing in LWJGL isn't just open-source... Writing JNI bindings is on its own level of masochism. It's the kind of open-source that no one wants to be doing. That usually has value. When my wife asks what I'm doing, I wish I had something better to say than "omg I'm writing Vulkan bindings, do you know how IMPORTANT this is?". Especially with the economy in Greece being what it is.

On Minecraft, I cannot claim any credit for what LWJGL was when Minecraft happened. Maybe Cas is right, I don't know. What I do know is that post-Minecraft success, its users had lots of trouble because of LWJGL and we didn't do much for them. We never had much of a contact with Marcus or their devs either, which I found strange given how critical LWJGL was for the game. Strange situation.

I strongly advise you to split LWJGL up into the bare minimum and then create separate, independent projects that build on top of or besides LWJGL for GUI libraries, structs, OpenCL, in-memory databases, vector math, etc.

Having everything in the same repo, in branches, or in different repos, is just a technicality. The only thing that matters is how the software is deployed. With #100 + a few other ideas we had recently, I believe everyone will be satisfied.
Online Spasi
« Reply #19 - Posted 2016-06-07 15:30:22 »

I think you're being a little defensive about my observations, Spasi! I'm quite aware of the 3.0.1 goals already.

I guessed so, I'm just trying to address your concerns in a way that will be understandable to everyone reading. I fully appreciate your input btw!

It's a pity to de-motivate the project lead like that.

Don't worry, there's no demotivation going on. Cas has strong opinions and gives honest advice. It's always helpful.
Offline ziozio
« Reply #20 - Posted 2016-06-07 18:57:40 »

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.
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #21 - Posted 2016-06-07 19:19:20 »

Cas Smiley
that read more like
Quote
Cas Cranky

- hwloc (incomplete branch)
i didn't know you bound hwloc to java. thanks alot!

With #100 + a few other ideas we had recently, I believe everyone will be satisfied.
i will be, this is great. it's pretty much what i am waiting for before leaving 2.9.4.

Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2016-06-07 19:54:27 »

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 Smiley

Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #23 - Posted 2016-06-07 23:19:59 »

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.

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Offline cylab

JGO Kernel


Medals: 188



« Reply #24 - Posted 2016-06-08 06:40:22 »

Quote from: spasi

Having everything in the same repo, in branches, or in different repos, is just a technicality. The only thing that matters is how the software is deployed. With #100 + a few other ideas we had recently, I believe everyone will be satisfied.

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

Mathias - I Know What [you] Did Last Summer!
Offline Opiop
« Reply #25 - Posted 2016-06-08 14:35:42 »

Hey look im the minimalist
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?
Online NegativeZero

JGO Kernel


Medals: 333
Exp: 1 month or less


Zero but not.


« Reply #26 - Posted 2016-06-09 01:15:31 »

Hey look im the minimalist
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?

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.

This sounds great.

Offline Hydroque

JGO Coder


Medals: 25
Exp: 5 years


I'm always inspiring a good time.


« Reply #27 - Posted 2016-06-09 02:38:57 »

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.

You think I haven't been monitoring the chat? http://pastebin.java-gaming.org/c47d35366491fHere is a compilation <3
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #28 - Posted 2016-06-09 09:05:12 »

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
Offline princec

« JGO Spiffy Duke »


Medals: 1059
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #29 - Posted 2016-06-09 09:31:14 »

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 Smiley

* 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.

Pages: [1] 2
  ignore  |  Print  
 
 

 
EgonOlsen (1869 views)
2018-06-10 19:43:48

EgonOlsen (1901 views)
2018-06-10 19:43:44

EgonOlsen (1258 views)
2018-06-10 19:43:20

DesertCoockie (1703 views)
2018-05-13 18:23:11

nelsongames (1379 views)
2018-04-24 18:15:36

nelsongames (2003 views)
2018-04-24 18:14:32

ivj94 (2753 views)
2018-03-24 14:47:39

ivj94 (1955 views)
2018-03-24 14:46:31

ivj94 (3045 views)
2018-03-24 14:43:53

Solater (1090 views)
2018-03-17 05:04:08
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!