And what next ?

[princec]

Look, if anyone put SPGL or anything remotely like it in LWJGL I'd just forget it all and start over. I want the minimum required in the LWJGL to write games. Absolute minimum. The way I do a sprite library is pretty different I imagine than the way anyone else would do a sprite library. Only today I discovered what relying on just a tiny piece of someone else's idea of how to do things costs me (see diary for pathetic sorting performance). Read how Michael Abrash discovered something interesting about memcpy().

It's still a "G"ame library because we don't have any pretensions to integration with AWT and the native methods we've got are methods you need in games and that can't be done in Java (or can't be done in Java unless you have AWT).

If it can be done in Java it belongs in someone else's library.

If this means creating a subproject in LWJGL and calling it org.lwjgl.util.* then that's fine, but if it involves more native code, it's no longer the LWJGL.

Cas

[gregorypierce]

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

No, I'm saying that the naming of lwjgl probably will continue to cause some issue to those who see the words "game" and "library" and assume that its something they can use to create games in Java, when in reality its not a game library.

I'm also saying that one should monitor the requests for support that are coming in and address them within the framework of lwjgl. If people keep coming in and trying to figure out how to put text on the screen or load textures and no solution is provided - the library will not be used, plain and simple. Its not a gaming library just because it isn't tightly coupled to the AWT.

Bah, I've spent too much time belaboring this point The line should be clearly defined between what is considered lightweight enough to go into lwjgl and what isn't. But again, I've got my own solutions now so I'm really just trying to make sure the technology itself doesn't end up being neglected for the wrong reasons. People should not use it if it doesn't work for them, not because they can't figure out how to define a light in a bytebuffer.

[markuskidd]

Look, if anyone put SPGL or anything remotely like it in LWJGL I'd just forget it all and start over. I want the minimum required in the LWJGL to write games. Absolute minimum.

The absolute minimum required to do games is not a lightweight games library, plain and simple; therefore you should really rethink your project's name .

It's still a "G"ame library because we don't have any pretensions to integration with AWT and the native methods we've got are methods you need in games and that can't be done in Java (or can't be done in Java unless you have AWT).

That doesn't make it a game library, since there's nothing specifically game-centric about it. AWT in and of itself has nothing to do with gaming specifically, and therefore your lack of pretensions relating to the AWT brings nothing to the table for your argument. Wisely, Sun chose a fitting name; the Abstract Windowing Toolkit, which describes the package's function. In the case of the LWJGL's current functionality, something like "The Lightweight Java Media and Graphics Toolkit" would be approprite. As far as I see it, the success or failure of this library to achieve far-reaching success for Java game development will be whether or not developers can be convinced it is the right tool for the job. If the name of the library is in any way misleading, it's going to be one more obstacle in the path of its acceptance.

edit: this is probably the last I'm going to contribute to the conversation, since I think I've made whatever point I'm trying to make I'll let the more qualified ones take over

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

[Matzon]

If this means creating a subproject in LWJGL and calling it org.lwjgl.util.* then that's fine, but if it involves more native code, it's no longer the LWJGL.

Yeah, this is where I am headed too.
So we'll add a bit supportcode to lwjgl, however we will distribute this code in the lwjgl_optional.jar - thus we still have a core library and a support library for making it easier to use lwjgl.
We have audio loading done, so we need classes for textures and fonts, right?

Regarding native code - controlling a cdplayer can hardly be a core requirement? - anymore than say moving the window around the screen (which we currently can't do)?

So if we choose to implement it, should some of the native code be implemented in a lwjgl_optional.dll instead of everything in the lwjgl.dll ?

[princec]

I want anything requiring native code in the core library; and anything not requiring native code to be in the optional library, by and large. I think the CD player therefore is a core requirement. It's tiny anyway.

The Vector classes might end up in the optional library actually. They shouldn't really be in there at the moment. I can see people wanting to use javax.vecmath instead for example.

Cas

[Orangy Tang]

I'd lean towards the idea of putting any 'pure java' util classes in an optional _lib jar, and then if it becomes apparent that they're hevily used moving them into the core. Likewise, anyone using just a few _lib classes can always produce a custom trimmed down version of the optional classes but still keep the core.

If the Cd player is as minimal as Cas mentioned, then it should be in the core - after all, its not something done via pure java. Some sort of optional .dll's could be a sticking point though. I'd suggest a _lib dll, and then playing it by ear on how much gets used etc.

[Themroc]

Ah, is there a way to set the title of the window in windowed mode? That would be my request for 0.5 ;-)
Anyone else has problems with window mode? Whenever my window gets obscured partly by another window and then comes back to front it is all white and nothing more will be redrawn (WinXP, J1.4.1_01).

And a lwgl.jar ready as a standard extension for easy deployment with applets on windows and linux. It's not that hard, add a manifest, add a little class to unpack the *dll or *so and sign it (with a fake certifikate if needed).

[EgonOlsen]

Ah, is there a way to set the title of the window in windowed mode? That would be my request for 0.5 ;-)
Anyone else has problems with window mode? Whenever my window gets obscured partly by another window and then comes back to front it is all white and nothing more will be redrawn (WinXP, J1.4.1_01).

I have the same problem under WinXP. Under Win2K, the window works quite well and under Win98, it's only visible if no other window gets the focus. The windowed mode definitly needs some work.