Three requests

[aldacron]

It's nice that you guys decided to implement some convenience features, such as automatic initialization of the input devices, and all of the goodies in the Display.update function. But, I have a couple of requests to make the system more flexible. I'm working on a framework that would allow mixing and matching of various APIs (such as LWJGL for rendering, and AWT for input, and JOAL for audio, for example). There are a couple of things that require workarounds to get LWJGL to play nicely:

1) Apparently, it is apparently not possible to turn off the property 'org.lwjgl.opengl.Display.noinput' programmatically. I tried via System.setProperty, and the input devices are created every time. It would be nice to be able to set a flag prior to calling one of the Display.create functions that would turn off auto-creation of input devices. In the meantime, my workaround is to destroy them all myself when the window is created. Having the flag would be much cleaner (then I could remove all references to input devices from my graphics system).

If someone decided to use their own input lib (or something like JInput) with LWJGL, having the devices created automatically could cause problems.

2) It would be extremely nice to have a Display.update method that only  processes window events through the native call and did not bother with swappinog buffers or polling input devices. Perhaps it should be named Display.process(). Also, the swapBuffers method should be publicly exposed again. While no harm is done as is, it would be nice if we had a choice of controlling the call sequence ourselves rather than the API taking that away from us.

3)  There really, really ought to be a way to control the window position. At a bare minimum, an option to center the window at start up. It's extremely rare to need to move a window programmatically during the course of a game, but having the ability to center the window on screen would be a big plus.

Is there anyway this could be added to the library? If not I'm going to have to distribute a modified version with my famework, and I'm not too keen on that. I can live without number 2 I suppose, but 1 and 3 I see as essential.

[Matzon]

Well, I think I would like to start out with saying that LWJGL is for the masses. If you need to have some features that 99% of people won't be using - and worse, requires api changes - then your best bet is to modify LWJGL to suit your needs. It just doesn't make sense to use JOAL for audio when using LWJGL for example - you must have some very specific needs.

1:
Sounds odd that noinput flag doesn't work programatically - don't see any reason for that... anyone? perhaps system properties cannot be set ?

2:
Well, we could easily make such a method, I just fear that people will abuse it somehow - calling it AND .update() for lack of knowing better.

3:
setLocation was added in 0.93.

[aldacron]

Well, I think I would like to start out with saying that LWJGL is for the masses. If you need to have some features that 99% of people won't be using - and worse, requires api changes - then your best bet is to modify LWJGL to suit your needs. It just doesn't make sense to use JOAL for audio when using LWJGL for example - you must have some very specific needs.

No, I don't need to use JOAL with LWJGL. But if LWJGL really is for the masses, then it needs be flexible enough to support a variety of needs within its scope. Just because you wouldn't use JOAL with LWJGL doesn't mean someone else wouldn't if they have the opportunity. All of that stuff the Display.update does is very specific, and not general case at all. What I am asking for are not major API changes that would break anything, but API additions that would provide an extra option. And they make it much easier to provide a flexible framework where LWJGL and the Sun stuff can be swapped at run time system-by-system. I can go off with my own modified version but I'd really prefer to avoid it.

1:
Sounds odd that noinput flag doesn't work programatically - don't see any reason for that... anyone? perhaps system properties cannot be set ?

I was surprised as well. Regardless of what the problem is, this is something that shouldn't be a system property annyway. It should be decided at development time, not at run time with a command line argument. Customers don't care when, where or how the input devices are created.

2:
Well, we could easily make such a method, I just fear that people will abuse it somehow - calling it AND .update() for lack of knowing better.

That's what documentation is for

3:
setLocation was added in 0.93.

Oops. I missed that. Maybe I'm one of those guys who would abuse the  .update method

[aldacron]

Okay, setting the property via System.property works. Again, it's my fault. I need to take time to cool off before posting feature requests next time.

Request #2 still stands, though!

[elias]

I think the hook is small and reasonable enough to add, so I put it in CVS (processMessages()). We used to have a separate methods like this too.

- elias

[aldacron]

Thanks, elias. I recall the separate methods. I was away from LWJGL for a while and coming back recently I was a bit stumped at first by all of the changes. I just have one minor design issue to point out after looking at the source.

With your new DisplayImplementation class and the new method Display.getDisplayImplementation, there's no need for the processMessages method. Anyone who is taking that route will still need to call getDisplayImplementation to swap buffers. So we might as well just call DisplayImplementation.update and avoid the processMessages method altogether. I wonder if it might not be better to hide the getDisplayImplementation and reimplement a public method Display.swapBuffers, or just remove the processMessages method and make working through the DisplayImplemenation the way to go. Just food for though