[FIXED] OSX / Java 7

[kappa]

Should I be thinking of moving to Display.setParent(), or is it even possible(as the AWTGLCanvas stuff looks to be part of jMonkeyEngine 2)?

AWTGLCanvas will eventually be implemented but is probably be one of the last things on the TODO list. If you can switch to Display.setParent() easily and don't want to wait, then do make the switch.

From what I see in earlier comments, this is what I should expect at this point since AWTGLCanvas is not yet implemented, am I correct? I initialize my application along the following lines, using Display.setParent() with a canvas object:
...
where canvas is an AWT canvas, and parent a subclass of Applet.

Yup, no AWTGLCanvas atm. A decent example of how to use LWJGL's Display.setParent() as applet is the Basic LWJGL Applet example on the wiki.

[Freezerburn]

Using the zipped binaries from the January 16th post, I have a couple things happen when dropped the jar/libs directly over 2.8.5. This is with OS X 10.8.2.

First, I tried to run my current code (which pretty much just calls Display.create() with a title and size) using Java 6, and it gave some kind of memory error, which hard crashed Java.

com.intellij.rt.execution.application.AppMain quit unexpectedly while using the liblwjgl.jnilib plug-in.

(if you can't tell, I'm using IntelliJ IDEA 12)
This showed up in a crash window, with this output to my console:

Invalid memory access of location 0x50 rip=0x1144d99fe

Then I switched over to Java 7, and got the standard "JAWT_GetAWT must be called after loading a JVM". From what I read in the thread, it seems like if I want to use LWJGL with Java 7, I need to create an AWT window and attach the Display to that? Is that why it currently can't run?

[Nagi]

Hi. This is my first post here. Hope it's useful. I've been using this version of LWJGL for testing my game on Mac OS X (Java 7.) My game runs perfectly, but I've noticed two little details, which I'll show by means of the following program:

public class Main {
	public void start() {

// AUDIO INIT
		try{
			AL.create();
		} catch (LWJGLException le) {
			le.printStackTrace();
			return;
		}
// END AUDIO INIT

// DISPLAY INIT
		try {
			Display.setDisplayMode(new DisplayMode(800,600));
			Display.create();
		} catch (LWJGLException e) {
			e.printStackTrace();
			System.exit(0);
		}
// END DISPLAY INIT

		GL11.glMatrixMode(GL11.GL_PROJECTION);
		GL11.glLoadIdentity();
		GL11.glOrtho(0, 800, 0, 600, 1, -1);
		GL11.glMatrixMode(GL11.GL_MODELVIEW);

		while (!Display.isCloseRequested()) {
			GL11.glClear(GL11.GL_COLOR_BUFFER_BIT | GL11.GL_DEPTH_BUFFER_BIT);	
			GL11.glColor3f(0.5f,0.5f,1.0f);
			GL11.glBegin(GL11.GL_QUADS);
			GL11.glVertex2f(100,100);
			GL11.glVertex2f(100+200,100);
			GL11.glVertex2f(100+200,100+200);
			GL11.glVertex2f(100,100+200);
			GL11.glEnd();
			Display.update();
		}

		System.out.println("Voila");
		Display.destroy();
	}

	public static void main(String[] argv) {
		Main m = new Main();
		m.start();
	}
}

The above program won't run on my Mac (OS X 10.8.1). It gets locked, and the window is never shown. However, if I swap the AUDIO INIT and DISPLAY INIT sections, it runs and the window is perfectly shown! I.e., executing AL.create before Display.setDisplayMode leads to Display.setDisplayMode getting stalled. I suspect it might be a synchronization problem, but I could be wrong. Nevertheless, inverting the initialization sections allows the program to run fine.

The other detail is that if I close the window by clicking on the top left red button of the window, the program closes fine, and the "Voila" message is shown (i.e., Display.isCloseRequested() returns true). However, if I press Command-Q, the window is also closed but the string "Voila" is not shown... it seems Command-Q kills the app immediately... is that the intended behavior? If yes, how can I capture the window-close message in order to clear the audio and perform further cleanup when Command-Q is pressed (I ask because LWJGL on Java 6 does not kill the app immediately when Command-Q is pressed.)

Thanks for reading. And of course, thank you for your work!

[kappa]

New update:

- full native cursor support now (including animated native cursors)
- fix issue with Display.setParent on Java 7+ (as reported by @pizza2004, @ac & @Freezerburn)
- implement Mouse.isInsideWindow()
- fix Display.getWidth()/getHeight() to return correct values
- fix problem with resizing

[edit] another minor update:
- fix a crash on exit
- fix initial Mouse.getX()/getY() values so they report the correct mouse position
[/edit]

Do please test and report any issues.

Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip

[rachoac]

Hi there -- been anxiously monitoring this thread for a month or so now. Y'all are my heroes for taking this incredibly annoying problem on.

Using Kappa's latest binaries, I'm encountering this exception on OSX + Java7:

Exception in thread "Thread-7" java.lang.UnsatisfiedLinkError: org.lwjgl.opengl.MacOSXDisplay.nCreateWindow(IIIIZZZZLjava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)Ljava/nio/ByteBuffer;
   at org.lwjgl.opengl.MacOSXDisplay.nCreateWindow(Native Method)
   at org.lwjgl.opengl.MacOSXDisplay.createWindow(MacOSXDisplay.java:140)
   at org.lwjgl.opengl.Display.createWindow(Display.java:303)
   at org.lwjgl.opengl.Display.create(Display.java:845)
   at org.lwjgl.opengl.Display.create(Display.java:754)
   at org.newdawn.slick.AppGameContainer.tryCreateDisplay(AppGameContainer.java:299)
   at org.newdawn.slick.AppGameContainer.access$000(AppGameContainer.java:34)
   at org.newdawn.slick.AppGameContainer$2.run(AppGameContainer.java:350)
   at java.security.AccessController.doPrivileged(Native Method)
   at org.newdawn.slick.AppGameContainer.setup(AppGameContainer.java:345)
   at org.newdawn.slick.AppGameContainer.start(AppGameContainer.java:314)
   at com.racho.client.display.Surface.init(Surface.java:108)
   at com.racho.client.ControllerImpl.start(ControllerImpl.java:80)
   at com.racho.client.RunClient$1.run(RunClient.java:32)
   at java.lang.Thread.run(Thread.java:722)

The app is webstart enabled so if anyone is interested in trying it live to reproduce, let me know.

[kappa]

@rachoac do double check that you replaced both the old lwjgl.jar and the native correctly (in the case of JWS, the new native will probably have to replace the old native in the mac natives jar).

[princec]

Seems to be working great for me

Cas

[Nagi]

I've tested this new version and my game keeps running fine. I know the 2 issues I've previously commented have not been addressed yet, but I wanted to inform you that everything seems fine with this new build. Thank you!

[rachoac]

Doh @kappa thanks so much -- I updated the jar properly and things work awesomely now. I have not encountered further issues in OSX yet, I will let you know if I do. Thanks so much!

[ajr_1]

Thanks for the updates Kappa.  This seems to be working in general for me, but I have a strange issue:

Clicking on our load/save menu buttons bring up a Swing jFileChooser to select the file to load or save.  This doesn't happen using Java 1.7 with new LWJGL builds - it just hangs without any exception or error messages.  The funny thing is, when I step through the code, it works fine every time.  I'm not sure if this is anything to do with LWJGL or if it's a Java 1.7 issue, as when I drop down to Java 1.6 everything works, even with the new LWJGL builds.  I'll keep looking into it, but without any exceptions and no problems when stepping through, it's a tough one to narrow down.

 

[kappa]

Thanks for the updates Kappa.  This seems to be working in general for me, but I have a strange issue:

Clicking on our load/save menu buttons bring up a Swing jFileChooser to select the file to load or save.  This doesn't happen using Java 1.7 with new LWJGL builds - it just hangs without any exception or error messages.  The funny thing is, when I step through the code, it works fine every time.  I'm not sure if this is anything to do with LWJGL or if it's a Java 1.7 issue, as when I drop down to Java 1.6 everything works, even with the new LWJGL builds.  I'll keep looking into it, but without any exceptions and no problems when stepping through, it's a tough one to narrow down.
 

Not sure what it could be, but there was a recent post in another thread that might be relevant, basically try Swing's setLightWeightPopupEnabled(false) method.

[Nagi]

Further insight:

1) Display.setDisplayMode locks after AL.create

I haven't looked at it as I have the simple workaround commented before. I've modified the lib I'm using (LibGDX) to use this workaround and it works so far.

2) Command-Q kills my app immediately (Closing the app by means of the menu has the same effect.)

Well, I have found a workaround for this, which might be useful for other people. First, I was expecting windowShouldClose in org_lwjgl_opengl_Display.m to be called whenever Command-Q is pressed. However, windowShouldClose is only invoked when the window is going to be closed. The window, not the app. If I close the app by clicking the top left red button, windowShouldClose is readily invoked. But Command-Q does not trigger it.

Then I took a look at QuitStrategy, and set it to CLOSE_ALL_WINDOWS (the default action being SYSTEM_EXIT_0… that's how the app responds, a direct exit(0).) However, changing the QuitStrategy disabled Command-Q, i.e., the app would not close anymore by means of Command-Q. A quick glimpse at Java code reveals that Java dispatches a WINDOW_CLOSING event to the Frames of the app. It seems my app does not receive such notification, or I have yet to learn how to capture it.

Therefore, I defined my own QuitHandler in MacOSXDisplay.java:

            Application.getApplication().setQuitHandler(new QuitHandler() {
                @Override
                public void handleQuitRequestWith(QuitEvent event, QuitResponse response) {
                    response.cancelQuit();
                    doHandleQuit();
                }
            });

(I'm doing this in createWindow.) Note that this handler simply cancels the app quit, and notifies MacOSXDisplay's handler about the quit request.

And that's it. So far, so good. This workaround allows me to test my game at finer detail, but of course I could be doing something wrong. Let's better wait until the LWJGL gurus implement a fix.

Thanks to such gurus, of course.

[kappa]

@Nagi thanks for your detailed reply.

I'll have a look into AL.create freeze thing and see if I can find a fix.

As for the CMD+Q thing I wasn't sure what default behaviour we should use since its an OS shortcut and didn't want the user to lose the option to kill a crashed LWJGL app (like in fullscreen mode thus requiring a hard reboot). However looking further into it there seems to actually be a proper way to force kill an OS X app (using CMD-Shift-Option-Esc held for 3 seconds) therefore we should actually catch CMD+Q and make it behave the same as the red X close button.

[cookies]

Hi,

thanks a ton for your continued work on this! I still have the same problem with the new build though: when I use it with the jMonkeyEngine and turn Multisampling/AA on, the JVM crashes. Without that, it seems to run fine.

I'll attach the crash log hoping it helps you a bit.

[kgcab]

With your latest drop, the latest Minecraft, Java 1.7.0_11-b21, and Mac OS X 10.8.2, keyboard input still fails after the first few characters are read.

Keyboard.next() is returning false, except when non-alpha keys are typed (such as shift, control, tab, etc). Then Keyboard.next() returns the pressed key.

It feels like some other part of lwjgl is consuming the keypresses.

Thanks for the hard work.