Great Stuff.
Now I’ll have to buy a USB gamepad so I can try the Jinput integration 
And I can compile SharpShooter16k as an unsigned Application.
Alan 
Edit: Damn, there’s still at least one doPrivileged missing. App won’t work unsigned still.
It’s in the utilities lib, I guess it got missed.
It’s Ok if I set the display directly using org.lwgl.opengl.Display(…). In fact that compiled to smaller code, so I’m keeping it ;D
/* mode = org.lwjgl.util.Display.setDisplayMode(
org.lwjgl.util.Display.getAvailableDisplayModes(
640, 480, -1, -1, 16, 32, 60, 85),
new String[] {"width=800", "height=600", "bpp="+
Display.getDisplayMode().getBitsPerPixel(), "freq=60"});
*/
DisplayMode modes[] = Display.getAvailableDisplayModes();
for (int i=0; i< modes.length; i++) {
DisplayMode m = modes[i];
if (m.getBitsPerPixel() ==
Display.getDisplayMode().getBitsPerPixel()) {
if ( m.getWidth() <= 800 && m.getHeight() <= 600 &&
m.getFrequency() <= 85)
mode = m;
if ( m.getWidth() == 800 && m.getHeight() == 600 &&
m.getFrequency() == 60)
break;
}
}
Display.setDisplayMode(mode);
For reference here is the stacktrace
java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.reflect.AccessibleObject.setAccessible(Unknown Source)
at org.lwjgl.util.Display$1Sorter.<init>(Display.java:162)
at org.lwjgl.util.Display.setDisplayMode(Display.java:210)
at G.<init>(Unknown Source)
at G.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
#### Java Web Start Error:
#### Keyboard must be created before you can query key state
Great news guys! Controllers have been awaited for a long time. Thanks a lot! And not to forget the controbution of kevglass. Kev, would you mine to write a little controller API usage in the javadoc of Controllers class please? I have some questions such as, how do you look up for a type of controller. Does Controller.getName() provide a sufficiently standard id? Which build of jinput should we get? Sources, nightly bulld or latest release?
The following ones are more for general doc: How to lookup a particular button or axis? How to poll? How to check for the value of a button?
Thanks!
-
There is no way of picking particualr types of controllers. This was hidden away since JInput (or rather the libraries underneath) are so un-reliable in providing the correct type. The way the code is written is meant to encourage you to write configuration utilities.
-
getName() provides what ever the operating system is calling the controller. Again its not specified anywhere whether that’ll be reliable or not.
-
JInput binaries and libraries will be included with the LWJGL release. (they’ve just been missed for now)
-
Polling - I thought this was quite easy and not requiring doc (Controller.poll() or Controllers.poll() if you want to poll them all at once)
-
The methods are named after their buttons/axis or you can use the indexed version. Again I thought this was a little too obvious to be stating.
-
Checking the value of a button - on the controller interface -
/**
* Check if a button is currently pressed
*
* @param index The button to check
* @return True if the button is currently pressed
*/
public boolean isButtonPressed(int index);
Again it seems pretty simple? Unless its been changed?
I’ll update the javadoc with a usage scenario if you think it really required? There is also the test that goes along with the LWJGL input stuff?
Kev
Thanks Kev. About write doc or not, I think it’s just a question of good practice. Writing little doc usage doesn’t hurt and is just a good habit. When used to, it doesn’t take hours to do.
updated and fixed in 0.98-1
you dont even need to call poll - if you have created a display, then Display.update will check it for you
Its another maintainence issue. Writing usage doc where appropriate is a really good idea, writing it where its needless is another place thats not compiler checked that you need to remember to update when you update/change APIs. Whats worse than no documentation, documentation thats out of date.
Personally, I think its a question of ‘good practice’ to consider writing it, not just to blindly go ahead and write it.
Kev
[quote]Personally, I think its a question of ‘good practice’ to consider writing it, not just to blindly go ahead and write it.
[/quote]
I agree. My point was to have some API usage in the javadoc.
great work on getting this release out, oh and well done on busting that sis/s3 bug!
Hmm, I think I’m going to point this at Cas this time It seems that he’s using “setAccessible” on private fields to access DisplayMode fields directly. Instead, he should really use reflection to access the public accessors, since I don’t think it’s good to make privileged calls in a util library.
- elias
Thanks for the response. I’m pleased to say that the doPrivileged()'s you put in the rest of the library have done the trick for org.lwjgl.opengl.Display.create() and org.lwjgl.Display.setFullScreen(), which means I can throw away my kludged library. Hooray. I’m sure org.lwjgl.util.Display can be fixed in release 0.99
Alan
I think we’ll patch it in 0.98 - it’s just a quickie fix to use interfaces instead of the horrible kludge that I hacked together
Cas
Matzon, do you know with LWJGL can connect with Radiant Editor?