We are considering splitting the LWJGL deployment up into separate .dlls and .jars for core, input, opengl, openal, and vector.

Our reasoning is that it's entirely probable you won't be using all of the features - particularly the vector code. Or if you're just doing tiny graphics demos you might not want to ship the OpenAL stuff. Etc. Perhaps all you want is a hires timer?

Hi, I think it's a good idea to split it up. I consider it similar to the apache's large repository of projects/libraries, it would be painful if I had to download all of apache.org's software just to get at something simple. Unfortunately, the name 'Lightweight Java Gaming Library' implies a sort of monolithic chunk of code that you use to build games with. I'm not sure exactly how to address this, but the concept of 'packages' comes to mind. You could still keep the 'Library' name (in the sense that a real library has many books in it) but break out the components of the library into packages, such as OGL APIs, timing, sound, Graphics, Vectors, Pathing, etc. It could be that there are dependencies between these packages, but I don't think that should mean you need to bundle it all together. (for example, the FOP project form apache requires many other packages from other apache projects for it to operate (xalan, xerces, batik, ant (compile only), some SVG stuff, etc). It's the responsibility of the developer to know what package dependencies exsist if you are going to use a certain package. This also means that improvements can be made to very localized sections of an entire library....in addition to being ablet o pick and choose the sections of the library you needed (Could you imagine if you only wanted information in volume X of an encyclopedia but they said you need to chck out the entire encyclopedia if you want it! would suck...)

Right now the library is organised in a way that makes it highly amenable to being split, and also provide the full distribution as well because it's just not that complex.

There's a "core" LWJGL, which contains a few basic utilities required by most users of the library, such as pointer fiddling and hires timers. Currently the vector maths is in there too (but not the vector packages).

As dependents of the core LWJGL package we've got input, OpenGL, and OpenAL, which are easy to split out of the Java distribution although it's slightly fiddlier removing the C++ parts because you need a C++ compiler to hand.

I think I'm right in saying that we never intend to add more to the LWJGL than the bare minimum required to write a high-performance Java game in Java without having to code your own C++ to do something for you, so it is unlikely to ever grow significantly larger than it already is. A lightweight monolith...

Since someone trying to play my 48-hour game has it crash out straight away with "The procedure enty point alcGetEnumValue could not be located in the dynamic link library OpenAL32.dll", despite me no having any sounds at all I'd say a split would be preferable if only to avoid such situations.

Personally I would have preferred that most of this stuff was just set up using SPIs (service provider interfaces) so I could replace the OpenAL stuff with easier to use and more capable platform specific sound engine (for OSX).

well, then it wouldn't have been Lightweight Anyhows - the library is specifically tied to OpenGL and OpenAL - what would the point be of a SPI?

If one was to do what you're talking about, then we would be talking about a completely other game library, one which didn't expose how it played sound or draws graphics. This just isn't what we wanted to do. We wanted to create a library that is a fast as possible to use, from within java - we acknowledge that some might be turned of by having to use OpenGL or OpenAL (and any of the other packages), but we did this to allow for people to do it as fast as possible. That said, we do expect people to build a library on top of lwjgl for easier usage. (see: http://sourceforge.net/projects/spgl)

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