And what next ?

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

++
Chman

  • 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 :slight_smile:

what is keyboard translation ?

  • 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

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

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.

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 :slight_smile:

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…

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

  • elias

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.

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…

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 ;D)
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 ;D). 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 :stuck_out_tongue:
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

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

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 :slight_smile:

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

[quote]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
[/quote]
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.

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?

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.

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…

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 :slight_smile: )

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 :frowning:

Cas :slight_smile: