Multiple GL Windows

[zparticle]

Okay so I've started to get into LWJGL and I have a question. Note: If this had been asked before please point me to the correct forum topic.

I don't understand why the decision was made to use only static methods in the Keyboard and Display classes. Doesn't this make it impossible to write a game that uses more than one window?

I mean first, how could I create two different windows in my program? Second, if I can do that how do know what key events are meant for which window?

Perhaps the assumption was that all LWJGL games would be full screen and therefore never need a second window.

[darcone]

Hmm.. I am yet to see a game with several windows with opengl contexts
I see LWJGL as a more proffessional approach to creating games. And good quality games often are organized inside its own window? Correct me if I am mistaken, although I am sure this is a choice of design.

[zparticle]

Well just because there isn't one yet doesn't mean there shouldn't/couldn't be. "Professional" does not imply single window, at least in my mind. I guess the question I was trying to ask is this:

Why intentionally limit the abilities of the library?

Also think about using the library to create utilities to help you create your games. These would very likely be better (read "easier to use") if given the ability to have multiple windows. For instance a object/terrain/world editor. Especially for folks like myself that use multiple monitors.

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

[princec]

We have intentionally limited the library to a single display context, single input context, and soon, single sound context.

Our library is designed to turn a machine into a games console; eg, a black screen with some input devices attached to it and some speakers. That's why windowed mode is a debug mode; it's not a mandatory feature in the JNI implementation. It just so happens to work on Win32, Linux, and Mac, but one day we might with any luck see our library running on a console. (That's my hope, anyway).

If you want more than one window, you've got some major headaches in input processing which just don't fit in with the way the whole library is designed to work. You've effectively said you want a game application which interacts with the other applications in the windowing system, allowing the mouse to traverse windows, rearrange them, paint bits of them, etc. What you want is GL4Java, which has the benefit of the entire AWT under it.

If you want more than one window, you're probably not making a game either

So write your own windowing system if you need multiple windows (it's not hard), and render it on your empty screen.

Cas

[zparticle]

Our library is designed to turn a machine into a games console; eg, a black screen with some input devices attached to it and some speakers.

I see, I hadn't looked at it from the perspective.

That's why windowed mode is a debug mode; it's not a mandatory feature in the JNI implementation.

What exactly does this mean? The methods take a boolean for wheater or not to use fullscreen. Does this mean the code sets some debug flag when in windowed mode? If so what effect does the have?

If you want more than one window, you've got some major headaches in input processing which just don't fit in with the way the whole library is designed to work.

That was part of the point I was trying to make.  Just seemed weird to me to design things that way and I wanted to understand why, thus the reason I asked the question.

If you want more than one window, you're probably not making a game either  

It so funny that people have this histeria about having more than a single window in a game.

[Herkules]

If you want more than one window, you're probably not making a game either

As soon as a game gets more technical, this doesn't hold. I don't think there is any serious gaming engine out there that is limited to a single window or even fullscreen mode. Most rely on a hWnd to render into.

MS Flight has fully dockable windows within. So you can place the panel or the COM devices or the GPS or the compass on you second screen.

Many games offer an editor as well, mostly relying on a common windowing system.

[princec]

Because LWJGL is theoretically designed from the perspective of a console, there is no windowing system to rely on - the lowest common denominator is a screen.

If you want windows - draw them yourself! Works for me. Then you'll have a completely portable windowing system that works on Win32, MacOS X, Linux, and even the PS3 (If it gets GL and Java ever ) which all behave and look identical, which I believe to be very important in the immersive game experience.

Cas

[zparticle]

I think you're missing the point, but I'll leave it alone because I'm not up for an argument today. Cheers.

[darcone]

perhaps I didnt get your point either but I think it´s a good idea. Princec has a point and it would be ownage if lwjgl game would run exactly the same on all platforms

[Morin]

Wouldn't it be possible to run swing inside the OpenGL window? AFAIK the swing components are designed to render themselves to an awt.Graphics object, whatever that does internally. It should be possible to write such an object that actually maps everything to OpenGL. Sounds nice to me because suddenly you get everything in your GUI that swing has, including user-made extensions from the 'net.

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

[Backmask]

Hi

Isn't it possible to create a custom classloader that you can use to create multiple lwjgl gl, keyboard, sound instances that in the JWM will be seperate objects in different memory locations. Or? Just an idea...

[princec]

Morin - actually, that is sorta possible, but of course a waste of time, because Swing is Shit. There, I've said it. No going back now

Backmask - that part of the problem is simple. The problem is - who owns the mouse? How do your multiple windows interact - using Threads? What if you're trying to run LWJGL code on something which doesn't have a windowing system in the first place? Think out of the box on it: it's a cross-platform console gaming library.

I keep saying this, but if you want AWT features and OpenGL you need to use GL4Java. If you want to write games - the usual kind of game, that is, that doesn't require windows - well, I'd stick with LWJGL.

Cas

[Herkules]

Is there anything against a JFrame besides the LWJGL window? For editors I mean...

[zparticle]

Hi

Isn't it possible to create a custom classloader that you can use to create multiple lwjgl gl, keyboard, sound instances that in the JWM will be seperate objects in different memory locations. Or? Just an idea...

Interesting idea however it won't work because of the assumption that was made that only a single window be involved. The Keyboard and controller classes would poll for the state, in each window, and possibly loose events or eat events that don't belong to them.

After looking closer at the source, it should be a trivial matter to make the library support multiple windows. Let's be clear about this, I'm not talking about drawing a window for a user interface. I'm talking about having more than one physical OS window.

There is no reason this would stop someone from only using a single window. But it would allow people that need/want multiple windows to have them. The main changes I see needed to do this are the following:

1> If a window isn't active the keyboard polling routines return that no keys are pressed
2> If a window isn't active the controller polling routines return that no buttons/directions are pressed
3> The mouse shouldn't be disabled when you are outside of a window. (that should never be the case regardless of whether multiple windows are supported)
4> The Keyboard and Display classes have to become instance based so you can use different instances in each window.

Probably a number of other things that I don't know about yet. I realize this isn't going to happen but I think it is at least worth discussion.

[princec]

We don't have events in LWJGL. We don't have multiple threads either, as we all know that mixing threads up with hardware rendering is a world of slowness and complexity. Both of these things will make it impossible to coexist with a windowing system nicely without writing a load of glue code, and before you know it - oh look, we've got the AWT and GL4Java.

Herk - theoretically no, there's nothing stopping you from just using AWT and Swing for your other windows except that we have a nasty habit of capturing and hiding the mouse pointer when the LWJGL window has focus. You'd need to do some tweaking to the native side and maybe add a bit of API to hide & show a mouse cursor.

Of course, if you do use AWT and Swing it means that you're outside the realms of "consoles" again. I know it's hypothetical right now, but the idea is that we have a "platform" specified by the API, much like MIDP but for high-powered devices. The platform is basically "Java2 minus java.awt.*".

Cas

[zparticle]

We don't have events in LWJGL.)

I understand that, I used the term to mean things like the key presses in the Keyboard buffer.  You wouldn't loose them if you attached a Keyboard object to a specific window and only allowed it read when the window was active.

I guess I need to dig deeper into the source because I don't see where this "load of glue" code is needed.

[Orangy Tang]

This topic seems to come up with disturbing regularity Currently theres been at least 3 (including myself) custom GUI toolkits that people have produced for use with LWJGL, perhaps this calls for some sort of community-based open source project?

The main problem i see is the conflicting uses people want it for - either something unique looking for a game gui or something quick-yet-functional for an editor..

[zparticle]

Your probably right but this isn't about a custom GUI toolkit.

[vrm]

for info I made a 4th one
http://vrm.free.fr/sc-star.png

I don't disagree about looking to merge/redo code for make a BSD licensied toolkit