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 
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.
[quote]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).
[/quote]
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…
[quote]RE: 2D, more and more I think this is going to be essential for those older systems without 3D cards.
[/quote]
Yes I totally agree. OGL on my old laptop is dead slow.
[quote]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.
[/quote]
Ok, I take it back ;D.
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
Yes, I just used the SPI interface to add in what I needed.
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
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.
[quote]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.
[/quote]
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.
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).
Ding. We have another winner
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.
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.
So what you’re saying is that spgl and lwjgl should be merged?
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
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.
[quote]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.
[/quote]
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 :D.
[quote]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).
[/quote]
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
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 ?
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
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.
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).
[quote]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).
[/quote]
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.