New sizing and positioning API:
- Add setResizable(boolean) / isResizable() flags to Display which should dynamically alter the resizability of the native Display when in windowed non-setParented mode
- Add getWidth() / getHeight()
- Add getX() / getY()
- Add setLocation(int, int)
- Add setSize(int, int)
- Add setBounds(int, int, int, int)
- Add wasResized() which will be processed in update(), and return true if the window size has changed since the last call to update()
New focus management API:
- Add requestFocus() to gain focus
- Add setAlwaysOnTop(boolean)
- Add toFront() and toBack()
Anybody think of anything else?
Cas :)
Sweet thanks!
I still think we should be able to get Mouse x & y negative values off screen without dragging (hidden switch only allows if dragging). This is unrelated to window API stuff, but it would be useful to windowed games.
Quote from: jediTofu on July 07, 2011, 03:25:02
I still think we should be able to get Mouse x & y negative values off screen without dragging (hidden switch only allows if dragging). This is unrelated to window API stuff, but it would be useful to windowed games.
It is no longer a hidden switch - see allow negative mouse coordinates also with Mouse.next() (http://lwjgl.org/forum/index.php/topic,4044.0.html) which is already committed.
But I'm not sure you can get mouse coords outside of the window when you didn't grab the mouse.
movement outside window is tricky without grab, it requires a system hook - on windows. Not sure about the other.
Quote from: jediTofu on July 07, 2011, 03:25:02
I still think we should be able to get Mouse x & y negative values off screen without dragging ... This is unrelated to window API stuff, but it would be useful to windowed games.
Implementation problems aside, extra changes shouldn't be needed for non dragged relative mouse position outside the window, the new API above provides the getX() & getY() of the window. Combined with Java's MouseInfo class you'll be able to get that info. Besides non dragged relative screen position outside the window is an extremely rare use case for games.
How will the requestFocus() stuff work? I don't know of a reliable way on Windows. But functions to make the taskbar icon blink would be nice...
Feature requests for the resize API:
- Specify a minimum/maximum window size
- Specify a fixed aspect ratio (Important!!)
Our game supports only 16:10 (or 16:9, depending on some things determined at startup) resolutions.
It would be great to have all that in LWJGL, but I feel kinda uncomfortable that we have to reinvent the wheel to make it happen. Our windowing code is shitty enough as it is, adding more stuff in there will require a lot of effort and testing (especially to get it to behave properly across platforms). I've always thought that LWJGL should have re-used some existing library for the windowing system, isn't there any lightweight open-source one we can use out there? I also wonder if it would be possible to hook-up our stuff in a JavaFX2 window, that would solve a lot of problems...
nbf from #LWJGL already has the resizeable Display stuff working for Linux, think he implemented it last night. Mac already has resizing built in (as it uses an AWT Frame) and its just a matter of a few methods to expose it (can add that if needed).
Only thing we need now is for someone to bite the bullet and implement it for Windows (any takers?).
@spasi agree with you, but not seen any good options for Java. There's stuff like SWT but its way too heavy. JavaFX has the Prism Toolkit but its unclear whether it will be available directly and even if it is it'll require a cutting edge version of Java (Java 7+ at least) plus it'll probably be a few years before its widespread enough especially on platforms like Mac (will be Java 8+ on there) which pretty much rules it out for now. If we're feeling ambitious we could try some cross project teamwork and work with Jogamp's NEWT!
However LWJGL's Display generally works brilliantly for the limited stuff it does (must say I do like its simplicity). Its pretty battle hardened too being tweaked and patched for many years (it'll be 9 years old at the end of this month), so would be a shame to loose that stability and work.
I agree about the stability and maturity of the current code, but it's in a state that makes adding new features hard. There's very limited documentation and the code is inconsistent between platforms. Also the dependency on Display is very awkward, we can't possibly support multiple displays with the current code base. I tried to do it once and gave up quickly. I was hoping for a clean-up/redesign before adding any features, but it's ok if this RFE can be implemented relatively painlessly.
About Prism, I think JavaFX 2.0 will be supported on JDK6 as well. At least the current beta version requires 6.0u24, which is very reasonable. NEWT would be a nice option as well, as long as it has the features we need, I haven't checked what they've done so far.
well we're almost at 3.0 (two releases away?) would be a great opportunity to do some major API breakage and refactoring.
Thanks to whoever implements the proposed RFE, and +1 for a redesign of the Display class to support multiple monitors/adapters (please don't ignore the later :)). I will happily ditch JOGL for the resizing additions.
If you're gonna go that far I'd just say integrate it more properly with AWT and be done with it.
I didn't think some really simple changes like resizable windows is such a tricky thing to do though?
Cas :)
One thing: if the Display is made resizable (which would be very nice) could it also utilize an event listener API? Example:
Display.addDisplayListener(REFERENCE_TO_OBJECT_IMPLEMENTING_DISPLAYLISTENER);
Display.removeDisplayListener(REFERENCE_TO_DIFFERENT_OBJECT_IMPLEMENTING_DISPLAYLISTENER);
It could then appropriately call all registered listeners in update().
DisplayListener could be an interface with methods such as:
displayResized();
displayMoved();
displayEnteredFullscreen();
displayLeftFullscreen();
displayBPPChanged();
// etc
Alternatively, you could break up the possible types of feedback into different interfaces, such as DisplaySizeListener, DisplayPixelFormatListener, etc.
Just an update on this, decided for now to go for a bare minimum version of princec's resizing api. The following 5 methods have been added to the Display:
1) setResizable(boolean)
2) isResizable()
3) wasResized()
4) getWidth()
5) getHeight()
The mac implementation is done and now part of the nightly builds (so you can already start playing with it, runs really nice and smooth here). nbf is just polishing up the linux implementation and hopefully it should be added soon.
The windows implementation is still up for grabs, if you're interested in attempting it, just post here or pop into the lwjgl irc channel, shouldn't be much work if you're familiar with the Win API. Matzon's working on the windows implementation.
Is there any form of callback? How can I detect if the Display has changed size?
Also, what happens to the viewport when it is set smaller than the full Display but the window is resized?
Quote from: CodeBunny on July 14, 2011, 11:41:00
Is there any form of callback? How can I detect if the Display has changed size?
Just call Display.wasResized() every frame, if it returns true you will know that the window has been resized and that new Display.getWidth() and Display.getHeight() values are available. You can then take the appropriate steps to reposition/resize your content.
Quote from: CodeBunny on July 14, 2011, 11:41:00
Also, what happens to the viewport when it is set smaller than the full Display but the window is resized?
Only the window size is increased (i.e. more/less of the opengl context is visible at top right), nothing on the opengl side is changed (nor any viewport), that's up to you on how you want it to behave, whether you want to zoom/scale everything to new sizes or increase usable area by repositioning stuff.
Each of the above methods have JavaDoc defining the behaviour of the methods (just download the docs bundle from nightly builds and look at the Display class).
Alright. Sounds good.
Sounds perfect. Just need a way to determine if the window has focus or not now, and a way to grab it if possible (I'm aware that the crossplatform behaviour in this instance is sketchy). One reason I'd like to be able to do this is when switching a setParented display to fullscreen, we actually get two windows on the taskbar in Windows; if you alt-tab off the fullscreen display you're confronted with a rather strange big black window. I was hoping to be able to check that the fullscreen display was no longer focused and setVisible(false) on the AWT frame but of course that causes the LWJGL display to explode. So going back to the LWJGL Display seemed like the best idea. For which I needed the resizing stuff :)
How complex would it be to add setLocation()/setBounds()/setX()/setY()/setSize()/setWidth()/setHeight() API do you think? I suspect there are people out there who want to use an undecorated Display and manage their mouse interactions with custom widgetry rendered in OpenGL (TWL springs to mind).
Cas :)
Another update, Matzon's already finished the windows implementation and just needs to iron out some quirks, so we're almost done with implementing the resize api for all 3 platforms.
Quote from: princec on July 15, 2011, 09:46:26
Sounds perfect. Just need a way to determine if the window has focus or not now, and a way to grab it if possible (I'm aware that the crossplatform behaviour in this instance is sketchy). One reason I'd like to be able to do this is when switching a setParented display to fullscreen, we actually get two windows on the taskbar in Windows; if you alt-tab off the fullscreen display you're confronted with a rather strange big black window. I was hoping to be able to check that the fullscreen display was no longer focused and setVisible(false) on the AWT frame but of course that causes the LWJGL display to explode. So going back to the LWJGL Display seemed like the best idea. For which I needed the resizing stuff :)
The Display.isActive() (http://lwjgl.org/javadoc/org/lwjgl/opengl/Display.html#isActive()) call should tell you whether the window has focus.
As for the setParent issue you could try unparent the Display before switching to fullscreen and then reparent when going back to windowed mode, use Display.setParent(null) to unparent.
Quote from: princec on July 15, 2011, 09:46:26
How complex would it be to add setLocation()/setBounds()/setX()/setY()/setSize()/setWidth()/setHeight() API do you think? I suspect there are people out there who want to use an undecorated Display and manage their mouse interactions with custom widgetry rendered in OpenGL (TWL springs to mind).
Display.setLocation(x, y) (http://lwjgl.org/javadoc/org/lwjgl/opengl/Display.html#setLocation(int,%20int)) is already implemented :). As for setting the window size this can be done using
Display.setDisplayMode(new DisplayMode(width,height));so you can pretty easily write your own wrapper methods for setBounds(), setX(), setY(), setSize(), setWidth(), setHeight(), especially now that Display has the new methods Display.getWidth() and Display.getHeight().
The above is also some of the reason why only a subset of the original RFE was picked, however the extra methods you mentioned are nice and provide a much cleaner API. LWJGL 3.0 will probably be the API Breakage release and the plan is to rethink the API to be nice, simple and consistent without worrying about backwards compatibility or bloating the Display API. Probably need to reconsider if DisplayMode's should be used for windowed mode, IMO they're a bit ugly for such a usecase.
Awesome job guys, that was very fast.
Aha of course. Funny how after all these years I've only just gotten around to looking at this :)
Yes, the use of DisplayModes for windowed mode is rather strange - though of course there is the issue of aux/stencil/depth buffers and bitdepth as well; looks like the dimensions and buffer configurations probably need factoring apart.
Cas :)
This is probably by design, but "Display.wasResized()" doesn't work in Applets (and probably never when in a Canvas?). Just something to remember when writing Javadoc for these new methods ;) The workaround is to use ComponentListener's of course.
Quote from: jediTofu on July 20, 2011, 03:52:07
This is probably by design, but "Display.wasResized()" doesn't work in Applets (and probably never when in a Canvas?). Just something to remember when writing Javadoc for these new methods ;) The workaround is to use ComponentListener's of course.
Yup, the JavaDoc does mention if Display.setParent() or Fullscreen is being used then Display.setResized() will always return false.
Just curious, are you already using the resize api?
Quote from: kappa on July 20, 2011, 08:40:26
Quote from: jediTofu on July 20, 2011, 03:52:07
This is probably by design, but "Display.wasResized()" doesn't work in Applets (and probably never when in a Canvas?). Just something to remember when writing Javadoc for these new methods ;) The workaround is to use ComponentListener's of course.
Yup, the JavaDoc does mention if Display.setParent() or Fullscreen is being used then Display.setResized() will always return false.
Just curious, are you already using the resize api?
Well, I was just testing it out, because I thought that it'd be useful for my applet (since I'm setting width and height to 100% of the browser window). When I'm done, I'll probably also deploy it using Java WebStart though and use the resize api there. However, for the applet, I'm just using a component listener on the canvas. So the answer is...yes and no haha
Hm returning "false" is I think exactly the sort of abuse of return values that exceptions were designed for. I think it should throw an IllegalStateException if you attempt to ask if it's resized when in fullscreen mode.
Cas :)
Quote from: princec on July 21, 2011, 12:13:18
Hm returning "false" is I think exactly the sort of abuse of return values that exceptions were designed for. I think it should throw an IllegalStateException if you attempt to ask if it's resized when in fullscreen mode.
Cas :)
But then you'd have to put a try-catch block in your game loop (plus the if statement), and I think that's more computationally expensive than an if statement?
Another quick update on this, Matzon committed the resizing code for the windows implementation yesterday, so hopefully folk on Windows can start testing it too with the nightly builds.
It still has a few quirks in it namely:
Quote<Mazon> known issues/kinks:
1) window moves a bit when enabling resize (and back when disabling) - "normal" behavior?,
2) resize mouse cursor seems to sometimes stay when inside window (?)
3) when enabling resize, the client area seems to be off by x pixels - at least in mousetest, oddly minimizing and maximizing seems to "fix" the issue
All 3 of the above seem to be related to some odd Win API stuff, if anyone here is familiar with that API, do consider providing some feedback to assist in ironing them out.
Hi there,
I have tested the new API on Windows 7 64 bit and no problems here - great job! It feels a lot sturdier than the AWT workaround and I look forward to scrapping my Frame. As someone who is looking to use this, I do however have one request if I may?
As I see it the only thing that is missing is the ability to maximize the window. If that could be considered for the API requirements I would be a happy camper, at the moment I am forced to continue using the AWT workaround as my window needs to be that flexible.
Just thought I would drop this in. Great work so far!
Liam
EDIT: I have added a page to the Wiki with the AWT workaround and example code. I have dropped mention of the efforts being made here, when this is finalized either I'll update it with the new implementation or let you guys do it ^.^
http://www.lwjgl.org/wiki/index.php?title=Using_a_Resizeable_Native_Window
Quote1) window moves a bit when enabling resize (and back when disabling) - "normal" behavior?,
I would think that this would be from calling AdjustWindowRectEx in WindowsDisplay#setResizable. If AdjustWindowRectEx is already called somewhere else first, I'd think all you would have to do is call setWindowPos and use the rect from GetWindowRect instead of GetClientRect. You usually call AdjustWindowRect just the first time when creating the window, or if you add/change some GUI components.
Or if you're really wanting to adjust the client rect, then you'll have to take the window rect into consideration:
http://www.suite101.com/content/client-area-size-with-movewindow-a17846
Quote2) resize mouse cursor seems to sometimes stay when inside window (?)
I don't understand the question ???
Quote3) when enabling resize, the client area seems to be off by x pixels - at least in mousetest, oddly minimizing and maximizing seems to "fix" the issue
Not sure here. Sounds like you need to get the insets somehow and then add that to the x and y of the client rect. The link above would do that. I'm not sure how else to get the insets like you can in Java.
QuoteQuote2) resize mouse cursor seems to sometimes stay when inside window (?)
I don't understand the question ???
It's a bug - sometimes, when the mouse cursor is in the border of a resizable window, and hence in the "Resize N/S" or "Resize E/W" shape, and you move it back into the window, it stays the wrong shape instead of turning back into an ordinary pointer.
Cas :)
Is there any news on this? My current project pretty much relies on the solidity of this implementation to work well heh >.<
The following are things I would really like to see added:
- The Maximize window function (Already mentioned this)
- A minimum size for the window
I believe those two additions would 'complete' the API for most developers needs.
Sorry for the double posts, but I thought this was worth it to report the bug:
- On the MAC, after the resize has occured all offsets seem relative to the ultimate top of the window (i.e. the top of the native UI bar). This gives the effect of hiding part of the GUI underneath it.
Liam
Can't you put it on a JFrame? Display.setParent will still work, you know.
Quote from: Liam on August 30, 2011, 16:06:40
Sorry for the double posts, but I thought this was worth it to report the bug:
- On the MAC, after the resize has occured all offsets seem relative to the ultimate top of the window (i.e. the top of the native UI bar). This gives the effect of hiding part of the GUI underneath it.
Liam
Can you please clarify a bit more on exactly what the issue is here? I've had a look but not noticed anything odd in the resize behaviour, so not sure what the bug here is that you're reporting.
The Resizing API is now complete as the last remaining implementation (for Linux) is now part of the nightly builds.
I'll mark this RFE as done as its ready for use. Any further features or API's should probably be a separate RFE to keep things simple and allow LWJGL 2.8 to go ahead.
Please do test and report any issues so that they can get fixed for the soon to be released LWJGL 2.8.
Sweet! I'll have a go with the nightlies as soon as I can. Been holding off releasing an update of Revenge until 2.8 comes out :)
Cas :)