LWJGL Forum
Archive => Resolved Bugs/RFE => Topic started by: Mickelukas on May 21, 2009, 10:07:28
-
Hi there,
If I hold down a mouse button while moving the mouse outside my applet Mouse.isbuttondown still returns true even if I release the mouse. If I after that move the mouse back inside the applet it still says that the mouse button is down even though it isn't.
I could make a workaround for it if there was a function to check whether or not the mouse is inside the applet but the Mouse class doesn't have that functionality.
Any ideas?
-
It's probably an OS/driver restriction you have to handle yourself. If the mouse is outside the window, the OS most likely doesn't send events to the application. Lots of game engines have trouble with input when loosing focus.
-
Standard windows driver and windows xp. Probably the most common combination there is.
I could fix it if I were able to add the standard java mouselistener to the applet but when I do it doesn't get any events at all.
-
No workaround/solution for this? What about the possibility to catch the mouseevents from java seeing as they have mouse entered and mouse exited?
-
as with the above mentioned post this behaviour only happens with windows, what most games do to get round this is they grab the mouse Mouse.setGrabbed(true) or Mouse.setCursorPosition(middleOfScreenX, middleOfScreenY), so it can't leave the window, an example of this behaviour can be seen at http://www.minecraft.net
-
Well, half or so of my game is played outside the applet and half inside meaning that you will need to be able to move the mouse outside of the applet.
Is there no workaround to access the java mouse listener?
-
you can't really use the java mouse listener since LWJGL's Display is not an AWT/Swing component. You could use LWJGL's AWTGLCanvas container but then you would loose significant performance.
You could also use the AWT Robot but then this would require signed permissions.
one thing that comes to mind is that you could use javascript to detect if the mouse is outside the applet, that way you can alert the applet using using liveconnect.
-
It still sounds like something that lwjgl may be able to handle - but is it a windows only issue ?
-
can't speak for mac or solaris, but linux correctly detects mouse button release when outside the applet Display, while on windows it does not.
-
one thing that comes to mind is that you could use javascript to detect if the mouse is outside the applet, that way you can alert the applet using using liveconnect.
This was how I was going to solve it if it wasn't possible for you guys to see what causes it. I don't like that kind of workaround though seeing as it brings alot of combinations of webbrowsers/OS' that might cause problems.
-
It still sounds like something that lwjgl may be able to handle - but is it a windows only issue ?
Did you get an epiphany regarding this issue? :) If it would be possible to get it fixed in 2.2 then I don't have any more open issues after my merge from JOGL to LWJGL.
-
Still no clue about this one?
-
I comitted a fix yesterday. Nightly failed (missing import) but hopefully it should all be good tonight - pending tests.
-
Cool :) If you get rid of the security alert and release 2.2 I'll definately donate some money as thanks for all the bug fixing :)
-
well, it seems that there are some issues still - so need to look at bit on that - not sure if I have time tonight tho...
lwjgl 2.2 will happen eventually - but the certificate stuff is out of my hands, and moving at an invisible snails pace.
-
well, it seems that there are some issues still - so need to look at bit on that - not sure if I have time tonight tho...
lwjgl 2.2 will happen eventually - but the certificate stuff is out of my hands, and moving at an invisible snails pace.
So it might be moving quite quick as it is invisible eh? :P
Well, I'm fine with the certificate question while developing the game but it would be cool to have it fixed once I launch a beta :)
-
Had the time to look into the windows issue?
-
Matzon has found and fixed the mouse issue on windows, patch is in svn.
You can find a working example of it in action here (http://bossattack.com/games/gearsapplet/GearsApplet.html)
-
It's working wonderfully :) Thanks a bunch!
-
I had to download the nightly build for another problem so ended up testing this on my own application.
I have a problem that might not be easily fixed. When I hold down the mouse and move it to a negative X or Y (outside the applet below or to the left of it), the Mouse.getX() and Mouse.getY() never goes below 0 so I don't know if it is just outside the corner or a kilometer outside.
Any ideas?
-
I tried to work around it myself but I guess it needs to be changed within LWJGL (preferably before 2.2.0 :)). Is something difficult to fix or can you easily pass negative numbers?
-
No ideas about this?
-
fixed in nightly I think
-
fixed in nightly I think
You're my hero Matzon! I'll download the nightly later today or on Monday to check it out :)
-
Work got in-between... I tried it out now and I get the same behavior as before. When moving the mouse to where I'd expect a negative x or y value it just returns 0.
-
oh, forgot this:
/doc/lwjgl_hidden_switches.text - added a new allowNegativeMouseCoords
otherwise we might risk breaking things that rely on non-negative value
http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/trunk/LWJGL/doc/lwjgl_hidden_switches.text?r1=3241&r2=3240&pathrev=3241
-
Works like a charm in Eclipse but not in the browser.
I get following error during startup:
Fatal error occured (8): access denied (java.util.PropertyPermission org.lwjgl.input.Mouse.allowNegativeMouseCoords write)
java.security.AccessControlException: access denied (java.util.PropertyPermission org.lwjgl.input.Mouse.allowNegativeMouseCoords write)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.System.setProperty(Unknown Source)
at dreamlandz.Main.init(Main.java:83)
at org.lwjgl.util.applet.AppletLoader.switchApplet(AppletLoader.java:765)
at org.lwjgl.util.applet.AppletLoader.run(AppletLoader.java:643)
at java.lang.Thread.run(Unknown Source)
Do I need to sign the whole package with the same certificate to make it work as that would not be very appreciated. Would it not be possible to make a setter and getter for the value within the Mouse.java file instead of reading the "secret" value.
I had to figure out how to set it but if someone wants to do it and reads this just edit the initiation part of your program and add this:
System.setProperty("org.lwjgl.input.Mouse.allowNegativeMouseCoords", "true");
-
I first wrote that it worked because I had only tested it in Eclipse and then I updated the post. You were online at the time Matzon so I'm no sure you saw the update. Therefore this post.
-
you could try using -Dorg.lwjgl.input.Mouse.allowNegativeMouseCoords=true as a java vm argument.
for an applet that'd be <param name="java_arguments" value="-Dorg.lwjgl.input.Mouse.allowNegativeMouseCoords=true">
not tried it but it might work.
-
I added it to my arguments list making it look like this:
<param name="java_arguments" value="-Dsun.awt.noerasebackground=true -Dsun.java2d.noddraw=true -Dorg.lwjgl.input.Mouse.allowNegativeMouseCoords=true -Dsun.java2d.opengl=false -Dsun.java2d.pmoffscreen=false -Dsun.java2d.d3d=false">
Then the applet does load but I don't get any negative mouse coords.
-
you could add some debugging to see whats going on...
could be applets that behave differently
-
I think but not entirely sure that the Applet SecurityManager does not allow you to change System Properties (System.setProperty) unless its explicitly one of the exceptions. That could explain the current behaviour.
A possible solution (other than signing your applet) would be to have a publically exposed API in LWJGL e.g. Mouse.enableNegativeCoords(boolean). Technically its not just unlocking negative coords but any coords outside the Display, so could also be something like Mouse.clipCoords(boolean), Display.clipMouseCoords(boolean), etc.
-
A possible solution (other than signing your applet) would be to have a publically exposed API in LWJGL e.g. Mouse.enableNegativeCoords(boolean). Technically its not just unlocking negative coords but any coords outside the Display, so could also be something like Mouse.clipCoords(boolean), Display.clipMouseCoords(boolean), etc.
*wink* *wink* Matzon? *wink* *wink*
-
Need more winks? ;) *wink* *wink*
-
I'll go on with winking at you Matzon :) *wink* *wink*
-
I'll go on with winking at you Matzon :) *wink* *wink*
;) I had forgotten all about this thread. I will look into it soon - but I'll be drunk tonight, so I think I'll wait till tomorrow.
-
;) I had forgotten all about this thread. I will look into it soon - but I'll be drunk tonight, so I think I'll wait till tomorrow.
Lol, have a nice evening :)
I put the programming on hold for a year and just started up again three or so weeks ago with motivation again so no rush :)
-
several of the flags are initialized statically. So setter methods may or may not have any effect, depending on how stuff is initialized :/
not sure how to handle this ...
-
several of the flags are initialized statically. So setter methods may or may not have any effect, depending on how stuff is initialized :/
not sure how to handle this ...
It doesn't matter that they are static as long as they aren't final, right? But I barely know any Java, how I managed to make this much of a game is just because I'm stubborn and spent more than a thousand hours :P
-
several of the flags are initialized statically. So setter methods may or may not have any effect, depending on how stuff is initialized :/
not sure how to handle this ...
It doesn't matter that they are static as long as they aren't final, right? But I barely know any Java, how I managed to make this much of a game is just because I'm stubborn and spent more than a thousand hours :P
The problem is that the flags are set in static initializers - and passed down to native code. So if you change then after, then differnet parts of the code will not be told about the value change.
I'll look into how and if we can change that behavior.
-
Ah, right, thanks for the explanation. Maybe give the option to set such things before creating the OpenGL context and not allow them to be changed afterwards?
-
It wasn't as easy as I'd have hoped eh?
Oh, and as thanks for you all answering my weird questions and bugs without snapping at me I made my first donation :-)
Mike
-
More than 6.000 views :) Was the conclusion that it wasn't possible so you need to sign applets if you want to use it a non gripping mouse?
Mike
-
Getting close to 7.000 views :), Matzon?
-
Getting close to 7.000 views :), Matzon?
heh, honestly, haven't looked at it. However the main problem still remains. The options are really meant the be static, which it is passed as VM parameters.
Since this is an applet specific issues, I am thinking about being able to set lwjgl specific (or at least generally specific) parameters through out applet loader, since that is signed. kappa, does that make sense?
-
Since this is an applet specific issues, I am thinking about being able to set lwjgl specific (or at least generally specific) parameters through out applet loader, since that is signed. kappa, does that make sense?
Ah yes (pretty genius), that would work since it'll be done before any LWJGL classes start running and not require the user to sign their own jars to do it. It would be almost on par with setting VM parameters. Would need to make sure which parameters are allowed though if its going to be a general solution. Does sound good though and likely to work well.
-
so, all properties beginning with org.lwjgl should be allowed.
What else?
some of the directdraw / opengl com.sun variants?
-
so, all properties beginning with org.lwjgl should be allowed.
What else?
some of the directdraw / opengl com.sun variants?
org.lwjgl should be fine, don't think we need any other properties. Plugin2 pretty much covers most the stuff that might have been useful like setting vm memory size, etc. The java2d directdraw and opengl issues don't apply any more to LWJGL since the move to Display.setParent() which completely bypasses the issues, besides there are already applet parameters available to handle those. Can't think of anything else that might be useful, so yeh, org.lwjgl should be fine.
-
Wuhuuu, I see a fix on the horizon :)
Almost getting ready to starting blogging/discussing my game, just need another month or so and it'll actually be a game and not a simulator of sorts so this would be great.
Mike
-
I have added parsing of java_arguments for org.lwjgl* properties in the applet loader.
Please try the next nightly (> 1011)
usage:
<param name="java_arguments" value="-Dorg.lwjgl.input.Mouse.allowNegativeMouseCoords=true -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.opengl.Display.allowSoftwareOpenGL=true">
-
Matzon,
I downloaded the newest nightly (1012) and tried it both in my own applet and in the gears applet that comes with the lwjgl_applet but neither allows negative mouse coordinates when that parameter is added.
Kind regards,
Mike
-
are you able to get any value from inside your applet for the value System.getProperty("org.lwjgl.input.Mouse.allowNegativeMouseCoords") ? or does it return null?
haven't got time to test atm but would make life easier if you can confirm from an already working setup.
-
Running in the applet viewer it returns true (as expected as it always used to work)
Running in a normal applet with or without the argument gives the following:
access denied (java.util.PropertyPermission org.lwjgl.input.Mouse.allowNegativeMouseCoords read)
access denied (java.util.PropertyPermission org.lwjgl.input.Mouse.allowNegativeMouseCoords read)
java.security.AccessControlException: access denied (java.util.PropertyPermission org.lwjgl.input.Mouse.allowNegativeMouseCoords read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at client.Main.init(Main.java:294)
at org.lwjgl.util.applet.AppletLoader.switchApplet(AppletLoader.java:1011)
at org.lwjgl.util.applet.AppletLoader.run(AppletLoader.java:767)
at java.lang.Thread.run(Unknown Source)
But I guess that's to expect as well seeing as it isn't my applet that should be allowed to read the values but the applet loader, right?
Mike
-
But I guess that's to expect as well seeing as it isn't my applet that should be allowed to read the values but the applet loader, right?
yes, mean't from a signed jar, so you'd have to sign your jars to test it, thought you might already have such a setup.
-
apparently, using java_arguments was a bad idea since the JRE strips arguments from it :/
so, fixed it by using lwjgl_arguments instead. Tested locally and works as expected :)
Please get the next nightly build (> 1012)
-
Yay, you're the best Matzon, I'll test it tomorrow :)
Mike
-
Yay, it is fixed, thanks :-D