And what next ?

[Chman]

What will bring the future version of LWJGL ? because version 0.4 seems very complete...

++
Chman

[princec]

- keyboard translation (should make it into 1.0)
- donate the screen mode selection code from SPGL as it seems to be universally useful
- considering fast 2D surface & blit API for systems without OpenGL support
- considering ogg vorbis decompressor
- considering CD player controller
- any other suggestions which meet general approval

Cas

[Chman]

what is keyboard translation ?

Games published by our own members! Check 'em out!

[gregorypierce]

- Moving issue and bug tracking to JIRA (underway)
- Gathering screenshots and tech demos
- Addition of utility code to make it easier to make games, since its not *just* a binding

[Chman]

no, i think lwjgl sould only be a binding... else it will become a big library and it won't be interesting to use it only for opengl... look at the SPGL if you want a game library...

screenshots support is a very good idear...

for tech demos, look at my website... http://chman-area.tuxfamily.org (if you have some demos, please send me a link and a short description)

++
Chman

[gregorypierce]

Its a lightweight game library (according to its name) so it should actually provide some assistance for actually building games... but this is something that has been debated in the development group for some time now. Adding functionality for texturing, easily loading a shader, etc. will in no way make the API large (because all of this is *utility* code which is optional and you don't need to carry it around).  The point is to give people stuff so that they can get up and running quickly in order to increase the adoptance of lwjgl.

We aren't talking about adding in a scene graph, for example.

[princec]

It's still a separate layer though. No harm in that; people always like to find their own way of doing things, especially programmers. I don't think everyone would be too pleased if I forced SPGL down everyone's throat.

Cas

[Jacko]

How about formalising some idea of LWJGL plugins?

These could be additional "bits"  that you can download from the sourceforge site for specific purposes, or if you want to, you could still roll your own.

Just an idea off the top of my head...

[elias]

chman: http://www.JavaGaming.org/cgi-bin/JGOForums/YaBB.cgi?board=volunteer;action=display;num=1041779009

- elias

[gregorypierce]

No harm in that; people always like to find their own way of doing things, especially programmers. I don't think everyone would be too pleased if I forced SPGL down everyone's throat.

I certainly don't disagree with that.  The big thing that I'm running across are things like:

a) looks interesting, but I can't fingure out how to texture map through NativeByteBuffers

b) how do I create a shader and render with it

c)  how to I render a vertex array

d) how do I set up multiple rendering passes


Everyone who might be interested in using lwjgl is all that interested in the actual implementation details as much of it is much lower level than some Java developers care to get - especially since they really don't care how it works... just that it works, and that they have the ability to override the default implementation later if they so choose.

LWJGL certainly gives people the flexibility to do whatever they want - but a newcomer adopting lwjgl is really left with a lot of questions and frustrations. I personally don't have any issues, but it would be ashamed to see good technology go to waste because the people most likely to adopt it don't because Java3D is just easier to get working with.

Games published by our own members! Check 'em out!

[Matzon]

but lwjgl should still be an enabling technology - not nescecarily an easy to use library...
All the "fancy" stuff should be in a optional jar, and not in the lwjgl.jar - as already discussed on irc.
But it is a very thin line - on one hand we want it to be lightweight and other hand we want it to actually be usefull...

[erikd]

For what it's worth, I like lwjgl to stay small and yes I think it should be nothing more than enabling technology.
Sort of like becoming for java what directx is for windows (at least I *think* so, not knowing all that much about dx  )
As for adopting the technology, I think it's being adopted not that bad at all, looking at what Egon Olsen is doing with it with his jPCT for example (which I think is pretty cool).
But, I think many people hesitate to start using it because they think something like 'it's low level, it's got pointers, it's directly binding to ogl, it's for professionals ooh... difficult!' (or maybe that was just me  ). But when you actually start looking and playing with the examples, then it turns out to be not that hard at all.
I found understanding j3d for doing basic stuff a lot harder than lwjgl even though I'm only scratching the surface yet.
Maybe it could do with a little more documentation or at least a readme with something useful like 'how to start an example' (I didn't know the dll had to be in the root for example). Also, the current documentation stretches the point a little too much that it is 'aimed at professional games developers' for my taste which adds to the perception that it is too hard for 'hardly professional game developers' like myself  
I believe people can judge for themselves if they're up to using it or not by just reading what it is and what it isn't.

Well that's my 2 cts.

Greetings,
Erik

[elias]

Well, isn't all that documented after all. But yes, we could sure use some basic setup instructions. OpenGL docs are out there in the thousands, so we really only have to document the obscure parts of lwjgl thoroughly.


- elias

[princec]

Maybe I might explain a couple of the most common things like "how do I load a texture?" and stuff which I've done do death for a couple of years now.

Cas

[cknoll]

A CD controller in a gaming library?  I think you're beginning to take a step down the dark path...

Why not call the featureset of the LWJGL complete and make a LWJMU (light weight java multimedia utilities) that has those sort of things in it.


-Chris

[Captain-Goatse]

A CD controller in a gaming library?  I think you're beginning to take a step down the dark path...

Why not call the featureset of the LWJGL complete and make a LWJMU (light weight java multimedia utilities) that has those sort of things in it.


-Chris

Exactly. I think LWGL would loose its purpose if it'd have all these things. CD controller is not exactly game related, where as sound system would be. However, why not make these things as plugins? MP3 plugin would be great as well as some way to play AVIs, but cd cntroller?

I like the way LWGL is kept abstract, usually the point where i stop using certain apis is when they take control and become part of the programming. APIs are supposed give me the ability to take advatange of things I wouldn't otherwise be able to use.

I agree with lw multimedia package. If you begin to do this, at least leave a stripped down version of LWGL without these "great" abilities.

[cfmdobbie]

I was under the impression that all these things effectively *would* be plugins...?  

Considering late-loading of DLLs, proper separation of functionality into different packages etc, is there any reason why you can't just not distribute the "CD player" DLL and jar?

[Matzon]

as much as humanely possible, all dll's will be loaded dynamically. That said, some features will have to be in the lwjgl.dll, which is the core - however, any features - and this is where the community comes in - will be made part of the core or made optional depending on what *you* say.

The two main reasons for determaning whether a class is part of the core, or optional are size and relavancy - both of which should be discussed when any feature is implemented.

[Matzon]

Considering late-loading of DLLs, proper separation of functionality into different packages etc, is there any reason why you can't just not distribute the "CD player" DLL and jar?

Yes. We load OpenGL and OpenAL dynamically since they're rather large, and you might want to run lwjgl without oal or ogl. However at the moment ALL native code is deployed in one dll - we have discussed (and turned down) the option of having a package containing
lwjgl_core.dll
lwjgl_gl.dll
lwjgl_al.dll
lwjgl_vector.dll
lwjgl_input.dll
we could then add a _cd and a _vorbis - which would make it all more dynamic - at the price of clutter...

We might in the future split the dll, but I don't think this will happen for 1.0 - but then again - if this is what people wan, we will most likely do this...

[princec]

Whilst the .dll and .jar combined come in at under 300Kb I don't think there's any reason to split anything up as it's just not worth the bother. But because we're open source there's nothing stopping you from splitting it up yourself.

RE: a cd player being beyond the remit of game functionality - there are many games which have relied on CD music tracks for one reason or another, and currently this is not possible for Java, so we can enable this. It's probably going to cost about, ooh, 8Kb on the library. Big deal.

RE: plugins, I think we'll be making all external dependencies dynamically loaded from now on as it seems to be really easy if a little more onerous to code. (Heh - thanks elias )

RE: ogg, it'll be very small, and very very useful to a lot of developers. It isn't, however, necessary to put it in LWJGL because it is entirely possible in pure Java or as a 3rd party lib - all you need is to be able to stuff bytes in a buffer and stream it out using OpenAL. So probably not.

RE: 2D, more and more I think this is going to be essential for those older systems without 3D cards. We have something in Java1.4 now called VolatileImage but of course it relies on the huge AWT infrastructure and licensing so really, we've got to do it or there'll be no graphics on my old laptop

Cas

[princec]

Oh, and we need someone clever with #asm, MMX, SSE, and Altivec to write proper optimised code for the vector processing part, because currently it's just straight C.

Cas

[gregorypierce]

Sort of like becoming for java what directx is for windows (at least I *think* so, not knowing all that much about dx  )

Yeah, bad comparrison because with DX there is a metric assload of utility code for everything from loading shaders to loading models in the DirectX distribution.

But I've already said my peace on the matter. I'll add anything else I need to add outside the framework of LWJGL.

In order for any API to be adopted it must be heavily documented and provide enough sample code and utilities such that a person can get up to speed fast enough to put together a demo to see what the strengths and limitions are. As long as that path remains difficult for all but people close to the project or those familiar with NativeBuffers and able to read through and understand the sample code, just don't expect it to be more than just another Java OpenGL binding (because really I don't know a single person clamoring for a binding to OpenAL as sound, nor input were never really a problem).

I think that not providing these ease of use benefits is a critical mistake. But, of course, I want it to be more than just another API.

[Matzon]

just don't expect it to be more than just another Java OpenGL binding (because really I don't know a single person clamoring for a binding to OpenAL as sound, nor input were never really a problem).

That depends on what is available in the optinal package.

Regarding OAL - have you actually tried using Java sound for a game? - I find it rather unusefull. The latency is just waaay to high.  Though the mix n bytes approach might work better in JavaSound...

[erikd]

RE: 2D, more and more I think this is going to be essential for those older systems without 3D cards.

Yes I totally agree. OGL on my old laptop is dead slow.

Yeah, bad comparrison because with DX there is a metric assload of utility code for everything from loading shaders to loading models in the DirectX distribution.

Ok, I take it back .
I'd hate lwjgl to become as big as dx anyway, but it would be nice if it would get the same 'status' as a standard for building games on.

As for CD support, I think that's typically the kind of thing LWJGL would need to include and NOT become a plugin. Unlike ogg or mp3.

Erik

[gregorypierce]

That depends on what is available in the optinal package.

Regarding OAL - have you actually tried using Java sound for a game? - I find it rather unusefull. The latency is just waaay to high.  Though the mix n bytes approach might work better in JavaSound...

Yes, I just used the SPI interface to add in what I needed.

[princec]

I've got to put me foot down about LWJGL:

All it is is an enabling technology for Java games programmers, the very minimum required to allow you to do the things you can't otherwise do without help from Sun (eg. AWT, JavaSound, Java3D). Any more than that belongs in another library on top of it - and that's exactly what we'd like to see happen - the "HWJGL", with all the extra cream and sugar in it.

Cas

[markuskidd]

I think simply by virtue of the word "library" you are implying that there is going to be code that lies in that wide, gray expanse between the category of game engine and that of driver-wrapper. One test you developers might also perform mentally is to ponder whether wrappers for OpenGL, OpenAL, et al. and some Vector-related code actually constitute a game library by any other criteria than that it brings together some assets which *can* be used for game making. I realize I'm coming at this in a roundabout way, but it seems like if it is to be called the Lightweight Java Game Library, it should be in a form which is immediately usable in coding a game. I assert that, if it appears that the LWGJL is unusable in it's current form in 90% or more situations (ie it requires middle layer of tools or interfaces) then it is perhaps best called something more indicative, the Java I/O and Graphics Library or something in that vein.

Either route will produce something useful, but these are just my thoughts. I'm sure you guys who are actually working on this will come up with a workable solution.

[Matzon]

I realize I'm coming at this in a roundabout way, but it seems like if it is to be called the Lightweight Java Game Library, it should be in a form which is immediately usable in coding a game.

Yeah, but then again lightweight is also a part of the name, which implies that some of the more advanced stuff is left out - or at least not in the core distribution.

I assert that, if it appears that the LWGJL is unusable in it's current form in 90% or more situations (ie it requires middle layer of tools or interfaces) then it is perhaps best called something more indicative, the Java I/O and Graphics Library or something in that vein.

Agree 100%. Which is why we have examples and we have some basic utility classes (WaveData for instance). We need to seperate between must/should/could/won't have (MoSCoW).
lwjgl is first and foremost an enabling technology, that is we provide the interface for some of the stuff that just isn't possible from the Java framework. Secondly we are a game library and as such whatever features we implement must be relevant for games - not general applications. Thridly - the above statements doesn't exclude utility classes, that make life easier - but they should be placed in any optional package, so that _everybody_ doesn't get a copy, even though they don't need it. And this is exactly the problem with the lwjgl.dll - it contains _all_ native code - this means (at the current point in time) that all features we implement that need native access _will_ be distributed to all developers, regardless if they need it or not. We therefore need to evaluate any feature that requires native code, while any Javacode may be added whenever someone adds a nice general utility class.
Lwjgl will never become a fullfledged game library - this we leave to others (ie. spgl).

[gregorypierce]

I realize I'm coming at this in a roundabout way, but it seems like if it is to be called the Lightweight Java Game Library, it should be in a form which is immediately usable in coding a game.  

Ding. We have another winner

Secondly we are a game library and as such whatever features we implement must be relevant for games - not general applications.

This is where the trouble starts. What specifically does LWJGL do that helps one develop a game. By calling it a game library, the suggestion is made that there is functionality in it to allow the easier development of games. Otherwise its just a binding (not that that's a bad thing) or a Java Native Media Acceleration Framework. During the marketting of LWJGL these are the types of emails I've gotten from the several folks who chose to ask about functionality of the API.

Personally I don't see the distinction between adding in code to control a media player and adding in code to load a texture, but that's just me. I've already written all the utility code I needed for both purposes. I mean after all there are things like alerts and the like in the native binding - something I found puzzling but implemented anyways.

Thridly - the above statements doesn't exclude utility classes, that make life easier - but they should be placed in any optional package, so that _everybody_ doesn't get a copy, even though they don't need it.

Very fine undefined line between what's needed and what makes life easier. But I mean that's all cool. People are just writing their own stuff on top of the native library binding and they don't expect it to provide game related functionality anymore. I mean seriously, if a 2D game library didn't even define a sprite (part of J2MEs original problem), there are going to be issues and lots of people wasting time and energy trying to create their own sprite classes - which is what happened with J2ME.

[Matzon]

This is where the trouble starts. What specifically does LWJGL do that helps one develop a game. By calling it a game library, the suggestion is made that there is functionality in it to allow the easier development of games. Otherwise its just a binding (not that that's a bad thing) or a Java Native Media Acceleration Framework. During the marketting of LWJGL these are the types of emails I've gotten from the several folks who chose to ask about functionality of the API.

So what you're saying is that spgl and lwjgl should be merged?