I must be going mad - I just can't find a way of creating an arbitrarily-sized window in the recent unofficial releases! I understand DisplayModes, and creation of displays with or without a fullscreen flag, but of course I can't create a DisplayMode object myself, and it looks like that's the only way context dimensions get into the system these days.
So, what am I missing?
The answer is... I'm not missing anything at all! Chat log follows (edited):
Quote
cfmdobbie Hi Elias, got a quick question:
cfmdobbie How do I create an arbitrarily-sized context?
cfmdobbie Windowed, I mean
elias_naur erh
elias_naur you can't,anymore
cfmdobbie Ah
cfmdobbie That's... a little annoying
elias_naur could be, depends on your usage
elias_naur we don't support resizing anyway...
cfmdobbie Don't care about resizing, I'm just after a window that isn't 4:3
cfmdobbie Specifically, 464x384 pixels.
elias_naur what for?
cfmdobbie For a simple little game, bit of a diversion really.
cfmdobbie It'd be intrusive to go fullscreen, so I want windowed,
cfmdobbie But I don't want to have a 4:3 window
elias_naur but why the exact odd window size?
cfmdobbie Lots of games have specific non-4:3 window sizes
cfmdobbie Think solitaire, winmine etc
elias_naur myes
cfmdobbie I was rather hoping I'd missed something - didn't want to have to change to JOGL just for context creation
cfmdobbie :-/
elias_naur what about the SWT bindings?
elias_naur they should be reasonable usable with LWJGL last time I heard
cfmdobbie I don't seem to have them in any of the releases I have here...
elias_naur no, they're still "unofficial"
elias_naur but people seem to have success building and using them
cfmdobbie Ugh
cfmdobbie I'm not too keen on having to bother with the whole 150+MB compiler download
cfmdobbie Righto, thanks anyway!
elias_naur ok
elias_naur I can see you're not happy with the things as they are now :-)
cfmdobbie Well, it was rather handy before, nice and convenient.
elias_naur but LWJGL windowed mode is not really meant to be anything than "fullscreen that cooperate with other desktop stuff"
elias_naur SWT and other "real" toolkits are meant to provide real windows, with controls, resizing and all that
elias_naur maybe you could post a request on the boards,and we'll come up with a nice compromise
cfmdobbie Well, yeah. But on the other hand, LWJGL 0.9 does what I want, as of 1.0 it won't.
cfmdobbie That a bit of a shame.
elias_naur maybe we should just make the DisplayMode constructor public
elias_naur after all, the setDisplayMode could fail
elias_naur that's what I meant about a compromise
elias_naur restore your wanted functionality in a way compatible with the new Display :-)
cfmdobbie Well, not really.
cfmdobbie I'm not playing with "display modes" at all - the syntax would be all b0rked
elias_naur yes, but then the name should be changed
elias_naur the DisplayMode is used for the windowed mode too
cfmdobbie Maybe DisplayMode -> ContextSpecification, include PixelFormat and fullscreen flag? That would make more sense, at least.
cfmdobbie Yeah, I think using DisplayModes for windowed mode is b0rked as well
cfmdobbie :-P
cfmdobbie You can create a windowed context, but only if your hardware is capable of making a fullscreen window of the same size? Meh.
elias_naur so I don't think PixelFormat and fullscreen flag should be included in the DisplayMode
elias_naur because DisplayMode is enumerated
cfmdobbie Okay. Hmm.
elias_naur anyway, we should continue this on the boards
elias_naur toget some input on it all ;)
cfmdobbie Righto, I'll tag it onto the end of my question.
The current syntax for creating windowed contexts is confused. You need to play with DisplayModes, which should be irrelevant outside of fullscreen applications. I'm not even sure, from looking at Display.java, how to create a window that doesn't fill the whole screen anyway!
My opinion:
A simple windowed mode is quick and convenient. Using JOGL or SWT to create a context is possible, but it seems like overkill when LWJGL is able to do it. I'm not after any advanced functionality, just what I could already do in LWJGL 0.9. I suggest a rethink of the way contexts are created.
I should not be passing in colour depths more than once for the same job. What happens if I request 32-bit colour in a 16-bit display mode? Why am I even given the option of specifying a window with a colour depth different from the current desktop colour depth? Those two situations are nonsensical, and the API should not allow them to occur.
The way that Display currently works seems to me to be a bad idea - and this opinion can be justified solely on the complexity of the code that makes it all happen. Reading Display.java is hard work, and I don't imagine that maintenance of it is any easier.
I believe Display should contain two different forms of context creation function, e.g. createFullscreenContext() and createWindowedContext(). I should not be passing in a fullscreen flag - the difference between fullscreen and windowed modes is much more complex than a boolean can express!
I think DisplayModes need to be hidden deep within the API - There's no real reason to allow arbitrary video mode switches. If the developer wants to pick a display mode from a list, fine. If they want to attempt to use one for their fullscreen context, fine. Those are functional uses for display modes. setDisplayMode is not - it's a low-level function that the developer shouldn't be concerned with.
First things first, what do you all think of the above?
setDisplayMode does not switch mode in itself. It sets the mode you want to use for the context. If the Display is not created, the given mode is simply stored for later use. If the Display is created, the mode is switched to the desired mode and the context is resized. Same goes for setFullscreen().
You're not required to pass in the color depth twice, either. It is documented that the bpp part of PixelFormat is ignored in Display.create().
- elias
Yes, if windowed mode is to be availabel thourgh lwjgl it should be possible to set whatever size one wants. The windows doesn't have to be resizeabe though IMO, but you should be able to choose to have a window that tetris clones will fit into perfectly without desktop space wastage...
I've never understood the reluctance to fully support windowed mode, anyway. Gamers are accustomed to games which allow them to toggle between fullscreen/windowed mode. On Windows it's not difficult to implement, and I imagine it would only be easier on Linux and Mac since, as I understand it, the OpenGL context doesn't get trashed when switching. This idea that Windowed mode is only for development has really been the only thing I dislike about LWGL.
And the idea that we should have to go through SWT for a Windowed mode game is absurd since it can be built right into LWJGL with full input support and without the extra requirement of shipping the SWT libraries. I just don't get it.
The reason for not supporting full windowed mode, is because of the complexities!
resize, focus, stay-on-top, minimize, restore, move etc etc.
It's hell to deal with, and quite hard to make it behave *exactly* similar on each platform. Therefor we try to keep it at a minimum. That minimum however, have been a bit fuzzy at times - since there are different opinions as to what that minimum is. That, and someone actually has to implement whatever we agree to...
Quote from: "Matzon"
resize, focus, stay-on-top, minimize, restore, move etc etc.
It's hell to deal with, and quite hard to make it behave *exactly* similar on each platform. Therefor we try to keep it at a minimum. That minimum however, have been a bit fuzzy at times - since there are different opinions as to what that minimum is. That, and someone actually has to implement whatever we agree to...
All of those events are easily handled through the window system's event manager, yes? There are two things that need to be done dependeing upon the specific event:
1) let the app know that the scene needs to be resized on resize/move events, and
2) activate/deactivate the app on other events.
Both cases can be handled with a listener interface that must be registered during initialization. This is basic stuff that I started doing on Windows in the DDraw days. I'm just not seeing the difficulty here, as long as you are only reacting to Window events and not providing a way to create them programmatically.
What's more difficult, as I see it, is dealing with toggling between fullscreen/windowed mode on Windows, since the gl context gets smashed (aauming the Window is destroyed and recreated) and all active textures/states need to be reloaded/reset. This, however, is an app-specific problem which again can be handled via the same listener. LWJGL can provide a isResetRequired method which returns true on all platforms where the context is smashed on a fullscreen toggle. And the toggling itself need not be implemented in the API, but again could be app-specific (ie destroying the current display and recreating in the proper mode).
Quote from: "aldacron"Quote from: "Matzon"
resize, focus, stay-on-top, minimize, restore, move etc etc.
It's hell to deal with, and quite hard to make it behave *exactly* similar on each platform. Therefor we try to keep it at a minimum. That minimum however, have been a bit fuzzy at times - since there are different opinions as to what that minimum is. That, and someone actually has to implement whatever we agree to...
All of those events are easily handled through the window system's event manager, yes? There are two things that need to be done dependeing upon the specific event:
1) let the app know that the scene needs to be resized on resize/move events, and
2) activate/deactivate the app on other events.
Both cases can be handled with a listener interface that must be registered during initialization. This is basic stuff that I started doing on Windows in the DDraw days. I'm just not seeing the difficulty here, as long as you are only reacting to Window events and not providing a way to create them programmatically.
Well, you're talking Windows here. As matzon said, the job is harder once you move to multiple platforms. Look how hard it is for SUN to maintain consistent behaviour in AWT/Swing. But the important point is that it is simply not that important - if you need special windowing, SWT/AWT is much better at it than us.
Quote
What's more difficult, as I see it, is dealing with toggling between fullscreen/windowed mode on Windows, since the gl context gets smashed (aauming the Window is destroyed and recreated) and all active textures/states need to be reloaded/reset. This, however, is an app-specific problem which again can be handled via the same listener. LWJGL can provide a isResetRequired method which returns true on all platforms where the context is smashed on a fullscreen toggle. And the toggling itself need not be implemented in the API, but again could be app-specific (ie destroying the current display and recreating in the proper mode).
Where did you get that from? In fact, fullscreen/windowed toggling works fine in LWJGL CVS code on win32 (and linux) right now.
- elias
What I'm getting at is that in LWJGL 0.9 we used to be able to create arbitrarily-sized windows, but in current CVS we cannot. In current CVS you can create windows, but only at a size that corresponds to a video mode that the 3D hardware allows - which makes no logical sense whatsoever.
I'm currently intending to step back to a previous version to fix this, but would be just as happy if you integrated the SWT binding to make it "official", and released a new version ASAP. It's been a while since the last official release, and there's so much in the API that would be useful to use, but if it's not possible to create non-4:3 windows, that's just not an option.
I don't have the time nor the bandwidth to download 150-200MB of compiler just so I can draw a square window. :roll:
For now, it has been fixed by adding a public DisplayMode constructor. And a new release is imminent
- elias
Quote from: "elias"
Well, you're talking Windows here. As matzon said, the job is harder once you move to multiple platforms. Look how hard it is for SUN to maintain consistent behaviour in AWT/Swing. But the important point is that it is simply not that important - if you need special windowing, SWT/AWT is much better at it than us.
You're missing my point. There's no need for
special windowing. I agree that SWT/AWT are the better solution in that case. Sun's difficulties with AWT have nothing to do with this. All I'm talking about is having the ability to create a Window which can be any size, which can be resized by the user (or not), and nothing more. In other words, the same functionality offered by SDL (actually less, since SDL also has the ability to hook into system window messages). I'm not talking about supporting child controls and all of that, which
is inconsistent from platform to platform.
IIRC Cas said before (more than once) that windowed mode was supported for use in development. All I'm asking is that windowed mode be given as much importance as fullscreen mode. People *will* complain about fullscreen only games, particularly those who play them in the office (I'm thinking from an indie business perspective here).
Quote
Where did you get that from? In fact, fullscreen/windowed toggling works fine in LWJGL CVS code on win32 (and linux) right now.
Yes, toggling has worked in LWJGL since I first used it. I haven't looked at CVS in a while, but if things are as they were before then toggling is done manually by resetting the display mode, destroying and recreating the window. Unless there's a toggle method now? But the opengl context will still get clobbered when the window is destroyed, a new one will be recreated, and all textures will need to be uploaded to the card again (unless things have suddenly changed on Windows).
My intent was to say that this is the most difficult and inconsistent aspect of supporting cross-platform windowed mode, in my view.
Well, I think resizing is special, because it is only applicable to windowed mode. And don't take Cas too seriously on the issue, as some of us crazy danes spoiled his grand debug-only plan a long time ago ;)
And yes, you can now setFullscreen(boolean) or setDisplayMode(mode) on Display and not loose your context.
- elias