Hi.
Since Oracles Java7 for OSX is soon available even as a JRE with Java7 update 6 (due shortly, preview here (http://download.java.net/jdk7u6/macosx.binaries.index.html.template)) and as a JDK (http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1637583.html) for some time now we (the jMonkeyEngine Team) started playing with it.
Oracle goes back to the "dylib" suffix instead of "jnilib" but with the appropriate querying of the system suffix we were able to extract the file with the correct name in our natives extraction system so it in fact loads the lwjgl binaries without problems. When using an off-screen context and painting the result back to awt we also managed to get the rendering engine to work.
However the canvas implementation as well as the "normal" main window of lwjgl fail under Java7.
This is the error of an app using the main window:
org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:51)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:94)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:92)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:92)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:66)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:57)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXContextImplementation.create(MacOSXContextImplementation.java:47)
at org.lwjgl.opengl.ContextGL.<init>(ContextGL.java:132)
at org.lwjgl.opengl.Display.create(Display.java:875)
at org.lwjgl.opengl.Display.create(Display.java:782)
at com.jme3.system.lwjgl.LwjglDisplay.createContext(LwjglDisplay.java:137)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:113)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:205)
at java.lang.Thread.run(Thread.java:722)
Any thoughts on this?
Cheers,
Normen
Ni Normen,
LWJGL is completely broken under OSX Java 7, and needs a ground-up rewrite of the Display implementation. There have been mutterings about people working on this but as yet, no confirmed progress or even so much as a commit to SVN. There was some hope that Mojang were going to contribute to it as they've got tons of money tied up in it and will suffer a veritable shit/fan interface situation if they don't get it done before it's offered on general release but ... still no news.
Cas :)
Alright, thanks for the info.. Might be I'll have to rig up a build environment for lwjgl/avian some time for iOS support for jME.. But thats definitely a thing of the future.. Maybe I'll find time to at least have an OSX build going with Java7.. But that'll be some research for me as I never built lwjgl yet and I have no idea how the JDK is tied in.. So no use to wait for me in this matter I either guess ;)
I've been one of those people muttering about helping out on the osx thing, although I have the code and can see the OSX items it would be good to get some of the other developers to provide some of their insight on what needs to be done. By that I mean, where are the java interface points that need to be taken in to concideration (ie what methods are the start points for where the work needs to be done), what c files need to be scrapped and replaced. I've done a bit of research on this and have a good idea of how to get AWT and JNI to work in cocoa and also how to get opengl context's but I have no idea where it needs to be plugged in and what needs to be passed back to the java code.
I guess starting with those that appear in the exception is a good idea ;D If you have some instructions on how to set up lwjgl, that'd probably help me and others to have a look too.
I saw the stacktrace ;D But wanted to get a complete picture before playing around. I guess could do it via trial and errorto start with
In terms of setup what do you mean? Do you mean how to build it? So far I have just checked out the SVN, there are some ant scripts there for building the natives. I'm not an expert on building the natives though.
I'll have a play around tonight and see if I can build whats there, and see if I can replace some code in the below area's.
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:57)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXContextImplementation.create(MacOSXContextImplementation.java:47)
at org.lwjgl.opengl.ContextGL.<init>(ContextGL.java:132)
I'll reply here with some compile help and how I am getting on. I have no idea how to commit back to the repository (unless anyone can put commits back)
So
After getting the code from SVN
http://java-game-lib.svn.sourceforge.net/viewvc/java-game-lib/
I ran the command ant in
/java-game-lib/trunk/LWJGL
ant -v
(-v gives you some verbose to help debug errors, remove it if you don't need to see everything)
You will need to edit
/java-game-lib/trunk/LWJGL/platform_build/macosx_ant/build.xml
to change gcc-4.2 to gcc and to remove the ppc compile and link sections (as xcode no longer supports it)
At the moment it complains about OpenGL/gl.h and some other headers in context.m (it bombs out in the compile native stage) but I haven't had time to fix it
The way to use cocoa for AWT and opengl is documented in the link below
http://forums.macrumors.com/showthread.php?t=900661
just need to know where to plug everything in to, I think context.m needs editing and the classes here
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:57)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
but I haven't got the current code to compile yet so haven't bothered to try and make any code changes. But its a start.
Anyone feel free to add information or tell me I am talking rubbish ;D more people that can help the better!
@abcdef Do keep in mind that AWT is main reason LWJGL no longer works in Java 7. Previously we were able to get a Cocoa NSView from an AWT Canvas and stick an OpenGL context on it (NSOpenGLContext). This has changed in Java 7 (thanks to Apple) and it is no longer possible because AWT/Swing components are no longer heavyweight and are now lightweight (i.e. AWT Canvas's are no longer Cocoa NSView's).
There was a new AWT API added by Apple in an attempt to fix the above limitation which allowed a CoreAnimation Layer (e.g. NSOpenGLLayers) to be added to an AWT Canvas. However this brought its own set of problems (as seen with our LWJGL applet support on OS X Java plugin2) and not really the best way to go for an OpenGL binding.
Hence the most viable solution is to scrap AWT altogether and rebuild the LWJGL OS X Display implementation from scratch using pure Cocoa and Java JNI. In practice though many bits of the current LWJGL OS X implementation can be reused in a new implementation as some bits are already using Cocoa.
So just need to basically implement
http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8
?
And hook it in to lwjgl framework?
Yeh you could say that. A basic window with keyboard, mouse and an OpenGL context needs to be written in Cocoa. This should have all the features of the Display, Mouse and Keyboard classes which isn't much and mostly about matching the Cocoa API's to the Display ones. The features of the above should be connected to Java via JNI, there might be a little fiddling needed here with the Java thread and Cocoa thread to get it to work but should be easy if you're familiar with both.
There are a tiny amount of API's not available in Cocoa (e.g. grabbing the mouse) and are currently done in the LWJGL codebase using a bit of Carbon, this code can pretty much be copied over to any new implementation to preserve those features.
Lastly we'll probably need to add/keep support for the JAWT API that uses a CoreAnimation Layer as detailed in this thread (http://lwjgl.org/forum/index.php/topic,4023.0.html). This won't be used at all for standalone LWJGL application but needed for allowing LWJGL to be embedded in AWT (Display.setParent() and AWTGLCanvas, e.g. for allowing LWJGL use in Applets and other AWT/Swing Applications). This is already implemented in the current codebase (was added to support plugin2 applets) but could use a little further looking at and polishing up.
So not too difficult a task if you are familiar with Cocoa, Java JNI and some C but will require some time and effort to implement.
Thanks, lots of good info there. Will start on the window part first. I'm not a cocoa expert but I understand the documentation code well enough to have a try.
A question on the build front, how are the Mac components build now? Are they built on a mac? The build.xml in the natives section needs a bit of work I think. The ppc compatible gcc is now fully depricated in 10.8.
Also can this problem not be solved by using a similar strategy to the linux code? I've seen other opengl programs work just fine which are written in c/c++ rather than objective c
Quote from: abcdef on August 16, 2012, 09:58:14
A question on the build front, how are the Mac components build now? Are they built on a mac? The build.xml in the natives section needs a bit of work I think. The ppc compatible gcc is now fully depricated in 10.8.
Yeh to build the mac natives the build.xml needs to run on a mac and it will compile the natives for PPC, 32bit and 64bit into one universal fat binary. The current mac code is pretty old and targets OS X 10.3+ (includes various workarounds/hacks for problems in those old OS X's). A fresh rewrite should target OS X 10.5+ and only the 32bit and 64bit arch's. Support for PPC architecture and any OS X lower than 10.5 should be dropped now as the marketshare there is now insignificant and Cocoa wasn't as mature on those older OS's.
Quote from: abcdef on August 16, 2012, 09:58:14
Also can this problem not be solved by using a similar strategy to the linux code? I've seen other opengl programs work just fine which are written in c/c++ rather than objective c
Would be great if we could get away with only using C but Cocoa is really the future on OS X and is now the only officially supported framework. Previously both Java and Carbon were also officially support hence why we've been able to get away for so long just using AWT on OS X.
Just a quick update on things, haven't done too much in the last few days (Weather has been great where I am so been out enjoying it!)
I can now get everything to compile and build from the main ant script, I had to fiddle with the mac osx build script a bit.
Its looking like 10.6 should be the new min version supported because when carbon went there was one function in org_lwjgl_opengl_Display.m which needed changing and the new function is is only available to 10.6+
JNIEXPORT void JNICALL Java_org_lwjgl_opengl_MacOSXDisplay_nHideUI(JNIEnv *env, jobject this, jboolean hide) {
if (hide == JNI_TRUE) {
[NSApp setPresentationOptions:NSApplicationPresentationAutoHideDock];
} else {
[NSApp setPresentationOptions:NSApplicationPresentationDefault];
}
}
SetSystemUIMode has not been removed and not available.
https://developer.apple.com/library/mac/#documentation/Carbon/reference/Dock_Manager/Reference/reference.html
So now it's all building going to start making some changes...from looking at the code it looks like org_lwjgl_opengl_MacOSXCanvasPeerInfo.m needs to changed
p.s. I noticed that there are quite a few deprecations on the build, especially around opencl. org_lwjgl_opengl_AWTSurfaceLock.c has functions that are also deprecated which isn't surprising.
I should think targeting 10.6+ is fine - less than 4% of Macs on Steam are using 10.5.8 (the minimum version required for Steam).
Cas :)
abcdef, I hate to ask this, but I was contracted about two months ago to both update the Minecraft renderer as well as fix LWJGL on OSX + Java 1.7. For the past couple months I've been concentrating on the renderer itself, but I was literally going to be banging out the necessary NSView subclass to fix the OSX + Java 1.7 issue either tomorrow night or Thursday night.
I obviously can't stop you if you're hell-bent on fixing it, but it would be greatly appreciated on this end of the keyboard if you leave it to me.
moderator removed references to #lwjgl issue, to prevent further derailment of thread
Heavy moderation
Thread was being completely derailed - split into two. Lets keep this one on OSX / Java 7
Quote from: EmuMog on August 21, 2012, 22:38:45
abcdef, I hate to ask this, but I was contracted about two months ago to both update the Minecraft renderer as well as fix LWJGL on OSX + Java 1.7. For the past couple months I've been concentrating on the renderer itself, but I was literally going to be banging out the necessary NSView subclass to fix the OSX + Java 1.7 issue either tomorrow night or Thursday night.
This sounds good, is the canvas implementation going to be fixed as well? The main window sounds like the easy part :)
EmuMog
Totally happy with you doing the work :)
I've been on holiday the last week so haven't made any progress apart from looking at the code and thinking about what would need to be done.
Happy to test after you make the changes though
I saw on the RSS feed that you has some issues building things? I can help you out there if you are still having trouble.
EmuMog
As you have probably seen there hasn't been much done on the mac osx code for a while, I guess it worked so no one fixed it before. But a good chance to upgrade everything a bit, hope your development work is going well.
Just in case I thought I would give you a dump of everything I did (which isn't much as you can see)
How are you getting on? I appreciate you are doing this for the minecraft community but there are still quite a few people outside of that who will benefit greatly and are looking forward to you making the changes.
This is build.xml I used to compile things
<project name="OS X Native code" basedir="../../bin/lwjgl" default="nativelibrary">
<property name="native" location="../../src/native"/>
<target name="init">
<mkdir dir="i386"/>
<mkdir dir="x86_64"/>
</target>
<target name="clean">
<delete failonerror="false">
<fileset dir="i386"/>
<fileset dir="x86_64"/>
<fileset dir="." includes="liblwjgl.jnilib"/>
<fileset dir="." includes="lwjgl.symbols"/>
</delete>
</target>
<target name="compile">
<apply dir="${dstdir}" executable="${compiler}" os="Mac OS X" skipemptyfilesets="true" failonerror="true" dest="${dstdir}">
<arg line="${cflags} -ObjC -O2 -Wall -Wunused -c -fPIC -I${native}/common -I${native}/common/opengl -I${native}/macosx -I/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/Headers -I/System/Library/Frameworks/JavaVM.framework/Headers -framework AppKit -framework OpenGL -framework CoreFoundation -framework Carbon"/>
<!-- Map from *.m and *.c to .o -->
<mapper type="regexp" from="^(.*)\.(c|m)" to="\1.o"/>
<fileset dir="${native}/macosx" includes="*.m"/>
<fileset dir="${native}/macosx" includes="*.c"/>
<fileset dir="${native}/common" includes="*.c"/>
<fileset dir="${native}/common/opengl" includes="*.c"/>
<fileset dir="${native}/generated/openal" includes="*.c"/>
<fileset dir="${native}/generated/opencl" includes="*.c"/>
<fileset dir="${native}/generated/opengl" includes="*.c"/>
</apply>
</target>
<target name="link">
<apply dir="${objdir}" parallel="true" executable="${linker}" os="Mac OS X" failonerror="true" skipemptyfilesets="true">
<arg line="${linkerflags} -exported_symbols_list ../lwjgl.symbols -dynamiclib -o ${libname} -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework /JavaNativeFoundation -framework AppKit -framework JavaVM -framework OpenGL -framework CoreFoundation"/>
<fileset dir="${objdir}" includes="*.o"/>
</apply>
<apply dir="${objdir}" executable="strip" os="Mac OS X" failonerror="true">
<arg line="-S -X"/>
<fileset dir="." file="${libname}"/>
</apply>
</target>
<target name="nativelibrary" depends="init">
<antcall target="compile">
<param name="dstdir" location="i386"/>
<param name="compiler" value="gcc"/>
<param name="cflags" value="-arch i386 -mmacosx-version-min=10.6"/>
</antcall>
<antcall target="compile">
hfskhj
<param name="dstdir" location="x86_64"/>
<param name="compiler" value="gcc"/>
<param name="cflags" value="-arch x86_64 -mmacosx-version-min=10.6"/>
</antcall>
<exec vmlauncher="true" executable="sh" output="lwjgl.symbols" failonerror="true">
<arg path="../../platform_build/macosx_ant/build-symbol-list"/>
<arg path="i386"/>
</exec>
<antcall target="link">
<param name="objdir" location="i386"/>
<param name="libname" value="liblwjgl-i386.jnilib"/>
<param name="linker" value="gcc"/>
<param name="linkerflags" value="-arch i386 -mmacosx-version-min=10.6"/>
</antcall>
<antcall target="link">
<param name="objdir" location="x86_64"/>
<param name="libname" value="liblwjgl-i86_64.jnilib"/>
<param name="linker" value="gcc"/>
<param name="linkerflags" value="-arch x86_64 -mmacosx-version-min=10.6"/>
</antcall>
<apply dir="." parallel="true" executable="lipo" os="Mac OS X" failonerror="true" skipemptyfilesets="true" >
<arg value="-create"/>
<srcfile/>
<arg value="-output"/>
<arg path="liblwjgl.jnilib"/>
<fileset file="i386/liblwjgl-i386.jnilib"/>
<fileset file="x86_64/liblwjgl-i86_64.jnilib"/>
</apply>
</target>
</project>
and this is the change I made to org_lwjgl_opengl_Display.m (just made a change to one function which is listed). Change was made as cocoa didn't have back wards compatability on the carbon function.
JNIEXPORT void JNICALL Java_org_lwjgl_opengl_MacOSXDisplay_nHideUI(JNIEnv *env, jobject this, jboolean hide) {
if (hide == JNI_TRUE) {
[NSApp setPresentationOptions:NSApplicationPresentationAutoHideDock];
} else {
[NSApp setPresentationOptions:NSApplicationPresentationDefault];
}
}
By way of update, work on the OS X Cocoa rewrite seems to be going well and reached a point where with the changes LWJGL is now able to run on OS X 10.6+ (including Java 7 and OS X Mountain Lion 10.8 ).
Support for the PowerPC architecture, OS X 10.3 and 10.4 will be dropped as they are pretty old and insignificant now (will also allow removing some of the legacy code and hacks needed to support those and make the binaries smaller). However we need to come to a consensus on whether to continue to support OS X Leopard 10.5?
Some effort will be required to make and maintain LWJGL's Cocoa port on OS X 10.5 e.g. Objective-C there lacks some new language features, Cocoa lacks some of the newer API's, pain to compile as the 10.5 SDK is not easily available on newer OS X's, etc. Leopards market share seems to be dropping quickly (current stats say its about 10% of all OS X installs) and will continue to drop as it gets older and also because its now unsupported by Apple. However don't think it should be dropped if a significant number of users are still using it or need it.
Great news :D
In terms of 10.5 I'd look at the market share of the different versions of OS X and make a decision based on that:
OS Market Share (http://www.statowl.com/operating_system_market_share_by_os_version.php?limit%5B%5D=windows&limit%5B%5D=mac&limit%5B%5D=linux)
Good news indeed!
Are the changes in the nightlies yet? I'd be interested in doing some testing.
Quote from: thebattlebard on August 31, 2012, 12:03:58
Great news :D
In terms of 10.5 I'd look at the market share of the different versions of OS X and make a decision based on that:
OS Market Share (http://www.statowl.com/operating_system_market_share_by_os_version.php?limit%5B%5D=windows&limit%5B%5D=mac&limit%5B%5D=linux)
Indeed, still a good 15% of Mac users on that chart are on 10.5.x - too high to just drop support. When it gets under 5% that'll be the time.
Cas :)
Quote from: princec on August 31, 2012, 12:54:07
Indeed, still a good 15% of Mac users on that chart are on 10.5.x - too high to just drop support. When it gets under 5% that'll be the time.
Cas :)
According to those stats:
- Leopard was
14.39% of all OS X installs back in March 2012.
- Last month, July 2012 it was down to only
11.37%.
If you look at the Leopard market share trend for the last year (http://goo.gl/NpRJh) from the same stats, you'll notice Leopards market share is dropping at a rapid and constant rate (was
21.21% back in August 2011). Its likely this trend will continue and its market share will be <5% in just a few months.
Another source here (http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10) has Leopards last months market share at
10.4% and also confirms the constant and steep loss of market share here (http://www.netmarketshare.com/report.aspx?qprid=11&qpaf=&qpcustom=Mac+OS+X+10.5&qpcustomc=2).
Also another thing to consider, princec mentioned earlier in this thread that Steam requires OS X 10.5.8+ as a minimum, so out of those OS X 10.5 installs above if we look at the version break down here (http://goo.gl/djfMy), only 71% of those Leopard installs are on 10.5.8+ (considering that update was released 3 years ago, its unlikely the current user base will be updating), so we can knock of another 1/3 of the above market share bringing the roughly
10% market share down to about
7%. You could go further on that 7% figure and consider how many of those Mac users will actually be using a 5 year old Mac OS for gaming, I'm guessing it should put it below 5% (matching this (http://lwjgl.org/forum/index.php/topic,4711.msg25314.html#msg25314)stat) :).
Further news stories like this (http://www.theinquirer.net/inquirer/news/2202058/one-out-of-10-apple-mac-pcs-is-running-mountain-lion?WT.rss_f=Home&WT.rss_a=One+out+of+10+Apple+Mac+PCs+is+running+Mountain+Lion)(1 in 10 macs already on latest OS X 10.8, released just 37 days ago ) show mac users upgrade pretty quickly (compared to windows) especially due to the cheap price of the upgrade.
I don't know about the new code but the old code (to get it to compile) only had
JNIEXPORT void JNICALL Java_org_lwjgl_opengl_MacOSXDisplay_nHideUI(JNIEnv *env, jobject this, jboolean hide) {
if (hide == JNI_TRUE) {
[NSApp setPresentationOptions:NSApplicationPresentationAutoHideDock];
} else {
[NSApp setPresentationOptions:NSApplicationPresentationDefault];
}
}
which needed 10.6. The question is are there any functions used in the rewrite which require cocoa on 10.6 (Cocoa works on 10.5 fine but some api now is not backwards compatible to 10.5). And if there are (like the one above) is there a way around it.
Great news! :)
Thanks for your hard work guys!
If it's bound to be less than 5% in a few months you might aswell drop support now. Will we see this in the nightly builds soon? I can test it out on 10.6, 10.7 and 10.8 if needed.
Many thanks to everyone who helped out! I was dreading having to port my entire game to some other language/library :P
Hi all, just figured I'd give a quick status update. Hopefully I can get this stuff into the nightlies within the next week, tops, as I have Minecraft working again with no flickering (but also no resizing or keyboard support yet, as I haven't plumbed it yet) on OSX + Java 7 + latest LWJGL, so this should bode well.
To add some clarification, as much as I would like to add native support for rendering to a component in a window, at the moment I'm leaving parent-based rendering plumbed to AWT. This is because I haven't yet worked out a good way of rendering into a window that has a canvas without experiencing the AWT-side issues that made me writing this native code a necessity in the first place. Hopefully I can nail that down, as ideally Mojang want to still be able to use the Applet rendering mode for embedding Minecraft in browser pages, but worst case they could spawn a new window to house the game.
Changes made so far:
- Created a new native NSOpenGLView-derived class for managing the GL context and native input as opposed to AWT input.
- Created two new Java classes: MacOSXNativeKeyboard and MacOSXNativeMouse, used for receiving input events from a native window rather than an AWT component. This is more consistent with the functionality on Linux and Windows.
- Plumbed MacOSXNativeMouse, currently works well enough to get in-game in Minecraft and look around, but mouse grabbing is still slightly ugly and doesn't hide the cursor.
- New native-side JNI calls for window management rather than using AWT
- New native-side JNI calls for mouse/keyboard management rather than using AWT
It's been slightly slow going at the moment as I hadn't quite expected AWT to have its tentacles entwined so deeply in the OSX side of things, plus I'm working a full time day job as a software engineer, but again with any luck I should have this ironed out within a week's time, probably less.
Quote from: EmuMog on August 31, 2012, 19:34:31
Changes made so far:
- Created a new native NSOpenGLView-derived class for managing the GL context and native input as opposed to AWT input.
- Created two new Java classes: MacOSXNativeKeyboard and MacOSXNativeMouse, used for receiving input events from a native window rather than an AWT component. This is more consistent with the functionality on Linux and Windows.
- Plumbed MacOSXNativeMouse, currently works well enough to get in-game in Minecraft and look around, but mouse grabbing is still slightly ugly and doesn't hide the cursor.
- New native-side JNI calls for window management rather than using AWT
- New native-side JNI calls for mouse/keyboard management rather than using AWT
- MacOSXNativeMouse prettied up, now hides the cursor and doesn't have a weird delta issue when grabbing the cursor.
- Keyboard hooked up, Minecraft at least is now playable.
- Window resizing fixed up, no longer freaks out when resizing the window. Looks glitchy, but I suspect that' GL's fault.
Also, interestingly enough, my changes do seem to work well enough for applet mode to work with my new code. Rather than using a custom-built version of Minecraft that doesn't use Display.setParent, I used stock vanilla, and it still seems to work. Hopefully I can get the Mojang guys to set up a test page that embeds the game and supplies my fixed JARs so I can test in-browser mode as well.
Oh nice, sounds like some awesome progress.
I'm not sure how you are handling the native fullscreen mode, but as you are in the flow of writing the Cocoa stuff, might be nice to also include support for the new OS X 10.7+ fullscreen API's as set out here (http://lwjgl.org/forum/index.php/topic,4671.msg25044.html), should make a nice addition for OS X Lion and above.
Good work EmuMog! :)
I've gotten machines ready with 10.6, 10.7 and 10.8 ready to test with whenever everything is added to the nightlies.
Hi
Any updates on when the fixes will be in the nightly builds?
Thanks
Quote from: abcdef on September 13, 2012, 19:32:48
Hi
Any updates on when the fixes will be in the nightly builds?
Thanks
Just asked him on IRC a second ago.
[Sunday 09:26:41 pm] <UltraMoogleMan> <+ShaRose> actually, curious UltraMoogleMan, I saw someone asking about the osx lwjgl update in the lwjgl channel a while ago since you hadn't given any updates on the thread since... the 2nd
[Sunday 09:27:03 pm] <UltraMoogleMan> I spent the past week working on the renderer re-write, but I'm currently trying to solve two issues before I commit
[Sunday 09:27:17 pm] <UltraMoogleMan> One is that when you go fullscreen, then un-fullscreen, resizing stops working
[Sunday 09:27:26 pm] <UltraMoogleMan> The other is that trying to go fullscreen will crash 10-20% of the timeSo there you go.
I'm on the edge of my seat :) Seriously! I got my first "Waaaahh! Doesn't work on OSX 10.8" support email the other day, the first of many :S
Cas :)
LWJGL does work on 10.8, you just need to use the Java 6 JRE (The one apple provides) which you can download from the apple website. Would be good though to have a java 7 compatible one too
Aye - I'd really like to move to JDK7 for Mac so I can embed it (and thus not rely on any further downloading). Not to mention a few spiffy new Java 7 features I rather enjoy using!
Cas :)
Any news?
Cas :)
yeah ... poke and stuff ... would like to get this in the next release, preferably before the cert expires ...
This gets important now. Latest OSX update disabled all apple java for the browser. This means when people encounter a java applet they will have to use Java7, they will even be automatically redirected.
When you have the JDK7 installed the only "obvious" way to revert to Java6 as default is to remove the JDK7 folder as the "Java Settings" app is gone as well :/ I have all my java apps incl. NetBeans, the jMonkeyEngine SDK etc. start on Java7 now t.t
Quote from: normen on October 17, 2012, 00:26:15
When you have the JDK7 installed the only "obvious" way to revert to Java6 as default is to remove the JDK7 folder as the "Java Settings" app is gone as well :/ I have all my java apps incl. NetBeans, the jMonkeyEngine SDK etc. start on Java7 now t.t
I installed the Lion security update (Java for OS X 2012-006) and discovered that the applet plugin disabled AND removed! The only way to get lwjgl applets to work again is to revert to 1.6.0.35 or lower. Not an easy task, but I downloaded
Java for OS X Lion Update 1 - http://support.apple.com/kb/DL1421 (http://support.apple.com/kb/DL1421)
which is 1.6.0_29, and extracted the JavaAppletPlugin.plugin to /System/Library/Java/Support/CoreDeploy.bundle/Contents/JavaAppletPlugin.plugin using Pacifist. Now works again, for me.
Criminy, sorry to disappear like that, life's been incredibly hectic lately.
Okay, so, the only two remaining issues (that I know of based on my limited testing) are:
1) In Minecraft at least, when you start the game, then go fullscreen, then go back to windowed mode, resizing no longer appears to work.
2) In Minecraft, when you go fullscreen, the menu bar and dock do not disappear.
I've been having a heck of a time trying to fix those two issues, and would love any insight any other OS X folks can provide into:
- The above two issues
- Bug reports when running other games / applications, preferably games that I too can obtain for the purposes of fixing said bug reports.
- General code review, specifically ignoring dead code / the large amount of printfs still present in the code, as I'm planning on doing a final beautification pass once issues #1 and #2 are ironed out. More interested in hearing if there are better ways of doing things, etc.
And here are the downloads:
LWJGL JARs: https://dl.dropbox.com/u/28008537/jars.zip
LWJGL natives for OS X: https://dl.dropbox.com/u/28008537/natives.zip
LWJGL source archive, includes both modified and unmodified files: https://dl.dropbox.com/u/28008537/src.zip
Thanks in advance!
Thanks, when using this for jMonkeyEngine3, I get a native crash with no traceable stack:
Thread 27 Crashed:: Java: LWJGL Renderer Thread
0 liblwjgl.jnilib 0x000000011482f7bb Java_org_lwjgl_opengl_MacOSXContextImplementation_nCreate + 235
1 ??? 0x0000000106fa3eee 0 + 4412030702
2 ??? 0x0000000106f989b3 0 + 4411984307
3 ??? 0x0000000106f98e8d 0 + 4411985549
4 ??? 0x0000000106f9885a 0 + 4411983962
5 ??? 0x0000000106f9885a 0 + 4411983962
6 ??? 0x0000000106f9885a 0 + 4411983962
7 ??? 0x0000000106f98d34 0 + 4411985204
8 ??? 0x0000000106f93438 0 + 4411962424
9 libclient64.dylib 0x000000010657afa2 0x1064e4000 + 618402
10 libclient64.dylib 0x000000010658702c 0x1064e4000 + 667692
11 libclient64.dylib 0x0000000106586f22 0x1064e4000 + 667426
12 libclient64.dylib 0x0000000106586ec2 0x1064e4000 + 667330
13 libclient64.dylib 0x0000000106586d64 0x1064e4000 + 666980
14 libclient64.dylib 0x0000000106586b79 0x1064e4000 + 666489
15 libclient64.dylib 0x00000001064f75ea 0x1064e4000 + 79338
16 libsystem_c.dylib 0x00007fff8f867742 _pthread_start + 327
17 libsystem_c.dylib 0x00007fff8f854181 thread_start + 13
Thread 25 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x00007fabd22206d0 rcx: 0x00007fabd22206d0 rdx: 0x00007fabd403a200
rdi: 0x0000000000000103 rsi: 0x0000010000000100 rbp: 0x000000010e126750 rsp: 0x000000010e126720
r8: 0x0000000000012068 r9: 0x000000010e126680 r10: 0x00000000000010bc r11: 0x0000000000000000
r12: 0x00007fabd1423bb0 r13: 0x00007fabd210aa40 r14: 0x00007fabd4907648 r15: 0x00007fabd60251d0
rip: 0x000000010e13c7bb rfl: 0x0000000000010202 cr2: 0x0000000000000028
Logical CPU: 3
:(
System:
OSX 10.8.2 (latest) / MacBook Pro Mid 2010 Core i7 / NVidia GeForce 330M
Java:
Oracle JDK 7u6
Hi EmuMog, thanks for the update. I've tried it out with Mountain Lion, Java 7 Update 9 and get a similar crash with nothing in the Java console:
Thread 23 Crashed:: Java: AWT-EventQueue-2
0 libsystem_kernel.dylib 0x00007fff8c15f212 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff8c095af4 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff8c0d9dce abort + 143
3 libjvm.dylib 0x00000001074f4073 os::abort(bool) + 25
4 libjvm.dylib 0x00000001075e282e VMError::report_and_die() + 2306
5 libjvm.dylib 0x00000001074f5767 JVM_handle_bsd_signal + 1073
6 libsystem_c.dylib 0x00007fff8c0828ea _sigtramp + 26
7 liblwjgl.jnilib 0x00000001569d07bb Java_org_lwjgl_opengl_MacOSXContextImplementation_nCreate + 235
8 ??? 0x0000000107dcdf90 0 + 4426882960
9 ??? 0x0000000107dc2333 0 + 4426834739
10 ??? 0x0000000107dc29e1 0 + 4426836449
11 ??? 0x0000000107dc2158 0 + 4426834264
12 ??? 0x0000000107dc2158 0 + 4426834264
13 ??? 0x0000000107dc2158 0 + 4426834264
14 ??? 0x0000000107dc2158 0 + 4426834264
15 ??? 0x0000000107dc2158 0 + 4426834264
16 ??? 0x0000000107dc2158 0 + 4426834264
17 ??? 0x0000000107dc2806 0 + 4426835974
18 ??? 0x0000000107dc2158 0 + 4426834264
19 ??? 0x0000000107dc2158 0 + 4426834264
20 ??? 0x0000000107dc2158 0 + 4426834264
21 ??? 0x0000000107dc2158 0 + 4426834264
22 ??? 0x0000000107dc2333 0 + 4426834739
23 ??? 0x0000000107dbc4f7 0 + 4426810615
24 libjvm.dylib 0x00000001073c793f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
25 libjvm.dylib 0x00000001073c770c JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
26 libjvm.dylib 0x00000001074027c3 JVM_DoPrivileged + 560
27 ??? 0x0000000107dcdf90 0 + 4426882960
28 ??? 0x0000000107dc2333 0 + 4426834739
29 ??? 0x0000000107dc2333 0 + 4426834739
30 ??? 0x0000000107dc29e1 0 + 4426836449
31 ??? 0x0000000107dc2333 0 + 4426834739
32 ??? 0x0000000107dbc4f7 0 + 4426810615
33 libjvm.dylib 0x00000001073c793f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
34 libjvm.dylib 0x00000001073c770c JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
35 libjvm.dylib 0x00000001074027c3 JVM_DoPrivileged + 560
36 ??? 0x0000000107dcdf90 0 + 4426882960
37 ??? 0x0000000107dc2333 0 + 4426834739
38 ??? 0x0000000107dc29e1 0 + 4426836449
39 ??? 0x0000000107dc2158 0 + 4426834264
40 ??? 0x0000000107dc2158 0 + 4426834264
41 ??? 0x0000000107dc2158 0 + 4426834264
42 ??? 0x0000000107dc2158 0 + 4426834264
43 ??? 0x0000000107dc2158 0 + 4426834264
44 ??? 0x0000000107dc2158 0 + 4426834264
45 ??? 0x0000000107dbc4f7 0 + 4426810615
46 libjvm.dylib 0x00000001073c793f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
47 libjvm.dylib 0x00000001073c7e1c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256
48 libjvm.dylib 0x00000001073c7f56 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74
49 libjvm.dylib 0x00000001073fe8d0 thread_entry(JavaThread*, Thread*) + 169
50 libjvm.dylib 0x00000001075b7694 JavaThread::thread_main_inner() + 134
51 libjvm.dylib 0x00000001075b8b7a JavaThread::run() + 440
52 libjvm.dylib 0x00000001074f4595 java_start(Thread*) + 173
53 libsystem_c.dylib 0x00007fff8c094742 _pthread_start + 327
54 libsystem_c.dylib 0x00007fff8c081181 thread_start + 13
@EmuMog and @norman might be useful to also post the Arch (32bit, 64bit), OS X version and Java version you are using to try narrow down if the above crashes happen only on certain configurations of mac.
Running the org.lwjgl.test.WindowCreationTest on my MacPro4,1 with OS X 10.8.2 (12C60) using an ATI Radeon HD 5870 1024 MB graphics card crashes when pressing Shift-F. It crashes with 1.6 and 1.7.
With Java 1.6:
java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-12A269)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
I get this after pressing Shift-F:
java -cp lwjgl_test.jar:lwjgl.jar:lwjgl_util.jar -Djava.library.path=../native/macosx/ org.lwjgl.test.WindowCreationTest
The following keys are available:
ESCAPE: Exit test
ARROW Keys: Move window when in non-fullscreen mode
L: List selectable display modes
0-8: Selection of display modes
F: Toggle fullscreen
SHIFT-F: Toggle fullscreen with Display.destroy()/create() cycle
Found 64 display modes
Problem retrieving mode with 640x480x24@-1
Problem retrieving mode with 800x600x24@-1
Problem retrieving mode with 1024x768x24@-1
Window handle is null
Resizeable
nCreate
setView
nMakeCurrent
Performing Display.destroy()/create() cycle
nReleaseCurrentContexta
clearDrawable
clearDrawable
nDestroy
Setting options
Setting options
Setting context
Non-default
2012-10-23 19:43:58.706 java[1639:2517] -[__NSCFType view]: unrecognized selector sent to instance 0x7f8c114280a0
2012-10-23 19:43:58.707 java[1639:2517] unlockFocus called too many times. Called on <NSNextStepFrame: 0x7f8c12518ca0>.
2012-10-23 19:43:58.707 java[1639:2517] -[__NSCFType view]: unrecognized selector sent to instance 0x7f8c114280a0
nCreate
setView
nMakeCurrent
2012-10-23 19:43:58.711 java[1639:2517] (
0 CoreFoundation 0x00007fff969640a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff904f83f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff969fa6ea -[NSObject(NSObject) doesNotRecognizeSelector:] + 186
3 CoreFoundation 0x00007fff969525ce ___forwarding___ + 414
4 CoreFoundation 0x00007fff969523b8 _CF_forwarding_prep_0 + 232
5 liblwjgl.jnilib 0x0000000114e0dbd1 -[MacOSXOpenGLView lockFocus] + 81
6 AppKit 0x00007fff8dc844ec -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 963
7 AppKit 0x00007fff8dc84bb9 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 2704
8 AppKit 0x00007fff8dc827d2 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 817
9 AppKit 0x00007fff8ddd208b -[NSNextStepFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 286
10 AppKit 0x00007fff8dc7de4d -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 4675
11 AppKit 0x00007fff8dc47d73 -[NSView displayIfNeeded] + 1830
12 AppKit 0x00007fff8ddd1f44 -[NSNextStepFrame displayIfNeeded] + 84
13 AppKit 0x00007fff8dc472ac _handleWindowNeedsDisplayOrLayoutOrUpdateConstraints + 738
14 AppKit 0x00007fff8e212971 __83-[NSWindow _postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke_01208 + 46
15 CoreFoundation 0x00007fff9692a9b7 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
16 CoreFoundation 0x00007fff9692a921 __CFRunLoopDoObservers + 369
17 CoreFoundation 0x00007fff96905d88 __CFRunLoopRun + 728
18 CoreFoundation 0x00007fff969056b2 CFRunLoopRunSpecific + 290
19 HIToolbox 0x00007fff941730a4 RunCurrentEventLoopInMode + 209
20 HIToolbox 0x00007fff94172e42 ReceiveNextEventCommon + 356
21 HIToolbox 0x00007fff94172cd3 BlockUntilNextEventMatchingListInMode + 62
22 AppKit 0x00007fff8dc44613 _DPSNextEvent + 685
23 AppKit 0x00007fff8dc43ed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
24 libawt.jnilib 0x00000001135d4235 -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124
25 AppKit 0x00007fff8dc3b283 -[NSApplication run] + 517
26 libawt.jnilib 0x00000001135805f8 +[AWTStarter startAWT:] + 1495
27 libawt.jnilib 0x000000011357ff72 -[CPerformer perform] + 93
28 Foundation 0x00007fff91790677 __NSThreadPerformPerform + 225
29 CoreFoundation 0x00007fff968e3101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
30 CoreFoundation 0x00007fff968e2a25 __CFRunLoopDoSources0 + 245
31 CoreFoundation 0x00007fff96905dc5 __CFRunLoopRun + 789
32 CoreFoundation 0x00007fff969056b2 CFRunLoopRunSpecific + 290
33 java 0x00000001093ca843 java + 18499
34 java 0x00000001093ca29a java + 17050
35 java 0x00000001093c7a98 java + 6808
36 ??? 0x0000000000000005 0x0 + 5
)
With Java 1.7:
java -version
java version "1.7.0_05"
Java(TM) SE Runtime Environment (build 1.7.0_05-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)
Again pressing Shift-F - I get a VM crash:
java -cp lwjgl_test.jar:lwjgl.jar:lwjgl_util.jar -Djava.library.path=../native/macosx/ org.lwjgl.test.WindowCreationTest
The following keys are available:
ESCAPE: Exit test
ARROW Keys: Move window when in non-fullscreen mode
L: List selectable display modes
0-8: Selection of display modes
F: Toggle fullscreen
SHIFT-F: Toggle fullscreen with Display.destroy()/create() cycle
Found 1 display modes
Problem retrieving mode with 640x480x16@-1
Problem retrieving mode with 640x480x24@-1
Problem retrieving mode with 640x480x32@-1
Problem retrieving mode with 800x600x16@-1
Problem retrieving mode with 800x600x24@-1
Problem retrieving mode with 800x600x32@-1
Problem retrieving mode with 1024x768x16@-1
Problem retrieving mode with 1024x768x24@-1
Problem retrieving mode with 1024x768x32@-1
Window handle is null
Resizeable
nCreate
setView
nMakeCurrent
Performing Display.destroy()/create() cycle
nReleaseCurrentContexta
clearDrawable
clearDrawable
nDestroy
Setting options
Setting options
Setting context
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fff904ed39f, pid=1659, tid=140735265481088
#
# JRE version: 7.0_05-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.1-b03 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libobjc.A.dylib+0x639f] objc_msgSend_fixup+0x5f
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/void/Documents/Java/lwjgl/lwjgl-mac-osx-beta/jar/hs_err_pid1659.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Abort trap: 6
Here is the "hs_err_pid1659.log" for the last crash: http://pastebin.com/LdVYsinR (http://pastebin.com/LdVYsinR)
Ok, repeating the last test with a more recent version of Java 7:
java -version
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
Appears to work better but fullscreen still does not work (I'll get a window without a border in the left bottom corner of the screen when I press 'F') and still it crashes when I keep pressing 'F' a couple of times:
java -cp lwjgl_test.jar:lwjgl.jar:lwjgl_util.jar -Djava.library.path=../native/macosx/ org.lwjgl.test.WindowCreationTest
The following keys are available:
ESCAPE: Exit test
ARROW Keys: Move window when in non-fullscreen mode
L: List selectable display modes
0-8: Selection of display modes
F: Toggle fullscreen
SHIFT-F: Toggle fullscreen with Display.destroy()/create() cycle
Found 96 display modes
Problem retrieving mode with 640x480x24@-1
Problem retrieving mode with 800x600x24@-1
Problem retrieving mode with 1024x768x24@-1
Window handle is null
Resizeable
nCreate
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Setting context
Non-default
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Resizeable
Setting context
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Setting context
Non-default
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Resizeable
Setting context
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Setting context
Non-default
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Resizeable
Setting context
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Setting context
Non-default
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Resizeable
Setting context
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Setting context
Non-default
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Resizeable
Setting context
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Setting context
Non-default
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Resizeable
Setting context
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Setting context
Non-default
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Resizeable
Setting context
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Setting context
Non-default
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Resizeable
Setting context
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Setting context
Non-default
setView
nMakeCurrent
nReleaseCurrentContexta
clearDrawable
Setting options
Setting options
Resizeable
Setting context
2012-10-23 20:31:19.453 java[509:1107] An uncaught exception was raised
2012-10-23 20:31:19.454 java[509:1107] *** Collection <__NSSetM: 0x7f911905f3c0> was mutated while being enumerated.
2012-10-23 20:31:19.456 java[509:1107] (
0 CoreFoundation 0x00007fff9a84a0a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff943de3f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff9a8ddf98 __NSFastEnumerationMutationHandler + 232
3 AppKit 0x00007fff91af595e -[NSView trackingAreas] + 254
4 AppKit 0x00007fff91bdc35b -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 96
5 AppKit 0x00007fff91be58f5 -[NSFrameView _windowChangedKeyState] + 93
6 AppKit 0x00007fff91be538e -[NSWindow _setFrameNeedsDisplay:] + 169
7 AppKit 0x00007fff91be9770 -[NSWindow becomeMainWindow] + 41
8 AppKit 0x00007fff91be3073 -[NSWindow _changeKeyAndMainLimitedOK:] + 830
9 AppKit 0x00007fff91be286b -[NSWindow _makeKeyRegardlessOfVisibility] + 104
10 AppKit 0x00007fff91be27c5 -[NSWindow makeKeyAndOrderFront:] + 25
11 liblwjgl.jnilib 0x000000017140f3a1 Java_org_lwjgl_opengl_MacOSXDisplay_nCreateWindow + 657
12 ??? 0x00000001065e3f90 0x0 + 4401807248
13 ??? 0x00000001065d8333 0x0 + 4401759027
14 ??? 0x00000001065d8806 0x0 + 4401760262
15 ??? 0x00000001065d8158 0x0 + 4401758552
16 ??? 0x00000001065d8158 0x0 + 4401758552
)
2012-10-23 20:31:19.456 java[509:1107] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSSetM: 0x7f911905f3c0> was mutated while being enumerated.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff9a84a0a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff943de3f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff9a8ddf98 __NSFastEnumerationMutationHandler + 232
3 AppKit 0x00007fff91af595e -[NSView trackingAreas] + 254
4 AppKit 0x00007fff91bdc35b -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 96
5 AppKit 0x00007fff91be58f5 -[NSFrameView _windowChangedKeyState] + 93
6 AppKit 0x00007fff91be538e -[NSWindow _setFrameNeedsDisplay:] + 169
7 AppKit 0x00007fff91be9770 -[NSWindow becomeMainWindow] + 41
8 AppKit 0x00007fff91be3073 -[NSWindow _changeKeyAndMainLimitedOK:] + 830
9 AppKit 0x00007fff91be286b -[NSWindow _makeKeyRegardlessOfVisibility] + 104
10 AppKit 0x00007fff91be27c5 -[NSWindow makeKeyAndOrderFront:] + 25
11 liblwjgl.jnilib 0x000000017140f3a1 Java_org_lwjgl_opengl_MacOSXDisplay_nCreateWindow + 657
12 ??? 0x00000001065e3f90 0x0 + 4401807248
13 ??? 0x00000001065d8333 0x0 + 4401759027
14 ??? 0x00000001065d8806 0x0 + 4401760262
15 ??? 0x00000001065d8158 0x0 + 4401758552
16 ??? 0x00000001065d8158 0x0 + 4401758552
)
libc++abi.dylib: terminate called throwing an exception
Abort trap: 6
:-\
Tested on OS X 10.6.6, Java 6, 64bit.
LWJGL's Gears Test works but on startup lots of error messages appear in the console http://pastebin.com/8VPLe22E possibly clues as to why it fails to startup on the macs above?, looks like native memory leaks also this message looks odd "Invalid memory access of location 0x18 rip=0x7fff8767d11c").
The gears test then continues to work fine (working native cocoa window, yay!) but when the window is closed it crashes with following exception http://pastebin.com/4sZeiTqt
Would it make sense to create a branch, so we can get more eyes on the code?
+1 for branch
Ok, more testing: Nifty works, yay! :D
Native mouse cursors are not supported? I get this Exception:
org.lwjgl.LWJGLException: Native cursors not supported
I've tried the MouseCreationTest to verify and it seems there is another native exception
java -cp lwjgl_test.jar:lwjgl.jar:lwjgl_util.jar -Djava.library.path=../native/macosx/ org.lwjgl.test.input.MouseCreationTest
Window handle is null
Resizeable
2012-10-25 23:44:24.258 java[1106:1107] An uncaught exception was raised
2012-10-25 23:44:24.259 java[1106:1107] *** Collection <__NSSetM: 0x7fb8fa8865d0> was mutated while being enumerated.
2012-10-25 23:44:24.260 java[1106:1107] (
0 CoreFoundation 0x00007fff8ee520a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff889e63f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8eee5f98 __NSFastEnumerationMutationHandler + 232
3 AppKit 0x00007fff860fd95e -[NSView trackingAreas] + 254
4 AppKit 0x00007fff861e435b -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 96
5 AppKit 0x00007fff861ed8f5 -[NSFrameView _windowChangedKeyState] + 93
6 AppKit 0x00007fff861ed38e -[NSWindow _setFrameNeedsDisplay:] + 169
7 AppKit 0x00007fff861ea86b -[NSWindow _makeKeyRegardlessOfVisibility] + 104
8 AppKit 0x00007fff861ea7c5 -[NSWindow makeKeyAndOrderFront:] + 25
9 liblwjgl.jnilib 0x000000016c8073a1 Java_org_lwjgl_opengl_MacOSXDisplay_nCreateWindow + 657
10 ??? 0x000000010374ff90 0x0 + 4352966544
)
2012-10-25 23:44:24.261 java[1106:1107] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSSetM: 0x7fb8fa8865d0> was mutated while being enumerated.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff8ee520a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff889e63f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8eee5f98 __NSFastEnumerationMutationHandler + 232
3 AppKit 0x00007fff860fd95e -[NSView trackingAreas] + 254
4 AppKit 0x00007fff861e435b -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 96
5 AppKit 0x00007fff861ed8f5 -[NSFrameView _windowChangedKeyState] + 93
6 AppKit 0x00007fff861ed38e -[NSWindow _setFrameNeedsDisplay:] + 169
7 AppKit 0x00007fff861ea86b -[NSWindow _makeKeyRegardlessOfVisibility] + 104
8 AppKit 0x00007fff861ea7c5 -[NSWindow makeKeyAndOrderFront:] + 25
9 liblwjgl.jnilib 0x000000016c8073a1 Java_org_lwjgl_opengl_MacOSXDisplay_nCreateWindow + 657
10 ??? 0x000000010374ff90 0x0 + 4352966544
)
libc++abi.dylib: terminate called throwing an exception
Abort trap: 6
A branch is a good step to finally getting this work completed too.
@EmuMog you mentioned that you wanted to run a final beautification pass on the code, if you could please do this, we can then branch the LWJGL SVN trunk and merge your changes into it.
We can then focus on ironing out the last issues, including applying patches/fixes from others, once stable enough we can merge the branch back into truck and get out a new LWJGL release.
For anyone wanting a version controlled option to EmuMog's zipped files, I've added EmuMog's source files to my unofficial lwjgl git mirror.
The branch with EmuMog's changes is:
https://github.com/mcunha/lwjgl/tree/macos-jr7
The only changes I've applied was removing the SVN property expansions present in the original source files that were provided.
Created branch for code: https://java-game-lib.svn.sourceforge.net/svnroot/java-game-lib/branches/osx-java7/
Applied 28008537/src.zip to branch.
EmuMog please PM me a sourceforge user name so I can give you write access.
Checked out branch, made some minor changes to allow it to compile, namely:-
Updated macosx_ant build.xml, removed PPC support, bumped the minimum OS X SDK for 32/64bit native to SDK 10.5. Commented out some code in Display.m that required SDK 10.7+, namely NSApplicationPresentationFullScreen, etc
Should be easier now for ppl to start hacking on it, fixing stuff and adding missing functionality. Just checkout and run build.xml to compile.
Fixed leaking memory issue by adding a NSAutoreleasePool to the nCreateWindow method in Display.m and a drain to nDestroyWindow.
There is still some elusive crash on exit bug which triggers on calling Display.destroy();
build for testing: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Hi
I noticed some code was checked into a branch which seems to support Mac & Java 7. I haven't had a chance to download it & build it yet. Is it in a usable state? If not, any idea when it might be or what's missing?
Thanks for the continued work on this, I was having no luck with the previous version (using VBOs, then getting a problem related to JAWT), so hopefully this branch will solve all my problems! :-)
Hi macdonag,
The code is still relatively fresh and unstable, although Emu's done a good job and completed the heavy lifting part, the PPC support has been dropped (making the natives smaller) and OS X 10.5 is the new minimum requirement, there still remains issues that need to be fixed and implemented. There are a few native crashes at the moment that need to be tracked down and fixed, some missing functionality needs to be added (e.g. native cursor support, etc) and to generally run tests on the API to find and fix calls so they all work as expected.
There are test builds above that you can download and try (do report back with how it goes) or you can check out the branch and hack at it to assist further.
I'm halfway through making a patch that adds the following to the build system:
- Detect if 10.6 SDK is available, and fallback to 10.7 if not. Building on 10.7+ will never have 10.6 SDK available [unless copied by hand by a developer from an old Snow Leopard install]
- Detect if gcc-4.2 still available, and fallbackk to just "gcc" if not. Snow Leopard and above dropped gcc-4.2 and they're not available on fresh installs.
Hopefully this will be covered by mc78's fixes, but I got the following error trying to build on 10.8.2:
/Users/graham/Documents/Code/svn/java-game-lib/LWJGL/build.xml:478: The following error occurred while executing this line:
/Users/graham/Documents/Code/svn/java-game-lib/LWJGL/build.xml:511: The following error occurred while executing this line:
/Users/graham/Documents/Code/svn/java-game-lib/LWJGL/platform_build/macosx_ant/build.xml:59: The following error occurred while executing this line:
/Users/graham/Documents/Code/svn/java-game-lib/LWJGL/platform_build/macosx_ant/build.xml:22: Execute failed: java.io.IOException: Cannot run program "gcc-4.2" (in directory "/Users/graham/Documents/Code/svn/java-game-lib/LWJGL/bin/lwjgl/i386"): error=2, No such file or directory
Fixed a native crash on startup which should hopefully fix the above reported startup crashes. It was happening with Revenge of the Titans which I used for testing and debugging purposes, the game now runs on my setup mostly just as well as the stable version of LWJGL.
Latest test build: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Gave this a try just now, with Starfarer on OS X 10.6
Having some issues running Java 7 - getting: Symbol not found: _JNFRunLoopDidStartNotification
Referenced from: /Users/amosolov/starfarer/Starfarer.app/Contents/Home/lib/server/../libosxapp.dylib
That may be me doing something silly, and doesn't seem to be related to LWJGL (would appreciate any advice, though!)
Then I tried running the test build with Java 6 (should work, right?). That ran, but had a few issues (apologies if these are already known):
Mouse.getX() / Mouse.getY():
Once you press and hold down a mouse button, it returns the coordinates where the press originally happened, and doesn't update when you move the mouse. Once you release the button, the coordinates are still stuck on where the button was originally pressed until you move the mouse again, at which point it updates. This happens for both the left and right buttons.
Mouse.getDWheel() always returns 0.
Also got a segmentation fault on exit.
This is awesome, though - can't wait to be able to ship with Java 7. Although, for some reason, the JRE is 170 megs? Need to take a closer look to see why in the world it's so much bigger.
Using the libs in the zip, I get the following error trying to run TheQuadExampleColored.java (OSX 10.8.2):
Window handle is null
Resizeable
2012-11-03 21:25:55.226 java[9055:1703] An uncaught exception was raised
2012-11-03 21:25:55.227 java[9055:1703] *** Collection <__NSSetM: 0x7fa13b485c50> was mutated while being enumerated.
2012-11-03 21:25:55.228 java[9055:1703] (
0 CoreFoundation 0x00007fff8c58f0a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8f8d83f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8c622f98 __NSFastEnumerationMutationHandler + 232
3 AppKit 0x00007fff8d3d195e -[NSView trackingAreas] + 254
4 AppKit 0x00007fff8d4b835b -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 96
5 AppKit 0x00007fff8d4c18f5 -[NSFrameView _windowChangedKeyState] + 93
6 AppKit 0x00007fff8d4c138e -[NSWindow _setFrameNeedsDisplay:] + 169
7 AppKit 0x00007fff8d4c5770 -[NSWindow becomeMainWindow] + 41
8 AppKit 0x00007fff8d4bf073 -[NSWindow _changeKeyAndMainLimitedOK:] + 830
9 AppKit 0x00007fff8d4be86b -[NSWindow _makeKeyRegardlessOfVisibility] + 104
10 AppKit 0x00007fff8d4be7c5 -[NSWindow makeKeyAndOrderFront:] + 25
11 liblwjgl.jnilib 0x0000000164490e3a Java_org_lwjgl_opengl_MacOSXDisplay_nCreateWindow + 538
12 ??? 0x0000000108b51f90 0x0 + 4441055120
13 ??? 0x0000000108b46333 0x0 + 4441006899
14 ??? 0x0000000108b46806 0x0 + 4441008134
15 ??? 0x0000000108b46158 0x0 + 4441006424
16 ??? 0x0000000108b46158 0x0 + 4441006424
)
2012-11-03 21:25:55.228 java[9055:1703] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSSetM: 0x7fa13b485c50> was mutated while being enumerated.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff8c58f0a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8f8d83f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8c622f98 __NSFastEnumerationMutationHandler + 232
3 AppKit 0x00007fff8d3d195e -[NSView trackingAreas] + 254
4 AppKit 0x00007fff8d4b835b -[NSView(NSInternal) _enableOrDisableTrackingAreas] + 96
5 AppKit 0x00007fff8d4c18f5 -[NSFrameView _windowChangedKeyState] + 93
6 AppKit 0x00007fff8d4c138e -[NSWindow _setFrameNeedsDisplay:] + 169
7 AppKit 0x00007fff8d4c5770 -[NSWindow becomeMainWindow] + 41
8 AppKit 0x00007fff8d4bf073 -[NSWindow _changeKeyAndMainLimitedOK:] + 830
9 AppKit 0x00007fff8d4be86b -[NSWindow _makeKeyRegardlessOfVisibility] + 104
10 AppKit 0x00007fff8d4be7c5 -[NSWindow makeKeyAndOrderFront:] + 25
11 liblwjgl.jnilib 0x0000000164490e3a Java_org_lwjgl_opengl_MacOSXDisplay_nCreateWindow + 538
12 ??? 0x0000000108b51f90 0x0 + 4441055120
13 ??? 0x0000000108b46333 0x0 + 4441006899
14 ??? 0x0000000108b46806 0x0 + 4441008134
15 ??? 0x0000000108b46158 0x0 + 4441006424
16 ??? 0x0000000108b46158 0x0 + 4441006424
)
libc++abi.dylib: terminate called throwing an exception
I'm getting a similar hang when trying to run my game (JVM is 1.7.0_05-b06 and OS X 10.8.2) :
Window handle is null
Resizeable
Which occurs in my GLDisplay.create() call (requesting the core profile 3.2).
The furthest I can see down the stack trace (using a debug session):
main@1, prio=5, in group 'main', status: 'RUNNING'
at org.lwjgl.opengl.MacOSXDisplay.nCreateWindow(MacOSXDisplay.java:-1)
at org.lwjgl.opengl.MacOSXDisplay.createWindow(MacOSXDisplay.java:138)
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:794)
...
I'm not sure how to get the full stack trace, it's just strangely hanging when it reaches the error, even with a debug session attached, and I'm not getting any native stack frames ... hell, it's not even raising an exception, this is really odd.
Edit: Happy to test builds/nightlies/anything ... having LWJGL on JRE7 (especially now that 10.8.2 no longer offers easy switching) would be an insanely good thing and makes me wish I knew enough about OS X's windowing system to help.
Thanks for all the reports and testing. As way of summary from all the above information the following issues are outstanding:-
1) A native crash on exist when calling Display.destroy() on window close, happens in two locations nDestroyWindow method inside Display.m and nUnregisterMouseListenermethod inside method MacOSXNativeMouse.m.
2) Another native crash related to "Collection <__NSSetM: 0x7f911905f3c0> was mutated while being enumerated". A full exception reported here (http://lwjgl.org/forum/index.php/topic,4711.msg25622.html#msg25622) and again here (http://lwjgl.org/forum/index.php/topic,4711.msg25636.html#msg25636) and again here (http://lwjgl.org/forum/index.php/topic,4711.msg25682.html#msg25682).
3) Mouse.getDWheel() not yet implemented properly, there is working code in the source code inside Display.m in method scrollWheel. However this is currently implemented using OS X 10.7+ API's therefore commented out to allow compilation and compatibility on lower OS X versions.
4) When you go fullscreen, then go back to windowed mode, resizing no longer appears to work.
5) When you go fullscreen, the menu bar and dock do not disappear, there is some code in Display.m inside method nHideUI, however was using OS X 10.7 API's so was commented out to allow compilation and compatibility on lower OS X versions.
6) Native cursor support not yet implemented.
7) Mouse.getX() / Mouse.getY() not being properly polled when button is held down.
8 ) Clean up debug code (println's etc) once above is fixed.
9) Implement Display.getX() and Display.getY() to update on window move.
10) Mouse.setCursorPosition() doesn't set the mouse to the correct location.
@avm1979 As a guess to your Java 7 issue, from the information provided, it seems it can't find JNF (Java Native Foundation) a helper library by Apple, as far as I recall this wasn't included in earlier builds of Java 7 for OS X, not sure if they added it to newer Oracle Java 7 releases, maybe try a newer version of Java 7 (just curious, which version of Java 7 were you testing with?).
Hope the above is a helpful summary, especially for those wanting to have a go at trying to fix some of the above issues.
Quote from: kappa on November 04, 2012, 14:45:39
@avm1979 As a guess to your Java 7 issue, from the information provided, it seems it can't find JNF (Java Native Foundation) a helper library by Apple, as far as I recall this wasn't included in earlier builds of Java 7 for OS X, not sure if they added it to newer Oracle Java 7 releases, maybe try a newer version of Java 7 (just curious, which version of Java 7 were you testing with?).
$ ./java -version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)That looks to be the latest, as far as I can tell - downloaded the .tar.gz from Oracle yesterday. The .dmg doesn't support 10.6, says it requires OS X Lion (10.7) to install. I wonder if this means that Java 7 isn't supported on 10.6, period? Do you know if there's somewhere I can grab JNF to give it a try? Spent a while googling around for it, to no avail.
Quote from: avm1979 on November 04, 2012, 19:32:21
Quote from: kappa on November 04, 2012, 14:45:39
@avm1979 As a guess to your Java 7 issue, from the information provided, it seems it can't find JNF (Java Native Foundation) a helper library by Apple, as far as I recall this wasn't included in earlier builds of Java 7 for OS X, not sure if they added it to newer Oracle Java 7 releases, maybe try a newer version of Java 7 (just curious, which version of Java 7 were you testing with?).
$ ./java -version
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05)
Java HotSpot(TM) 64-Bit Server VM (build 23.5-b02, mixed mode)
That looks to be the latest, as far as I can tell - downloaded the .tar.gz from Oracle yesterday. The .dmg doesn't support 10.6, says it requires OS X Lion (10.7) to install. I wonder if this means that Java 7 isn't supported on 10.6, period? Do you know if there's somewhere I can grab JNF to give it a try? Spent a while googling around for it, to no avail.
Yeh IIRC, Java 7 will be OS X 10.7+ only so the system JRE's on OS X 10.5 and 10.6 will need to be used. JNF comes with Java 6 but don't think it'll work with Java 7 since Apple haven't released the code for it.
In any event, I had a look further into the LWJGL OS X code to see why JavaNativeFoundation was needed and found a few unused references to it, have removed them now, I'm guessing it should work now, please do test build below.
Latest test build: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Gave that a try - same thing, but looks like it's actually not being triggered from LWJGL. Sorry for not pasting the whole thing earlier.
Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/amosolov/starfarer/Starfarer.app/Contents/Home/lib/lwawt/liblwawt.dylib: dlopen(/Users/amosolov/starfarer/Starfarer.app/Contents/Home/lib/lwawt/liblwawt.dylib, 1): Symbol not found: _JNFRunLoopDidStartNotification
Referenced from: /Users/amosolov/starfarer/Starfarer.app/Contents/Home/lib/server/../libosxapp.dylib
Expected in: /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation
in /Users/amosolov/starfarer/Starfarer.app/Contents/Home/lib/server/../libosxapp.dylib
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1825)
at java.lang.Runtime.load0(Runtime.java:792)
at java.lang.System.load(System.java:1059)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1846)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1648)
at java.awt.Toolkit.<clinit>(Toolkit.java:1670)
at java.awt.Color.<clinit>(Color.java:275)
at com.fs.starfarer.StarfarerLauncher.<init>(Unknown Source)
at com.fs.starfarer.StarfarerLauncher.main(Unknown Source)
Thank you for clarifying about JNF. Seems kind of weird for Java to have a dependency like that, but oh well.
Oh it looks like its AWT that has dependencies on JNF (you have a launcher or something that uses it?). It would be expected for AWT on OS X since Apple use to maintain it. However what is odd is that they didn't include it with Java 7 and/or left the dependencies in there (maybe a Java 7 bug?).
In any event it was good you ran into the above issues as we've cleared out dependences on JNF from LWJGL because of it.
The JNF Framework with Oracle is a Framework within a Framework, in the build.xml you need to tell it the location. I had this working is some really early tests I did (before EMUMog started). I'm at work at the moment but I'll post something later showing how I fixed that issue.
Quote from: kappa on November 04, 2012, 21:36:22
Oh it looks like its AWT that has dependencies on JNF (you have a launcher or something that uses it?). It would be expected for AWT on OS X since Apple use to maintain it. However what is odd is that they didn't include it with Java 7 and/or left the dependencies in there (maybe a Java 7 bug?).
Yeah, a launcher, and java.awt.Color pretty much everywhere. If I can nuke the latter with some broad-spectrum search & replace, I'll bypass the launcher and try it again on 10.6 - curious to see if it can work, or if some other internal Java dependency on it will pop up.
Edit: Gave bypassing the launcher a try. This is the result:
java.lang.UnsatisfiedLinkError: /Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/lwawt/liblwawt.dylib: dlopen(/Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/lwawt/liblwawt.dylib, 1): Symbol not found: _JNFRunLoopDidStartNotification
Referenced from: /Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/server/../libosxapp.dylib
Expected in: /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation
in /Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/server/../libosxapp.dylib
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1825)
at java.lang.Runtime.load0(Runtime.java:792)
at java.lang.System.load(System.java:1059)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1846)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1648)
at java.awt.Toolkit.<clinit>(Toolkit.java:1670)
at org.lwjgl.MacOSXSysImplementation.<clinit>(MacOSXSysImplementation.java:49)
at org.lwjgl.Sys.createImplementation(Sys.java:130)
at org.lwjgl.Sys.<clinit>(Sys.java:111)
at com.fs.profiler.Profiler.<clinit>(Profiler.java:224)
at com.fs.starfarer.combat.CombatMain.main(CombatMain.java:88)So, looks like JNF is still required by something.
I should also add, as I don't think it's been mentioned, that the branch doesn't build on my machine. After I've changed the references to gcc-4.2 to gcc, and the references to the 10.6 SDK path to the 10.7 SDK path, I get the following errors:
[apply] /Users/graham/Documents/Code/svn/java-game-lib/LWJGL/src/native/macosx/org_lwjgl_opengl_MacOSXNativeKeyboard.m:47:50: error: org_lwjgl_opengl_MacOSXNativeKeyboard.h: No such file or directory
[apply] /Users/graham/Documents/Code/svn/java-game-lib/LWJGL/src/native/macosx/org_lwjgl_opengl_MacOSXNativeMouse.m:47:47: error: org_lwjgl_opengl_MacOSXNativeMouse.h: No such file or directory
If I remove the #imports, it seems to build correctly. (Though I then get the mutated collection during enumeration crash.) I'm building on 10.8.2.
Attaching my fixes for build.xml:
Adding support for:
- Xcode location discovery
- Mac OS SDK discovery
- JavaVM.framework discovery
- gcc vs gcc-4.2 discovery
mc78 really nice job, patch committed, keep them coming :)
@macdonag try now with the latest svn code it has mc78's patch applied.
@avm1979 thanks for continuing to test and provide updates, looking into the OS X implementation of LWJGL's Sys class, there was actually some old code in there that started the AWT Toolkit to work around a bug in OS X 10.3, removed it, hopefully there won't any be other dependancies on AWT when running just the native Display.
Latest build for testing: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Looks like Sys.alert still triggers AWT loading (that's probably expected, though):
Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/lwawt/liblwawt.dylib: dlopen(/Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/lwawt/liblwawt.dylib, 1): Symbol not found: _JNFRunLoopDidStartNotification
Referenced from: /Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/server/../libosxapp.dylib
Expected in: /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation
in /Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/server/../libosxapp.dylib
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1825)
at java.lang.Runtime.load0(Runtime.java:792)
at java.lang.System.load(System.java:1059)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1846)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.loadLibraries(Toolkit.java:1648)
at java.awt.Toolkit.<clinit>(Toolkit.java:1670)
at javax.swing.UIManager.getSystemLookAndFeelClassName(UIManager.java:608)
at org.lwjgl.J2SESysImplementation.alert(J2SESysImplementation.java:52)
at org.lwjgl.Sys.alert(Sys.java:208)
at com.fs.starfarer.combat.CombatMain.main(CombatMain.java:352)
Hmm. Tried getting a little further, and getting the same JNF dependency from various core Java classes - ImageIO, Preferences, etc. So, it's probably too much of a quagmire, trying to figure out which subset of Java isn't going to set it off.
Tried a more standalone test (a bit of test code for particle systems, creates a display and renders some stuff, doesn't do much else):
Exception in thread "main" java.lang.UnsatisfiedLinkError: /Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/lwawt/liblwawt.dylib: dlopen(/Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/lwawt/liblwawt.dylib, 1): Symbol not found: _JNFRunLoopDidStartNotification
Referenced from: /Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/server/../libosxapp.dylib
Expected in: /System/Library/Frameworks/JavaVM.framework/Versions/A/Frameworks/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation
in /Users/amosolov/starfarer/java7/jre1.7.0_09.jre/Contents/Home/lib/server/../libosxapp.dylib
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1825)
at java.lang.Runtime.load0(Runtime.java:792)
at java.lang.System.load(System.java:1059)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1939)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1864)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1846)
at java.lang.Runtime.loadLibrary0(Runtime.java:845)
at java.lang.System.loadLibrary(System.java:1084)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:67)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:47)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.CGraphicsEnvironment.<clinit>(CGraphicsEnvironment.java:61)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:186)
at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:102)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:81)
at org.lwjgl.opengl.MacOSXDisplay.getDevice(MacOSXDisplay.java:206)
at org.lwjgl.opengl.MacOSXDisplay.init(MacOSXDisplay.java:239)
at org.lwjgl.opengl.Display.<clinit>(Display.java:135)
at org.lwjgl.util.Display.getAvailableDisplayModes(Display.java:71)
at com.fs.graphics.LWJGL2DInitializer.setDisplayMode(LWJGL2DInitializer.java:116)
at com.fs.graphics.LWJGL2DInitializer.init(LWJGL2DInitializer.java:41)
at com.fs.starfarer.renderers.damage.ExplosionParticleSystem.main(ExplosionParticleSystem.java:224)
Well, the good news is it works with Java 6. Thank you for having taken the time to look into it.
This is what I have in the build.xml for the args in compile target for the JNF
<arg line="${cflags} -ObjC -O2 -Wall -Wunused -c -fPIC -I${native}/common -I${native}/common/opengl -I${native}/macosx -I/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaNativeFoundation.framework/Headers -I/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/include"/>
and in link
<arg line="${linkerflags} -exported_symbols_list ../lwjgl.symbols -dynamiclib -o ${libname} -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework /JavaNativeFoundation -L/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/jre/lib -l libjawt.dylib -framework AppKit -framework CoreFoundation -framework OpenGL"/>
@avm1979 hmm, seems like there are still a few AWT dependencies in LWJGL's OS X code (Sys.alert(), clipboard, obtaining available device resolution, etc), not a major problem as they can all eventually be replaced by equivalent Cocoa replacements, however its better to come back to this task later after we've sorted out some of the more serious issues (like the native crashes). In any event for now you should try to have a look at why JNF isn't being found by Java itself. A little online searching shows that JavaNativeFoundation is a required dependency for Oracles Java 7 on OS X, so you'll need it in any event, this snippet comment below says a bit more:
QuoteJavaNativeFoundation is only present in /System/Library/Frameworks/JavaVM.framework/Frameworks. There is no private copy in OpenJDK, and OpenJDK itself relies on the version in /System. It's full and proper Mac OS X API.
...
You shouldn't have any problems by just using the built-in system one. It's system API, just like Foundation and AppKit.
So do check your system, maybe you've moved this folder or something?
@abcdef - yup, those are used now in the build.xml
@mc78 - getting a warning with the new build.xml "[available] DEPRECATED - used to override an existing property." so might need a little tweaking to to use newer ANT api.
Also looking further into the JavaNativeFoundation situation, its actually a framework that we shouldn't try to avoid, its there to help make working with Cocoa easier and will make LWJGL's OS X code a lot cleaner and smaller. Its a dependency that Apple Java 6, OpenJDK7, Oracle Java 7 all also depend on so no real harm in using it.
I dropped the latest version into my app, and it's giving the following exception:
Process: java [5132]
Path: /usr/bin/java
Identifier: net.java.openjdk.cmd
Version: 1.0 (1.0)
Code Type: X86-64 (Native)
Parent Process: eclipse [2877]
User ID: 501
PlugIn Path: /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/jre/lib/server/libjvm.dylib
PlugIn Identifier: libjvm.dylib
PlugIn Version: ??? (1)
Date/Time: 2012-11-06 11:22:15.551 +0000
OS Version: Mac OS X 10.8.2 (12C60)
Report Version: 10
Interval Since Last Report: 170701 sec
Crashes Since Last Report: 8
Per-App Interval Since Last Report: 226 sec
Per-App Crashes Since Last Report: 6
Anonymous UUID: 777A5CFF-5023-3FFC-8172-15FDEF497E3C
Crashed Thread: 24 Java: AWT-EventQueue-1
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000028
VM Regions Near 0x28:
-->
__TEXT 000000010033b000-000000010034c000 [ 68K] r-x/rwx SM=COW /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/bin/java
Application Specific Information:
abort() called
......
Thread 24 Crashed:: Java: AWT-EventQueue-1
0 libsystem_kernel.dylib 0x00007fff8db39212 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff88b25af4 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff88b69dce abort + 143
3 libjvm.dylib 0x000000010081a073 os::abort(bool) + 25
4 libjvm.dylib 0x000000010090882e VMError::report_and_die() + 2306
5 libjvm.dylib 0x000000010081b767 JVM_handle_bsd_signal + 1073
6 libsystem_c.dylib 0x00007fff88b128ea _sigtramp + 26
7 liblwjgl.jnilib 0x00000001323c9596 Java_org_lwjgl_opengl_MacOSXContextImplementation_nCreate + 214
8 ??? 0x00000001010f3f90 0 + 4312743824
9 ??? 0x00000001010e8333 0 + 4312695603
10 ??? 0x00000001010e89e1 0 + 4312697313
11 ??? 0x00000001010e8158 0 + 4312695128
12 ??? 0x00000001010e8158 0 + 4312695128
13 ??? 0x00000001010e8158 0 + 4312695128
14 ??? 0x00000001010e8158 0 + 4312695128
15 ??? 0x00000001010e8158 0 + 4312695128
16 ??? 0x00000001010e8158 0 + 4312695128
17 ??? 0x00000001010e8806 0 + 4312696838
18 ??? 0x00000001010e8158 0 + 4312695128
19 ??? 0x00000001010e8158 0 + 4312695128
20 ??? 0x00000001010e8158 0 + 4312695128
21 ??? 0x00000001010e8158 0 + 4312695128
22 ??? 0x00000001010e8333 0 + 4312695603
23 ??? 0x00000001010e24f7 0 + 4312671479
24 libjvm.dylib 0x00000001006ed93f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
25 libjvm.dylib 0x00000001006ed70c JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
26 libjvm.dylib 0x00000001007287c3 JVM_DoPrivileged + 560
27 ??? 0x00000001010f3f90 0 + 4312743824
28 ??? 0x00000001010e8333 0 + 4312695603
29 ??? 0x00000001010e8333 0 + 4312695603
30 ??? 0x00000001010e89e1 0 + 4312697313
31 ??? 0x00000001010e8333 0 + 4312695603
32 ??? 0x00000001010e24f7 0 + 4312671479
33 libjvm.dylib 0x00000001006ed93f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
34 libjvm.dylib 0x00000001006ed70c JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
35 libjvm.dylib 0x00000001007287c3 JVM_DoPrivileged + 560
36 ??? 0x00000001010f3f90 0 + 4312743824
37 ??? 0x00000001010e8333 0 + 4312695603
38 ??? 0x00000001010e89e1 0 + 4312697313
39 ??? 0x00000001010e8158 0 + 4312695128
40 ??? 0x00000001010e8158 0 + 4312695128
41 ??? 0x00000001010e8158 0 + 4312695128
42 ??? 0x00000001010e8158 0 + 4312695128
43 ??? 0x00000001010e8158 0 + 4312695128
44 ??? 0x00000001010e8158 0 + 4312695128
45 ??? 0x00000001010e24f7 0 + 4312671479
46 libjvm.dylib 0x00000001006ed93f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
47 libjvm.dylib 0x00000001006ede1c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256
48 libjvm.dylib 0x00000001006edf56 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74
49 libjvm.dylib 0x00000001007248d0 thread_entry(JavaThread*, Thread*) + 169
50 libjvm.dylib 0x00000001008dd694 JavaThread::thread_main_inner() + 134
51 libjvm.dylib 0x00000001008deb7a JavaThread::run() + 440
52 libjvm.dylib 0x000000010081a595 java_start(Thread*) + 173
53 libsystem_c.dylib 0x00007fff88b24742 _pthread_start + 327
54 libsystem_c.dylib 0x00007fff88b11181 thread_start + 13
I suspect the native crashes are occurring because of threading issues between the JNI thread and the Cocoa thread (Thread-0). This is because the Cocoa calls are currently running on the JNI thread. Will have an attempt at trying to fixing it tonight.
@Kappa: yep, my bad, forgot Ant doesn't like property overrides. Patch below, it's uglier but keeps Ant happy. Also noticed the line endings for build.xml on the branch now are Mac OS which seems to break svn diff and regular diff too. Maybe convert to UNIX line endings ?
Patch adds:
- Only set build.xml properties once to keep Ant happy
- Print which gcc, JavaVM.framework and Mac OS SDK is used for Mac OS natives
Quote from: kappa on November 06, 2012, 11:55:24
I suspect the native crashes are occurring because of threading issues between the JNI thread and the Cocoa thread (Thread-0). This is because the Cocoa calls are currently running on the JNI thread. Will have an attempt at trying to fixing it tonight.
I'm inclined to agree. I built the latest code, and ran the coloured quad example (http://www.lwjgl.org/wiki/index.php?title=The_Quad_colored). It seems to crash with the mutated collection during enumeration problem most of the time, but occasionally it runs without any problems.
(Still got the missing header files problem I mentioned earlier though - are there some files that need to be checked in?)
Quote from: macdonag on November 06, 2012, 21:00:33
(Still got the missing header files problem I mentioned earlier though - are there some files that need to be checked in?)
I ran into that the first time i checked out but didn't see it again as I copied the headers over from emu's src files, anyway found the cause of the problem. The native headers for two classes weren't being generated, made the changes to the main lwjgl build.xml, latest svn code should compile for you now.
Also added mc78's latest build.xml changes to svn.
@kappa: Checked, looks like I have JNF where it should be (in /System/Library/Frameworks/JavaVM.framework/Frameworks). Not sure why it's not finding it, I'll poke around a bit more.
@avm1979: which version of Mac OS are you trying to compile on ? which version of XCode do you have installed ?
Unless you're running 10.6 or prior, you shouldn't be trying to link/compile against anything in /System/Library/Frameworks. The patch I made for build.xml addresses these issues. If it's not working for you, please share the result of your ant build as well as the results of running "xcode-select".
I will be travelling over the next few days, but I'll try to check these forums as I can.
Not trying to compile it myself - just trying to use the build kappa posted with Java 7, on OS X 10.6.
Quote from: kappa on November 06, 2012, 21:58:12
Quote from: macdonag on November 06, 2012, 21:00:33
(Still got the missing header files problem I mentioned earlier though - are there some files that need to be checked in?)
I ran into that the first time i checked out but didn't see it again as I copied the headers over from emu's src files, anyway found the cause of the problem. The native headers for two classes weren't being generated, made the changes to the main lwjgl build.xml, latest svn code should compile for you now.
Also added mc78's latest build.xml changes to svn.
I removed the files when I was checking in, because they were part of the standard autogenerated headers. Since I can't compile, I didn't notice this issue. Sorry about that.
Quote from: kappa on November 06, 2012, 00:26:31
mc78 really nice job, patch committed, keep them coming :)
@macdonag try now with the latest svn code it has mc78's patch applied.
@avm1979 thanks for continuing to test and provide updates, looking into the OS X implementation of LWJGL's Sys class, there was actually some old code in there that started the AWT Toolkit to work around a bug in OS X 10.3, removed it, hopefully there won't any be other dependancies on AWT when running just the native Display.
Latest build for testing: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Kappa this fixed the issue I was having with my Minecraft game crashing any time I opened a window. It was having some issues with the mouse pointer afterwards. I'll be running this version while playing and if I run into any crashes will let you know. Thanks everyone that has put time into this to fix these bugs as well as keep me from having to build the LWJGL source.
Found a bug if your app that is using the lib (minecraft in my case) locks the mouse into it, and you hit esc and get your mouse out of it, then alt+tab back into the application, it doesn't refocus your mouse to inside of the app. So when I try to click, it actually clicks OUTSIDE of the app. Let me know if I need to describe this better...
edit:Okay so that's not the only time the bug happens. Anytime I need to actually click on something in the app with my mouse pointer, my mouse ends up being WAY outside of my app on my other monitor.
edit2: Tiago on Mojang's Jira put it a lot better than I did.
"I only tried this in windowed mode, but it seems like the window sometimes loses focus of the mouse and I'm actually clicking other windows instead of the Minecraft window. Usually clicking outside of it and back again fixes it, but sometimes the mouse buttons stop performing any actions after this."
There is some difference in behavior. Minecraft on 'release of the cursor' does the following:
public void release() {
Mouse.setCursorPosition(parent.getWidth() / 2, parent.getHeight() / 2);
Mouse.setGrabbed(false);
}
I'm not exactly sure where it is going wrong, but it used to drop the cursor dead-center in your active window. According to the javadoc (http://lwjgl.org/javadoc/org/lwjgl/input/Mouse.html#setCursorPosition%28int,%20int%29) the x,y setCursorPosition uses should be relative to the origin to the window origin. From what I can see it now drops it relative to the desktop-origin (topleft).
More bug fixes in now, hopefully two more of the native crashes are fixed, one of the startup ones (the "Collection <__NSSetM: 0x7fa13b485c50> was mutated while being enumerated.") and another on exiting the app (although there is now a different crash on exit which only happen when using the red x close window button, can be silenced but better to fix the root cause once found).
Also implemented missing functionality on Display.getWidth() and Display.getHeight() calls as they were not updating on Display resize, special thanks to Grum for reporting, narrowing down the bug and helping with testing.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Quote from: kappa on November 11, 2012, 20:16:22
More bug fixes in now, hopefully two more of the native crashes are fixed, one of the startup ones (the "Collection <__NSSetM: 0x7fa13b485c50> was mutated while being enumerated.") and another on exiting the app (although there is now a different crash on exit which only happen when using the red x close window button, can be silenced but better to fix the root cause once found).
Been using it for the last hour or so, without any of the enumeration crashes - thank you very much!
Another update, cleaned/removed a lot of the redundant LWJGL OS X code left over from the previous implementation (thx @Grum for providing an initial patch diff).
Implemented missing mouse movement events when dragging the mouse with either the right mouse button or the other button (thx @avm1979 for spotting and reporting).
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Hi kappa, just tried this newest build.
Firstly, on Java 1.6_037 in Eclipse. When run as an application rather than an applet it worked in general, although the mouse scroll wheel didn't work. It did crash on exit though, crash report is attached. As an applet, it crashed on loading, report attached.
Then with Java 1.7_09 in Eclipse. When run as an application it worked apart from the scroll wheel. It also crashed on exit, report attached. When run as an applet it crashed on startup, report attached.
Let me know if you need any more info.
Thanks for testing, scroll wheel is currently intentionally disabled as it was using an OS X 10.7+ Cocoa API, but will be fixed soon, just a matter of plugging in the older OS X 10.5+ Cocoa scroll wheel API.
The crash on exit is also known (http://lwjgl.org/forum/index.php/topic,4711.msg25788.html#msg25788) but why it happens is still a mystery. It crashes in the native method 'lockFocus' when calling 'setView' inside Display.m (if you comment out that call it works fine and doesn't crash), this is because the method is called once the window is destroyed/closed as something is making another draw call. This only happens when the red x close button is pressed on the nswindow. The crash stack trace seems to suggest that [AWTStarter starter:] is what is calling the redraw once the close button is pressed, however don't see in the code where this is being started from, any idea's are appreciated (maybe some sort of AWT thread started automatically by the OS X JVM?).
As for applets, they won't currently function with the above builds, as the old applet code used to make them work has been removed. Focus is on getting the native Display stable first. Spasi is working on a new experimental offscreen drawing method for LWJGL 3.0, which we'll backport to re-add this AWT functionality in the LWJGL 2.9 release.
The latest build that kappa posted some days ago here works a lot better for me. I've not seen crashes anymore and I can actually close a LWJGL window with cmd+q without the window staying open hanging.
Basically I just want to say thanks and keep up to good work! It looks a lot better now! ;D
Tried the latest build, (14 Nov),
Still getting
"[info] Window handle is null
[info] Resizeable" output to my console and it pauses while trying to Display.create.
I've tried varies versions of Display.create, various pixel formats, and core/compat profiles, none make a difference
Running 1.7.0_09 this time.
Using JRE6 for this LWJGL build works fine (until a crash on close), so there doesn't appear to be anything deeply flawed with my setup.
Finally found and fixed the native crash on exit.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Hey kappa. I found a crash in OS X when trying to enter fullscreen. I was following the basic tutorials on the site and I was on the FullscreenExample one. Well anyways, when entering fullscreen it crashes and gives the error log I attached saying it is a crash in the native code.
I did some experimenting and I found that on rare occasions it enters a pseudo-fullscreen. It is like a window with no borders, anchored in the bottom left of screen, but only the size of which was specified, in my case 800x600. Another thing I tried was starting out in fullscreen which produced the same effect as just described every time. But when switching out of full screen and then back it would crash again.
Hope this helps
BTW I'm using Java SE 7 and Mountain Lion
@adamk33n3r - thanks for the crash log and detailed description, will have a look into that.
@kappa Ya hey no problem. I'm glad I can help.
Just an update. I tried it on Java 6 and it crashed as well
Alright, I worked out what was causing my crashes.
My problem was that I was creating my own java.awt.Canvas and Frame, and parenting them manually. I guess that means Diaply.setParent functionality has changed.
I've removed all that code (just letting LWJGL handle it), I'm creating the Display the straight forward way and I'm no longer getting any crashes.
I'll go about getting full screen, resizing and mouse grabbing working again and see how I go.
Hello everyone.
I work in the OpenJDK AWT team and I am looking at this bug currently:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169339 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169339)
However, as I see from this topic, you do not need anything from our side already as you've almost implemented all the functionality in Cocoa.
Is that true? Do you still need this functionality to be implemented or any other support from the JDK side?
Best, Petr Pchelko.
It appears progress is being made but it'd be great if you could work with us on any tweaks or fixes in this area.
Cas :)
@Petr Pchelko thanks for dropping by, we have indeed had to reimplement all the functionality for standalone applications in pure Cocoa (basically bypassing AWT) . We had used AWT as our windowing system for over 10 years, it worked well as we just grabbed the NSView of an AWT Canvas and stuck an OpenGL context on it.
Apple made changes when they moved to lightweight AWT widgets (starting from Java Applets and now I think its also used for desktop AWT applications in Java 7). The reason this broke was there was no underlying NSView for AWT Canvases anymore or method to stick an OpenGL Canvas on it.
Apple did later add a JAWT method to add CALayers (thus allowing NSOpenGLLayer) but this isn't really suitable for Java OpenGL bindings because it forces all opengl calls and rendering to be done inside NSOpenGLLayer's drawInOpenGLContext method, so not feasible to do that from the Java Thread without serious hackery to fit all OpenGL calls into that method during the limited time slice its given to render.
We still need a better method or API for AWT integration of OpenGL Contexts for Java OpenGL bindings without needing to resort to hackery to make it work (like on Windows and Linux).
LWJGL integration with AWT Applications and Java Applets would still be nice and likely wanted and needed by users but with the current JAWT/CALayer API the only feasible way to use it is to internally use a PBuffer (now depreciated on OS X) as a shared context with the NSOpenGLLayer context then render to texture on LWJGL Display update (which has a large overhead) and then draw the texture in the NSOpenGLLayer. It would work but ends up being slow, buggy and adds a bit too much hackery insider an otherwise simple OpenGL binding.
kappa, I think I might know what causes the duplicate window to happen.
I installed gfxCardStatus that allows me to switch between Integrated/Discrete video accelerators. It also notifies me when the system changes the settings. I noticed that I occasionally still got a duplicated window (as it it was not parented) during development and that in those cases the 'switch' was 'early'. So maybe somehow the swapping from intel <-> nvidia causes something to lock up and an extra window to spawn?
Or maybe the window gets recreated and somehow lost thus it cannot be parented?
@kappa
Whether we want it or not, Apple wants developers to use CoreAnimation layers. Right now it's the only option for Safari plugins, but in future I would expect layers to be forced for desktop apps as well. Just because it makes OS X life much easier by controlling what, when, and where is rendered by applications.
AWT team at Oracle is about to provide a Java class, that is a wrapper over real NSView. Most likely, this NSView will be backed by CALayer, but it's too early to say it for sure right now. Is LWGJL team interested in this at all?
Crash i had just now:
2012-12-01 13:29:25.940 java[16337:707] *** -[NSArray initWithArray:range:copyItems:]: range {0, 4} extends beyond bounds [0 .. 2]
2012-12-01 13:29:25.942 java[16337:707] (
0 CoreFoundation 0x00007fff88d570a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8518f3f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff88d0c0e4 -[NSArray initWithArray:range:copyItems:] + 212
3 AppKit 0x00007fff89279079 -[NSView(NSInternal) _updateTrackingAreas] + 1201
4 AppKit 0x00007fff89278aac _handleInvalidCursorRectsNote + 863
5 AppKit 0x00007fff89776551 __35-[NSWindow _postInvalidCursorRects]_block_invoke_02794 + 46
6 CoreFoundation 0x00007fff88d1d9b7 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
7 CoreFoundation 0x00007fff88d1d921 __CFRunLoopDoObservers + 369
8 CoreFoundation 0x00007fff88cf8d88 __CFRunLoopRun + 728
9 CoreFoundation 0x00007fff88cf86b2 CFRunLoopRunSpecific + 290
10 HIToolbox 0x00007fff8e9510a4 RunCurrentEventLoopInMode + 209
11 HIToolbox 0x00007fff8e950e42 ReceiveNextEventCommon + 356
12 HIToolbox 0x00007fff8e950cd3 BlockUntilNextEventMatchingListInMode + 62
13 AppKit 0x00007fff8919e613 _DPSNextEvent + 685
14 AppKit 0x00007fff8919ded2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
15 libawt.jnilib 0x0000000117200fdb -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 124
16 AppKit 0x00007fff89195283 -[NSApplication run] + 517
17 libawt.jnilib 0x00000001171ff68c +[AWTStarter startAWT:] + 1495
18 libawt.jnilib 0x00000001171ff006 -[CPerformer perform] + 93
19 Foundation 0x00007fff8b614677 __NSThreadPerformPerform + 225
20 CoreFoundation 0x00007fff88cd6101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
21 CoreFoundation 0x00007fff88cd5a25 __CFRunLoopDoSources0 + 245
22 CoreFoundation 0x00007fff88cf8dc5 __CFRunLoopRun + 789
23 CoreFoundation 0x00007fff88cf86b2 CFRunLoopRunSpecific + 290
24 java 0x000000010b992843 java + 18499
25 java 0x000000010b99229a java + 17050
26 java 0x000000010b98fa98 java + 6808
)
It followed after restarting Minecraft (debugger attached) after it spawned the 'double windows'.
New update:
- total re-implementation of fullscreen mode, should work pretty nice now.
- resizing fixed, should work as expected now (including when switching to and from fullscreen).
- scroll wheel implemented.
- fixed a few native crash issues.
- fixes for keyboard keys that didn't work (credit to Grum).
- some code clean up.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Tested 'Revenge of the Titans' using the above build, game works pretty flawlessly for me now.
@adamk33n3r - your fullscreen issue should be fixed now.
@Ixmal - thanks for dropping by, having access to a real NSView would be nice but I do understand the reasons it would need to be backed by a CALayer (maybe have an option to allow non CALayer NSViews too, where possible? that would be useful to LWJGL for fast rendering in AWT applications). As I understand it (after a bit of googling), rendering OpenGL to NSViews backed by a layer doesn't work too well. Seems mainly like a limitation of how Core Animation works when trying to render to it using another thread. For CALayers, using the slower render to texture and then draw to a CALayer seems like the most feasible way for LWJGL to go atm for AWT support.
Nice work kappa!
... now, what's the score with deploying OpenJDK7 apps on Mac OS using embedded VMs?
Cas :)
Quote from: kappa on December 09, 2012, 18:12:05
New update:
- total re-implementation of fullscreen mode, should work pretty nice now.
- resizing fixed, should work as expected now (including when switching to and from fullscreen).
- scroll wheel implemented.
- fixed a few native crash issues.
- fixes for keyboard keys that didn't work (credit to Grum).
- some code clean up.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Tested 'Revenge of the Titans' using the above build, game works pretty flawlessly for me now.
@adamk33n3r - your fullscreen issue should be fixed now.
@Ixmal - thanks for dropping by, having access to a real NSView would be nice but I do understand the reasons it would need to be backed by a CALayer (maybe have an option for non CALayer NSViews too? that would be useful to LWJGL for fast rendering in AWT applications). As I understand it (after a bit of googling), rendering OpenGL to NSViews backed by a layer doesn't work too well. Seems mainly like a limitation of how Core Animation works when trying to render to it using another thread. Using the slower render to texture and then draw to a CALayer seems like the most feasible way for LWJGL to go atm for AWT support.
@kappa Thanks it works great now! Just something to tell you though: I'm getting a "invalid drawable" most of the time when I go fullscreen. It doesn't seem to be doing anything wrong but it's an error so I thought I'd let you know. Again, thanks
Just tested with latest Minecraft.
The scroll direction is inverted, don't know if this is an implementation problem in LWJGL or in Minecraft.
When using the launcher it seems happy to work, when attempting to start from terminal i get this:
QuoteException in thread "main" java.lang.NoClassDefFoundError: org/lwjgl/LWJGLException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
at java.lang.Class.getMethod0(Class.java:2685)
at java.lang.Class.getMethod(Class.java:1620)
at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:492)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:484)
Caused by: java.lang.ClassNotFoundException: org.lwjgl.LWJGLException
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
... 6 more
Tried starting it with a third party program and it gets stuck when loading LWJGL under Java 7, but works just fine with Java 6 (couldn't get any logs from the "stuck" state, it just stops responding entirely)
Am also getting crash reports when closing the game. Can post these if necessary
@Komoden good to know that it still works with launcher. Something is wrong with your settings when using the terminal, ensure lwjgl.jar is included in the classpath.
Not focused much on getting the Display.setParent()/AWTGLCanvas stuff working correctly yet as it needs a big rewrite and will be the most tricky part to get right. Currently focused on getting the pure native Display functionality fully working first. Anyway, was aware of the crash on close when using Display.setParent(), will look into getting that sorted soon.
I'll double check the scroll wheel direction, might have it the wrong way round.
@adamk33n3r - the "invalid drawable" should be harmless message for now, but will get that fixed.
Anyway thanks for testing ppl.
I tried it out and you definitely got scroll in there backwards. Other than that the only errors I see are that Minecraft crashes when I tell it to close, and it puts the version text in the title bar of the window in addition to the Minecraft text that's normally there.
I had the same error Komoden had when I tried to start Minecraft with the launcher jar by double clicking instead of putting in the necessary arguments the launcher normally does. When I added at the very least the two arguments to set the amount of RAM it worked perfectly fine and ran with Java 7.
New update:
- implemented Mouse.setCursorPosition().
- implemented Display.getX() and Display.getY().
- implemented Display.isActive().
- fixed 'invalid drawable' error - as reported by @adamk33n3r.
- corrected scroll wheel direction - as reported by @Komoden and @pizza2004.
- fixed crash on exit when using Display.setParent().
- some more code clean up.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Two things remain now after which the code is ready to be merged into LWJGL's main branch:
1) Implement native cursor support (shouldn't be too difficult).
2) Re-implement the AWT/Display.setParent support to use FBO's internally with the JAWT CALayer API (will allow LWJGL applications that use AWT to run on Java 7 and as Java Applet).
excellent work! keep 'em coming :)
Thanks, this definitely fixes the scrolling and the crash on close bugs. However I'm still seeing this bug:
Before when you ran Minecraft it would say "Minecraft" in the title bar of the window. Now, with this current version of LWJGL it displays "Minecraft Minecraft 1.4.6" in the title bar. Any ideas why this is happening? Should this be happening?
I also am now unable to run Minecraft using Java 7 at all. It gets stuck at the LWJGL loading stage, but I can't imagine why I'd have to include the class path name for LWJGL in the terminal command as I'm running the Minecraft Launcher with Java 7.
I guess I picked a bad time to start playing with OpenGL and Java, because I mainly develop on a MacbookPro and I'm running Java7. That said, I can get the intro tutorials on the lwjgl doc page to work fine, but the 3.2+ ones I can't get to work at all. The drawArrays one gives me "Invalid Operation" in the loop cycle and the drawElements on doesn't draw the quad at all, just the bluish background. Is there something I'm missing that should be in those tutorials? I know about the ContextAttribs being an immutable object and the calls should be chained, and I've tried taking out the glViewport calls, but it doesn't appear to have an effect.
I am eagerly anticipating further developments on this issue. I am testing with the current experimental build, please keep the updates coming!
Thank you, kappa.
Quote from: bobbo on December 25, 2012, 22:12:44
I am eagerly anticipating further developments on this issue. I am testing with the current experimental build, please keep the updates coming!
Thank you, kappa.
progress is being made, slowly but surely, currently trying to get the Display.setParent/AWT stuff working using the JAWT/CALayer API, this should allow Display.setParent() to work correctly on Java 7 and with Java applets. Will post the next update as soon as its in a usable form.
Is the source available on the repo?
https://github.com/LWJGL/lwjgl/tree/osx-java7
Thanks, this is what I was looking for.
Hi all,
I would love to start doing some testing on Mac. What's the current status of this set of issues?
Cheers,
Nick
Grab the binaries from
https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
See Kappa's posts for the latest (which is where I got this link from)
I'm not sure if this is a bug of this new version of LWJGL, or the latest version of Minecraft, but I suspect it is LWJGL, and I'm going to test that by reverting to the default version soon. Anyway, I'm unable to right click by holding the control button and left clicking like you would expect to be able to, and it's bothering me because I don't like having to use the two finger method of right clicking all the time.
EDIT: I checked by forcing an update and then getting the latest snapshot and I could indeed use the control button to right click. That means that it's an error in this version of LWJGL. Glad to help with bugs, I hope you continue to make good progress and we see Java 7 support on Mac soon with this improved version of LWJGL.
kappaOne, how close is this commit https://github.com/LWJGL/lwjgl/commit/790f895220cceb21324bc1957b8eae6ceba4d251 (https://github.com/LWJGL/lwjgl/commit/790f895220cceb21324bc1957b8eae6ceba4d251) to having Display.setParent work with CALayer? I will get a VM going to test in a couple of days.
Is the glBlitFramebufferEXT in src/native/macosx/org_lwjgl_opengl_MacOSXCanvasPeerInfo.m intentionally clipped to 640/480 or is that left over from a test?
I am trying to figure out what is going on here but it's a little over my head, especially with the ObjC lisp syntax I don't understand.
Thank you.
Quote from: bobbo on January 05, 2013, 17:57:59
kappaOne, how close is this commit https://github.com/LWJGL/lwjgl/commit/790f895220cceb21324bc1957b8eae6ceba4d251 (https://github.com/LWJGL/lwjgl/commit/790f895220cceb21324bc1957b8eae6ceba4d251) to having Display.setParent work with CALayer? I will get a VM going to test in a couple of days.
Still a few more steps left to implement before the CALayer stuff is ready.
Quote from: bobbo on January 05, 2013, 17:57:59
I am trying to figure out what is going on here but it's a little over my head, especially with the ObjC lisp syntax I don't understand.
Basically the Display.setParent stuff will work something like this, firstly we'll try to get the legacy NSView handle for the AWT Canvas (on OS X 10.5 and partially Apple Java 6), if found, we'll use that as its faster and simpler otherwise we'll use the Java CALayer/JAWT API to stick a custom Core Animation Layer on the AWT Canvas.
As the layer does its own drawing we share its opengl context with the main LWJGL Display opengl context to allow easy and fast transfer of data to it. Internally LWJGL's content will be draw to a FBO (instead of on the native Display window). Then when the layer is ready to draw, we'll simply blit the content of the LWJGL FBO onto it. Lastly since layers (unlike NSView's) have no concept of input and JAWT doesn't provide any other API's for this, we therefore can't use LWJGL's native input with them and will have to rely on using AWT to provide the input.
Quote from: bobbo on January 05, 2013, 17:57:59
Is the glBlitFramebufferEXT in src/native/macosx/org_lwjgl_opengl_MacOSXCanvasPeerInfo.m intentionally clipped to 640/480 or is that left over from a test?
Thats actually commented out code, currently being used for debug purposes.
Wonderful, 7u11 is out. I'll keep checking up on this :-) Thanks Kappa
Kappa - you say you've got RotT working with OpenJDK7 on the Mac then?
Cas :)
Quote from: princec on January 14, 2013, 08:45:22
Kappa - you say you've got RotT working with OpenJDK7 on the Mac then?
Cas :)
Yup, LWJGL OS X branch runs ROTT pretty well, just drop the above builds (https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip) (lwjgl.jar and natives) over the current files.
If you are thinking of bundling OpenJDK7/Java7 then do keep in mind that OpenJDK7/Java7 only work on OS X 10.7+ and you'll have to use the system JRE when on OS X 10.5 and 10.6. You'll probably need to use some sort of launcher to detect the OS X version and use the appropriate Java runtime (possibly using a shell script (http://www.macgeekery.com/tips/cli/how_get_mac_os_x_version_shell_script) that gets the OS X version).
New update:
After a lot of hackage the Display.setParent() should be working now, including on Java 7+ and with Java Applets.
Hopefully if all goes well with the new build, the OS X branch can be merged into the main LWJGL branch as most the heavy lifting is now done. Then its just a matter of polish, adding any missing bits and getting ready for a new LWJGL release.
Do please test and report any issues.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
boom! LWJGLException - native mouse cursors not supported.
Am in full on testing mode now. I'll test every build as soon as I see it.
Cas :)
Fantastic work Kappa! I'll set up a couple of VirtualBox images to test on, this is exactly what I was waiting for.
Applets might not be popular right now but maybe I can help sway some opinions. :-)
Any resolution on my being unable to use the control + click as right click with this version bug? It's such an integral part of Mac for a lot of people I'm sure, and it's commonly a lot more reliable than trying to use other methods (unless you have a two button mouse) so it would be nice if you'd fix it.
@princec native mouse cursors not implemented yet, probably the last biggish feature left to implement. Focused mainly on the Display.setParent() stuff this update. AWTGLCanvas also not implemented yet but shouldn't be too hard once there is further confirmation that Display.setParent() works. The rest should mostly be there.
@pizza2004, control + click should hopefully be implemented for the native Display soon, should already work when using the new Display.setParent mode (e.g. Minecraft) as that uses AWT for input.
hmm how'd you get Revenge of the Titans working then? It should crash...
Cas :)
Quote from: princec on January 17, 2013, 10:14:24
hmm how'd you get Revenge of the Titans working then? It should crash...
Cas :)
As far as I can tell, it doesn't use native cursors, its just grabs the mouse and draws its own (unless you changed that in more recent updates, not updated my version in a while).
edit: oh, just updated to latest ROTT and it seems that it does now use native cursors, guess the native cursor support will need to be implemented before ROTT works.
Yeah, if you recall I had to remove mouse grabbing because it misbehaved somewhat wrt. mouse acceleration etc etc. and this was my workaround - I set the cursor to a nearly invisible dot and don't grab it any more.
Cas :)
... I will be sending you a special gift when you get this working :)
Cas :)
Okay, I tested Minecraft and it appears to be working entirely correctly. So I'm happy about that! Now we just need to get Mojang to support 1.7 on Mac as well, they'll have to release a new launcher to allow that.
Hey guys, thumbs up for the good work on this. However, I was wondering, if by accident anyone was testing the binaries with jmonkey sdk? I have to do some work on jmonkey and am a complete new user. I don't have access to a linux/windows machine, so I am trying to figure out what is the least painful way of getting jmonkey. There's either finding out how to build jmonkey sdk with your libraries or freeing up enough space to set up a virtual machine...
Quote from: duffycola on January 19, 2013, 01:34:18
Hey guys, thumbs up for the good work on this. However, I was wondering, if by accident anyone was testing the binaries with jmonkey sdk? I have to do some work on jmonkey and am a complete new user. I don't have access to a linux/windows machine, so I am trying to figure out what is the least painful way of getting jmonkey. There's either finding out how to build jmonkey sdk with your libraries or freeing up enough space to set up a virtual machine...
Least painful way is to just drop the above binaries (https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip) over any existing LWJGL binaries included with it and you should be good to go.
I got the latest files from @kappa's post but since that only had osx natives in it I am getting this error when I run it on a windows system
jar version is '24', native library version is '23'
should I just not use the newer .jar? or are there updated windows natives too?
Hey, this current version of Minecraft runs perfectly with the latest version you provide in Java 6. It fails to start in Java 7, here's the crash report, maybe it will be helpful:
---- Minecraft Crash Report ----
// Don't be sad. I'll do better next time, I promise!
Time: 1/19/13 8:09 PM
Description: Failed to start game
org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:51)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:94)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:92)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:92)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:66)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:54)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXDisplay.createWindow(MacOSXDisplay.java:132)
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.lwjgl.opengl.Display.create(Display.java:736)
at net.minecraft.client.Minecraft.a(SourceFile:232)
at aub.a(SourceFile:56)
at net.minecraft.client.Minecraft.run(SourceFile:506)
at java.lang.Thread.run(Thread.java:722)
A detailed walkthrough of the error, its code path and all known details is as follows:
---------------------------------------------------------------------------------------
-- System Details --
Details:
Minecraft Version: 13w03a
Operating System: Mac OS X (x86_64) version 10.7.5
Java Version: 1.7.0_10, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 414681880 bytes (395 MB) / 514523136 bytes (490 MB) up to 954466304 bytes (910 MB)
JVM Flags: 2 total; -Xmx1024M -Xms512M
AABB Pool Size: 0 (0 bytes; 0 MB) allocated, 0 (0 bytes; 0 MB) used
Suspicious classes: No suspicious classes found.
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
LWJGL: 2.8.5
OpenGL: ~~ERROR~~ RuntimeException: No OpenGL context found in the current thread.
Is Modded: Probably not. Jar signature remains and client brand is untouched.
Type: Client (map_client.txt)
Texture Pack: Default
Profiler Position: N/A (disabled)
Vec3 Pool Size: ~~ERROR~~ NullPointerException: null
Edit: It appears I've gotten this same error in the past when trying to use this version of LWJGL and Java 7 instead of Java 6. So, that's why Minecraft won't work with Java 7 on Mac at the moment. Once this is finished and merged into the default version of LWJGL and there's a new version released perhaps it can come standard with the latest version of Minecraft.
Hi,
I was testing the latest binaries you supplied in this thread with JDK 1.7.0_11 and the latest JME nightly snapshot on OS X 10.8.2 and found 2 issues:
- on exiting the game, an error message is logged, no idea about what exactly: [error] AL lib: ReleaseALC: 1 device not closed
- when I turn on multisampling/AA, the JVM crashes:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000000016d5b39fe, pid=2885, tid=43527
#
# JRE version: 7.0_11-b21
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.6-b04 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [liblwjgl.dylib+0x159fe] Java_org_lwjgl_opengl_MacOSXContextImplementation_nCreate+0xce
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x00007fb4442d8000): JavaThread "LWJGL Renderer Thread" [_thread_in_native, id=43527, stack(0x000000016e23d000,0x000000016e33d000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000050
Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0x00007fb444af3090, RDX=0x00007fb446131800
RSP=0x000000016e33c460, RBP=0x000000016e33c4b0, RSI=0x0000010000000100, RDI=0x0000000000000103
R8 =0x0000000000012068, R9 =0x000000016e33c3c0, R10=0x00000000000010bc, R11=0x0000000000000000
R12=0x00007fb444af3090, R13=0x00007fb4442d81d8, R14=0x00007fb444af2c30, R15=0x00007fb448e201f8
RIP=0x000000016d5b39fe, EFLAGS=0x0000000000010206, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x000000016e33c460)
0x000000016e33c460: 000000016e33c4a0 00007fb448e0fec0
0x000000016e33c470: 000000016e33c470 000000010aea1248
0x000000016e33c480: 00007fb4442d8000 000000010aeb1f58
0x000000016e33c490: 0000000000000000 000000010aeb1f50
0x000000016e33c4a0: 000000016e33c538 00007fb4442d8000
0x000000016e33c4b0: 000000016e33c510 0000000106af2f90
0x000000016e33c4c0: 0000000146e1fad8 000000016e33c538
0x000000016e33c4d0: 000000016e33c4d0 000000010aeb1f50
0x000000016e33c4e0: 000000016e33c538 000000010aeb3638
0x000000016e33c4f0: 0000000000000000 000000010aeb1f58
0x000000016e33c500: 0000000000000000 000000016e33c530
0x000000016e33c510: 000000016e33c580 0000000106ae7333
0x000000016e33c520: 0000000146e345c8 0000000106aefddb
0x000000016e33c530: 0000000000000000 0000000146e1fad8
0x000000016e33c540: 000000016e33c540 000000010aeb1e21
0x000000016e33c550: 000000016e33c5c0 000000010aeb3638
0x000000016e33c560: 0000000000000000 000000010aeb1e80
0x000000016e33c570: 000000016e33c530 000000016e33c5a8
0x000000016e33c580: 000000016e33c620 0000000106ae79e1
0x000000016e33c590: 0000000000000000 0000000000000000
0x000000016e33c5a0: 0000000146e1fad8 0000000000000000
0x000000016e33c5b0: 0000000000000000 0000000146e1fa30
0x000000016e33c5c0: 0000000146e34638 0000000146e34648
0x000000016e33c5d0: 0000000146e34648 0000000146e34648
0x000000016e33c5e0: 000000016e33c5d0 000000010aeaeea7
0x000000016e33c5f0: 000000016e33c668 000000010aeb0f88
0x000000016e33c600: 0000000000000000 000000010aeaef50
0x000000016e33c610: 000000016e33c5a8 000000016e33c650
0x000000016e33c620: 000000016e33c6c0 0000000106ae7158
0x000000016e33c630: 0000000000000000 0000000000000000
0x000000016e33c640: 0000000146e34648 0000000146e34648
0x000000016e33c650: 0000000000000000 0000000000000000
Instructions: (pc=0x000000016d5b39fe)
0x000000016d5b39de: 48 89 d9 48 8d 35 38 56 02 00 ff 15 32 56 02 00
0x000000016d5b39ee: 49 89 c4 48 85 c0 0f 84 f1 00 00 00 49 8b 46 08
0x000000016d5b39fe: 80 78 50 00 0f 85 88 00 00 00 48 8d 35 d1 54 02
0x000000016d5b3a0e: 00 4c 89 e7 ff 15 c8 54 02 00 48 89 c7 be 31 01
Register to memory mapping:
RAX=0x0000000000000000 is an unknown value
RBX=0x0000000000000000 is an unknown value
RCX=0x00007fb444af3090 is an unknown value
RDX=0x00007fb446131800 is an unknown value
RSP=0x000000016e33c460 is pointing into the stack for thread: 0x00007fb4442d8000
RBP=0x000000016e33c4b0 is pointing into the stack for thread: 0x00007fb4442d8000
RSI=0x0000010000000100 is an unknown value
RDI=0x0000000000000103 is an unknown value
R8 =0x0000000000012068 is an unknown value
R9 =0x000000016e33c3c0 is pointing into the stack for thread: 0x00007fb4442d8000
R10=0x00000000000010bc is an unknown value
R11=0x0000000000000000 is an unknown value
R12=0x00007fb444af3090 is an unknown value
R13=0x00007fb4442d81d8 is an unknown value
R14=0x00007fb444af2c30 is an unknown value
R15=0x00007fb448e201f8 is an unknown value
Stack: [0x000000016e23d000,0x000000016e33d000], sp=0x000000016e33c460, free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [liblwjgl.dylib+0x159fe] Java_org_lwjgl_opengl_MacOSXContextImplementation_nCreate+0xce
j org.lwjgl.opengl.MacOSXContextImplementation.nCreate(Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)Ljava/nio/ByteBuffer;+0
j org.lwjgl.opengl.MacOSXContextImplementation.create(Lorg/lwjgl/opengl/PeerInfo;Ljava/nio/IntBuffer;Ljava/nio/ByteBuffer;)Ljava/nio/ByteBuffer;+9
j org.lwjgl.opengl.ContextGL.<init>(Lorg/lwjgl/opengl/PeerInfo;Lorg/lwjgl/opengl/ContextAttribs;Lorg/lwjgl/opengl/ContextGL;)V+103
j org.lwjgl.opengl.Pbuffer.<init>(IILorg/lwjgl/opengl/PixelFormat;Lorg/lwjgl/opengl/RenderTexture;Lorg/lwjgl/opengl/Drawable;Lorg/lwjgl/opengl/ContextAttribs;)V+88
j org.lwjgl.opengl.Pbuffer.<init>(IILorg/lwjgl/opengl/PixelFormat;Lorg/lwjgl/opengl/RenderTexture;Lorg/lwjgl/opengl/Drawable;)V+9
j org.lwjgl.opengl.Pbuffer.<init>(IILorg/lwjgl/opengl/PixelFormat;Lorg/lwjgl/opengl/Drawable;)V+7
j com.jme3.system.lwjgl.LwjglContext.determineMaxSamples(I)I+96
j com.jme3.system.lwjgl.LwjglContext.getNumSamplesToUse()I+23
j com.jme3.system.lwjgl.LwjglDisplay.createContext(Lcom/jme3/system/AppSettings;)V+92
j com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread()Z+25
j com.jme3.system.lwjgl.LwjglAbstractDisplay.run()V+32
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
V [libjvm.dylib+0x28855f]
V [libjvm.dylib+0x288a3c]
V [libjvm.dylib+0x288b76]
V [libjvm.dylib+0x2bf4f0]
V [libjvm.dylib+0x4782b4]
V [libjvm.dylib+0x47979a]
V [libjvm.dylib+0x3b51b5]
C [libsystem_c.dylib+0x14742] _pthread_start+0x147
C [libsystem_c.dylib+0x1181] thread_start+0xd
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.lwjgl.opengl.MacOSXContextImplementation.nCreate(Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)Ljava/nio/ByteBuffer;+0
j org.lwjgl.opengl.MacOSXContextImplementation.create(Lorg/lwjgl/opengl/PeerInfo;Ljava/nio/IntBuffer;Ljava/nio/ByteBuffer;)Ljava/nio/ByteBuffer;+9
j org.lwjgl.opengl.ContextGL.<init>(Lorg/lwjgl/opengl/PeerInfo;Lorg/lwjgl/opengl/ContextAttribs;Lorg/lwjgl/opengl/ContextGL;)V+103
j org.lwjgl.opengl.Pbuffer.<init>(IILorg/lwjgl/opengl/PixelFormat;Lorg/lwjgl/opengl/RenderTexture;Lorg/lwjgl/opengl/Drawable;Lorg/lwjgl/opengl/ContextAttribs;)V+88
j org.lwjgl.opengl.Pbuffer.<init>(IILorg/lwjgl/opengl/PixelFormat;Lorg/lwjgl/opengl/RenderTexture;Lorg/lwjgl/opengl/Drawable;)V+9
j org.lwjgl.opengl.Pbuffer.<init>(IILorg/lwjgl/opengl/PixelFormat;Lorg/lwjgl/opengl/Drawable;)V+7
j com.jme3.system.lwjgl.LwjglContext.determineMaxSamples(I)I+96
j com.jme3.system.lwjgl.LwjglContext.getNumSamplesToUse()I+23
j com.jme3.system.lwjgl.LwjglDisplay.createContext(Lcom/jme3/system/AppSettings;)V+92
j com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread()Z+25
j com.jme3.system.lwjgl.LwjglAbstractDisplay.run()V+32
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
Hope this helps. :)
Hi,
I tried the latest version, firstly on Java 1.6_37 with OS X 10.8.2 as an applet in Eclipse. I get the following native crash report:
Process: java [5279]
Path: /usr/bin/java
Identifier: com.apple.javajdk16.cmd
Version: 1.0 (1.0)
Code Type: X86-64 (Native)
Parent Process: eclipse [5187]
User ID: 501
PlugIn Path: /Users/USER/*/liblwjgl.jnilib
PlugIn Identifier: liblwjgl.jnilib
PlugIn Version: ??? (0)
Date/Time: 2013-01-22 14:39:09.632 +0000
OS Version: Mac OS X 10.8.2 (12C3012)
Report Version: 10
Interval Since Last Report: 224728 sec
Crashes Since Last Report: 11
Per-App Interval Since Last Report: 71078 sec
Per-App Crashes Since Last Report: 4
Anonymous UUID: D91619B8-7DB3-882E-F46B-8D8BD4C9635F
Crashed Thread: 34 Java: AWT-EventQueue-1
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000050
VM Regions Near 0x50:
-->
__TEXT 00000001039c5000-00000001039cd000 [ 32K] r-x/rwx SM=COW /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java
Application Specific Information:
Java information:
Exception type: Bus Error (0xa) at pc=113a099fe
Java VM: Java HotSpot(TM) 64-Bit Server VM (20.12-b01-434 mixed mode macosx-amd64)
Current thread (7fb4ef892000): JavaThread "AWT-EventQueue-1" [_thread_in_native, id=331317248, stack(113af8000,113bf8000)]
Stack: [113af8000,113bf8000]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.lwjgl.opengl.MacOSXContextImplementation.nCreate(Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)Ljava/nio/ByteBuffer;+0
j org.lwjgl.opengl.MacOSXContextImplementation.create(Lorg/lwjgl/opengl/PeerInfo;Ljava/nio/IntBuffer;Ljava/nio/ByteBuffer;)Ljava/nio/ByteBuffer;+9
j org.lwjgl.opengl.ContextGL.<init>(Lorg/lwjgl/opengl/PeerInfo;Lorg/lwjgl/opengl/ContextAttribs;Lorg/lwjgl/opengl/ContextGL;)V+103
j org.lwjgl.opengl.AWTGLCanvas.paint(Ljava/awt/Graphics;)V+101
j sun.awt.RepaintArea.paintComponent(Ljava/awt/Component;Ljava/awt/Graphics;)V+6
j sun.awt.RepaintArea.paint(Ljava/lang/Object;Z)V+368
j apple.awt.ComponentModel.handleEvent(Ljava/awt/AWTEvent;)V+70
j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+861
j java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2
j java.awt.EventQueue.dispatchEventImpl(Ljava/awt/AWTEvent;Ljava/lang/Object;)V+41
j java.awt.EventQueue.access$400(Ljava/awt/EventQueue;Ljava/awt/AWTEvent;Ljava/lang/Object;)V+3
j java.awt.EventQueue$2.run()Ljava/lang/Void;+12
j java.awt.EventQueue$2.run()Ljava/lang/Object;+1
v ~StubRoutines::call_stub
j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0
j java.security.AccessControlContext$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;+28
j java.security.AccessControlContext$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+6
j java.awt.EventQueue$3.run()Ljava/lang/Void;+11
j java.awt.EventQueue$3.run()Ljava/lang/Object;+1
v ~StubRoutines::call_stub
j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0
j java.security.AccessControlContext$1.doIntersectionPrivilege(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/security/AccessControlContext;)Ljava/lang/Object;+28
j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+73
j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+204
j java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30
j java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11
j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
j java.awt.EventDispatchThread.run()V+9
v ~StubRoutines::call_stub
Java Threads: ( => current thread )
=>7fb4ef892000 JavaThread "AWT-EventQueue-1" [_thread_in_native, id=331317248, stack(113af8000,113bf8000)]
7fb4e9089000 JavaThread "DestroyJavaVM" [_thread_blocked, id=69853184, stack(10419e000,10429e000)]
7fb4e9085800 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=329097216, stack(1138da000,1139da000)]
7fb4e9082800 JavaThread "thread applet-avc.TackFoot3D.AVC_Applet.class" [_thread_blocked, id=328036352, stack(1137d7000,1138d7000)]
7fb4ea851800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=326975488, stack(1136d4000,1137d4000)]
7fb4eb9b5000 JavaThread "AWT-Shutdown" [_thread_blocked, id=222179328, stack(10d2e3000,10d3e3000)]
7fb4eb9b4800 JavaThread "AWT-AppKit" daemon [_thread_in_native, id=1994916224, stack(7fff5ba3b000,7fff5c23b000)]
7fb4eb96f000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=217055232, stack(10ce00000,10cf00000)]
7fb4eb96e000 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=215994368, stack(10ccfd000,10cdfd000)]
7fb4eb96d800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=214933504, stack(10cbfa000,10ccfa000)]
7fb4ea818800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=213872640, stack(10caf7000,10cbf7000)]
7fb4ea817800 JavaThread "Surrogate Locker Thread (Concurrent GC)" daemon [_thread_blocked, id=212811776, stack(10c9f4000,10caf4000)]
7fb4eb96c800 JavaThread "Finalizer" daemon [_thread_blocked, id=210669568, stack(10c7e9000,10c8e9000)]
7fb4eb96c000 JavaThread "Reference Handler" daemon [_thread_blocked, id=209608704, stack(10c6e6000,10c7e6000)]
Other Threads:
7fb4eb967800 VMThread [stack: 10c5e3000,10c6e3000] [id=208547840]
7fb4eb980800 WatcherThread [stack: 10cf03000,10d003000] [id=218116096]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
par new generation total 19136K, used 9962K [7dae00000, 7dc2c0000, 7dee00000)
eden space 17024K, 58% used [7dae00000, 7db7ba940, 7dbea0000)
from space 2112K, 0% used [7dbea0000, 7dbea0000, 7dc0b0000)
to space 2112K, 0% used [7dc0b0000, 7dc0b0000, 7dc2c0000)
concurrent mark-sweep generation total 63872K, used 0K [7dee00000, 7e2c60000, 7fae00000)
concurrent-mark-sweep perm gen total 21248K, used 12062K [7fae00000, 7fc2c0000, 800000000)
Code Cache [1044df000, 104750000, 1074df000)
total_blobs=430 nmethods=41 adapters=352 free_code_cache=49730624 largest_free_block=7360
Virtual Machine Arguments:
JVM Args: -Xmx512m -Djava.library.path=/Users/Alan/PerforceWorkspace/AVC/JME2.0_19_05_10/lib/lwjgl/native/windows:/Users/Alan/PerforceWorkspace/AVC/JME2.0_19_05_10/lib/jogl/native/macosx:/Users/Alan/PerforceWorkspace/AVC/JME2.0_19_05_10/lib/jogl/native/macosx:/Users/Alan/PerforceWorkspace/AVC/JME2.0_19_05_10/lib/lwjgl/native/macosx:/Users/Alan/PerforceWorkspace/AVC/JME2.0_19_05_10/lib/lwjgl/native/macosx:/Users/Alan/PerforceWorkspace/AVC/JME2.0_19_05_10/lib/lwjgl/native/macosx:/Users/Alan/PerforceWorkspace/AVC/JME2.0_19_05_10/lib/lwjgl/native/macosx -Djava.security.policy=java.policy.applet -Dfile.encoding=MacRoman
Java Command: sun.applet.AppletViewer avc.TackFoot3D.AVC_Applet1358865547056.html
Launcher Type: SUN_STANDARD
Physical Memory: Page Size = 4k, Total = 16384M, Free = 4428M
When run as an application there are no problems.
Using Java 1.7_11, as an applet in Eclipse, a blank applet window loads, but I get the following error in the console and my app doesn't load up:
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
It works as an application with no issues.
Hope this helps.
@ajr_1 thx for testing, as mentioned above, AWTGLCanvas isn't yet implemented with the new CALayer stuff, however the more commonly used method of Display.setParent() should work fine and allow you to run LWJGL in the browser.
Ok, thanks for the update. I've inherited this app, and being mainly a web developer, I've not quite got my head around a lot of the concepts.
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)?
Hello, I'm also testing the new OSX-java7 branch (building binaries myself) on OSX 10.8.2. Everything appears to run fine with Java 1.6 (except re-initializing the Display, I can go into more detail later). But with 1.7 I get:
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:51)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:94)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:92)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:92)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:66)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:54)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXDisplay.createWindow(MacOSXDisplay.java:132)
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)
...
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:
canvas = new Canvas();
canvas.setFocusable(true);
canvas.requestFocus();
canvas.setBackground(Color.BLACK);
canvas.setForeground(Color.BLACK);
canvas.setBounds(0, 0, width, height);
parent.setLayout(new BorderLayout());
parent.add(canvas, BorderLayout.CENTER);
try {
PixelFormat format = new PixelFormat(32, 8, 24, 8, 1);
Display.setDisplayMode(new DisplayMode(width, height));
Display.setParent(canvas);
Display.create(format);
Display.setVSyncEnabled(true);
} catch (LWJGLException e) {
e.printStackTrace();
}
where canvas is an AWT canvas, and parent a subclass of Applet.
Quote from: ajr_1 on January 22, 2013, 20:43:36
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.
Quote from: ac on January 22, 2013, 20:55:30
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 (http://www.lwjgl.org/wiki/index.php?title=Basic_LWJGL_Applet) on the wiki.
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.
Quotecom.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:
QuoteInvalid 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?
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!
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
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.
@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).
Seems to be working great for me :)
Cas :)
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!
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!
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.
Quote from: ajr_1 on February 04, 2013, 10:20:46
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 (http://lwjgl.org/forum/index.php/topic,4217.msg26265.html#msg26265) that might be relevant, basically try Swing's setLightWeightPopupEnabled(false) (http://docs.oracle.com/javase/6/docs/api/javax/swing/JPopupMenu.html#setLightWeightPopupEnabled%28boolean%29) method.
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.
@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.
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.
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.
@kgcab I'm still getting the issue I was before when I try to start Minecraft, how did you get it to run with Java 7? Are you sure you're not just running it with Java 6 still? Using the default launcher provided with Minecraft will only run it in Java 6, try running it with this launcher I modified to run in Java 7. http://www.mediafire.com/?137i1rraix5sd0a (http://www.mediafire.com/?137i1rraix5sd0a) Basically, due to the difference in Oracle's implementation of Java, it's not possible for the app to find Java 7, so it just uses the version of Java 6 that Apple still provides. It took some doing, but I managed to hack the launcher apart and use a new launcher provided by Oracle to create a new version of the Minecraft launcher that will work with Java 7.
So yeah, unless you're running Minecraft through the command line (or via the launcher I provided) you're not going to be running Java 7, but rather Java 6. I figured I'd try to clarify this as I think it might be helpful for everyone to know what version of Java you're running for certain. You can also generate a crash log by holding down F3+C for like 10 seconds and then copy the contents of that file (It's in your minecraft folder in crash reports) to here so we can see for certain which version of Java you're using.
New update:
- fixed cmd-Q immediate app kill issue as reported by Nagi, LWJGL should now catch all quit commands (cmd-q, right clicking quit from dock, quit from menu, etc) and then report Display.isCloseRequested() as true.
- fixed issue with Display.setDisplayMode locking/freezing after an AL.create call as reported by Nagi (test case to reproduce the issue was very helpful).
- removed more AWT dependancies and replaced with equivalent Cocoa code (e.g. Display.getAvailableDisplayModes()), as a result LWJGL now even works when -Djava.awtheadless=true is set.
- Minor tweak to native cursor behaviour.
@cookies - Thx for reporting the Multisampling/AA issue when using JME3, currently looking into that and will hopefully have that fixed next.
@kgcabs - odd issue that, can you confirm whether it also happens on the Java 6 and/or when using the current stable release of LWJGL 2.8.5. Lastly can you also check whether it happens when running Minecraft in fullscreen mode? thx
Do please test and report any issues.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Thanks, kappa. I've been testing for a while and it works like a charm! The test case works perfectly now, and LWJGL is also catching the quit commands. I've even updated my local copy of the library I'm using (LibGDX) and my game runs smoothly, without needing to alter LibGDX source code anymore. I'll keep testing, but everything seems fine now. Thank you very much!
Hi kappa, thanks for the new update. I'm getting issues with the cursor in this one though - I've linked a couple of photos to illustrate. Everything else seems to be good though.
Cursor from this release:
http://www.flickr.com/photos/93113964@N07/8465551790/
Cursor from previous release:
http://www.flickr.com/photos/93113964@N07/8464454927/
@ajr_1, thx for testing, are you setting a native cursor? if so which data format are you using? (ARGB8888?, 1 bit or 8 bit transparency?)
Hi Kappa,
I've just been testing out the latest build. I'm having 2 main issues:
Mouse Grabbing
I'm trying to work out the exact pattern, but I can achieve both a completely lost cursor when the mouse shouldn't be grabbed, and an ever present cursor when it should be grabbed. Once I get the exact sequence of events I'll create a test case.
Fullscreen
When entering full screen, Display.getWidth/getHeight report the correct height/width of the screen, but only a subset of the window based from the bottom left is being drawn to (that area appears to match the windowed resolution before entering full screen).
I initially thought this might be glViewport based issue on my end .... but on hitting full screen getWidth/getHeight are reporting the correct the width/height (and my only viewport call is just after resize) and I'm also testing the same code against 2.8.5 on both windows and Mac, and both work are working perfectly.
Upon leaving full screen, resizing the window breaks Display.getWidth/getHeight, they get stuck reporting a specific width/height (one slightly smaller than full screen that doesn't match the current window) and continue to report that specific value regardless of the actual window size getting resized.
I haven't reduced this to a stand alone smallest possible test case. If my issue is strange/cant be reproduced let me know and I'll make one.
In short form:
1. Enter full screen
2. Exit full screen (only subset of window drawn too)
3. Resize window (getWidth/getHeight breaks)
Thanks.
I tested the latest upload with our jMonkeyEngine SDK which has two different ways to display the output to circumvent issues but both fail :(
The method where we create a backbuffer and copy the result to a "real" AWT panel works also on OSX/Java 7 with the current stable lwjgl but now both that and the use of the normal canvas fail like so:
Thread 41 Crashed:: Java: LWJGL Renderer Thread
0 libsystem_kernel.dylib 0x00007fff8e447212 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff881c2af4 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff88206dce abort + 143
3 libjvm.dylib 0x000000010b373c6f os::abort(bool) + 25
4 libjvm.dylib 0x000000010b46242e VMError::report_and_die() + 2306
5 libjvm.dylib 0x000000010b375363 JVM_handle_bsd_signal + 1073
6 libsystem_c.dylib 0x00007fff881af8ea _sigtramp + 26
7 liblwjgl.dylib 0x000000014862217e Java_org_lwjgl_opengl_MacOSXContextImplementation_nCreate + 206
8 ??? 0x000000010bc4df90 0 + 4492418960
9 ??? 0x000000010bc42333 0 + 4492370739
10 ??? 0x000000010bc429e1 0 + 4492372449
11 ??? 0x000000010bc42158 0 + 4492370264
12 ??? 0x000000010bc42158 0 + 4492370264
13 ??? 0x000000010bc42158 0 + 4492370264
14 ??? 0x000000010bc42158 0 + 4492370264
15 ??? 0x000000010bc42158 0 + 4492370264
16 ??? 0x000000010bc42158 0 + 4492370264
17 ??? 0x000000010bc42450 0 + 4492371024
18 ??? 0x000000010bc42806 0 + 4492371974
19 ??? 0x000000010bc3c4f7 0 + 4492346615
20 libjvm.dylib 0x000000010b24752f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
21 libjvm.dylib 0x000000010b247a0c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256
22 libjvm.dylib 0x000000010b247b46 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74
23 libjvm.dylib 0x000000010b27e4c0 thread_entry(JavaThread*, Thread*) + 169
24 libjvm.dylib 0x000000010b437294 JavaThread::thread_main_inner() + 134
25 libjvm.dylib 0x000000010b43877a JavaThread::run() + 440
26 libjvm.dylib 0x000000010b374191 java_start(Thread*) + 173
27 libsystem_c.dylib 0x00007fff881c1742 _pthread_start + 327
28 libsystem_c.dylib 0x00007fff881ae181 thread_start + 13
Thread 41 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x0000000148608cb8 rdx: 0x0000000000000000
rdi: 0x000000000000eb17 rsi: 0x0000000000000006 rbp: 0x0000000148608ce0 rsp: 0x0000000148608cb8
r8: 0x00007fff76fb0278 r9: 0x0000000148608c90 r10: 0x0000000020000000 r11: 0x0000000000000206
r12: 0x000000010b70a0e0 r13: 0x00007fdd86c191d8 r14: 0x000000014860a000 r15: 0x000000010b3771bc
rip: 0x00007fff8e447212 rfl: 0x0000000000000206 cr2: 0x00007fff76fa9fe8
Logical CPU: 0
When I run a normal jME app with the native window context it works but when I quit the app I get this (the first exception is happening multiple times before):
2013-02-12 14:29:30.249 java[7727:cd0b] Cocoa AWT: Not running on AppKit thread 0 when expected. (
0 libosxapp.dylib 0x0000000120d05411 +[ThreadUtilities getJNIEnv] + 34
1 liblwawt.dylib 0x0000000120c6c7ef -[AWTWindow windowDidBecomeMain:] + 118
2 CoreFoundation 0x00007fff8be3347a _CFXNotificationPost + 2554
3 Foundation 0x00007fff883a7846 -[NSNotificationCenter postNotificationName:object:userInfo:] + 64
4 AppKit 0x00007fff8723b7f0 -[NSWindow becomeMainWindow] + 169
5 AppKit 0x00007fff87235073 -[NSWindow _changeKeyAndMainLimitedOK:] + 830
6 AppKit 0x00007fff873133fc -[NSWindow _orderOutAndCalcKeyWithCounter:stillVisible:docWindow:] + 909
7 AppKit 0x00007fff8723d249 -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 3218
8 AppKit 0x00007fff8723c138 -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 940
9 AppKit 0x00007fff8723bd1f -[NSWindow orderWindow:relativeTo:] + 159
10 AppKit 0x00007fff87312b73 __18-[NSWindow _close]_block_invoke_0 + 487
11 AppKit 0x00007fff87312965 -[NSWindow _close] + 364
12 liblwjgl.dylib 0x0000000128e486c5 Java_org_lwjgl_opengl_MacOSXDisplay_nDestroyWindow + 165
13 ??? 0x000000010ddb2f90 0x0 + 4527435664
14 ??? 0x000000010dda7158 0x0 + 4527386968
15 ??? 0x000000010dda7806 0x0 + 4527388678
16 ??? 0x000000010dda7158 0x0 + 4527386968
17 ??? 0x000000010dda7158 0x0 + 4527386968
18 ??? 0x000000010dda7806 0x0 + 4527388678
)
2013-02-12 14:29:30.254 java[7727:cd0b] Please file a bug report at http://java.net/jira/browse/MACOSX_PORT with this message and a reproducible test case.
2013-02-12 14:29:30.256 java[7727:cd0b] An uncaught exception was raised
2013-02-12 14:29:30.259 java[7727:cd0b] java.lang.StackOverflowError
at org.lwjgl.opengl.MacOSXDisplay.nDestroyWindow(Native Method)
at org.lwjgl.opengl.MacOSXDisplay.destroyWindow(MacOSXDisplay.java:204)
at org.lwjgl.opengl.Display.destroyWindow(Display.java:348)
at org.lwjgl.opengl.Display.access$400(Display.java:62)
at org.lwjgl.opengl.Display$5.destroy(Display.java:832)
at org.lwjgl.opengl.Display.destroy(Display.java:1083)
at com.jme3.system.lwjgl.LwjglDisplay.destroyContext(LwjglDisplay.java:155)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.deinitInThread(LwjglAbstractDisplay.java:194)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:233)
at java.lang.Thread.run(Thread.java:722)
2013-02-12 14:29:30.286 java[7727:cd0b] (
0 CoreFoundation 0x00007fff8be810a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8a0413f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8bf15229 -[NSException raise] + 9
3 JavaNativeFoundation 0x00000001202c5539 JNFCallVoidMethod + 209
4 liblwawt.dylib 0x0000000120c6c838 -[AWTWindow windowDidBecomeMain:] + 191
5 CoreFoundation 0x00007fff8be3347a _CFXNotificationPost + 2554
6 Foundation 0x00007fff883a7846 -[NSNotificationCenter postNotificationName:object:userInfo:] + 64
7 AppKit 0x00007fff8723b7f0 -[NSWindow becomeMainWindow] + 169
8 AppKit 0x00007fff87235073 -[NSWindow _changeKeyAndMainLimitedOK:] + 830
9 AppKit 0x00007fff873133fc -[NSWindow _orderOutAndCalcKeyWithCounter:stillVisible:docWindow:] + 909
10 AppKit 0x00007fff8723d249 -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 3218
11 AppKit 0x00007fff8723c138 -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 940
12 AppKit 0x00007fff8723bd1f -[NSWindow orderWindow:relativeTo:] + 159
13 AppKit 0x00007fff87312b73 __18-[NSWindow _close]_block_invoke_0 + 487
14 AppKit 0x00007fff87312965 -[NSWindow _close] + 364
15 liblwjgl.dylib 0x0000000128e486c5 Java_org_lwjgl_opengl_MacOSXDisplay_nDestroyWindow + 165
16 ??? 0x000000010ddb2f90 0x0 + 4527435664
17 ??? 0x000000010dda7158 0x0 + 4527386968
18 ??? 0x000000010dda7806 0x0 + 4527388678
19 ??? 0x000000010dda7158 0x0 + 4527386968
20 ??? 0x000000010dda7158 0x0 + 4527386968
21 ??? 0x000000010dda7806 0x0 + 4527388678
)
2013-02-12 14:29:30.289 java[7727:cd0b] *** Terminating app due to uncaught exception 'JavaNativeException', reason: 'Internal JNF Error: failed calling Throwable.toString()'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff8be810a6 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8a0413f0 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8bf15229 -[NSException raise] + 9
3 JavaNativeFoundation 0x00000001202c5539 JNFCallVoidMethod + 209
4 liblwawt.dylib 0x0000000120c6c838 -[AWTWindow windowDidBecomeMain:] + 191
5 CoreFoundation 0x00007fff8be3347a _CFXNotificationPost + 2554
6 Foundation 0x00007fff883a7846 -[NSNotificationCenter postNotificationName:object:userInfo:] + 64
7 AppKit 0x00007fff8723b7f0 -[NSWindow becomeMainWindow] + 169
8 AppKit 0x00007fff87235073 -[NSWindow _changeKeyAndMainLimitedOK:] + 830
9 AppKit 0x00007fff873133fc -[NSWindow _orderOutAndCalcKeyWithCounter:stillVisible:docWindow:] + 909
10 AppKit 0x00007fff8723d249 -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 3218
11 AppKit 0x00007fff8723c138 -[NSWindow _doOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 940
12 AppKit 0x00007fff8723bd1f -[NSWindow orderWindow:relativeTo:] + 159
13 AppKit 0x00007fff87312b73 __18-[NSWindow _close]_block_invoke_0 + 487
14 AppKit 0x00007fff87312965 -[NSWindow _close] + 364
15 liblwjgl.dylib 0x0000000128e486c5 Java_org_lwjgl_opengl_MacOSXDisplay_nDestroyWindow + 165
16 ??? 0x000000010ddb2f90 0x0 + 4527435664
17 ??? 0x000000010dda7158 0x0 + 4527386968
18 ??? 0x000000010dda7806 0x0 + 4527388678
19 ??? 0x000000010dda7158 0x0 + 4527386968
20 ??? 0x000000010dda7158 0x0 + 4527386968
21 ??? 0x000000010dda7806 0x0 + 4527388678
)
libc++abi.dylib: terminate called throwing an exception
Running on OSX 10.8.2 / MacBook Pro Core i7 / NVIDIA GeForce GT 330M 512 MB / JDK 1.7u13
Cheers,
Normen
Using the latest experimental JAR on Windows 7, CTRL is not reported as being down when the mouse is clicked. You can reproduce this using the executable example code here:
http://lwjgl.org/forum/index.php/topic,4811.0.html
I need to use Display.setParent but this seems to crash on OSX. I can post the stacktrace, but first is it expected that Display.setParent works at this point? Not using it does work on Mac.
Edit, stacktrace:
...
Caused by: org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(Unknown Source)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(Unknown Source)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(Unknown Source)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(Unknown Source)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(Unknown Source)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(Unknown Source)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(Unknown Source)
at org.lwjgl.opengl.MacOSXDisplay.createWindow(Unknown Source)
at org.lwjgl.opengl.Display.createWindow(Unknown Source)
at org.lwjgl.opengl.Display.create(Unknown Source)
at org.lwjgl.opengl.Display.create(Unknown Source)
... 18 more
I've worked around it by using an LWJGL window instead of a Swing window on Mac. I also found the JavaApplicationStub no longer works for Java 7, by design. I used a shell script to launch Java. Screw you Apple!
New update:
Finally had a chance to test out JME3 with the OS X builds, found a number of issues which should now be fixed.
- implemented PBuffer support, fixes crash when using multisampling/AA with JME3, thx @cookies for finding and reporting.
- fixed an issue where the right side of title bar didn't allowing dragging after a window resize.
- fixed a crash on startup when creating a new Display after an old one has been destroyed in the same app.
- moved all the native Cocoa UI create/destroy code to the main thread, should fix the AppKit threading issues/crashes.
- a fix for a mouse grabbing issue by releasing mouse grab on Display destroy.
- fixed a resizing issues where incorrect Display size was being shown.
@refD - Mouse grabbing should be slightly improved now, do let know if you still have issues with it. There is a fix for a resizing problem, do test latest binary to see if you still get the issues you reported.
@norman - your second reported issue should hopefully be fixed now, as for the first issue, got a link to a test case that can reproduce the issue? maybe one of the jme3 engine tests?
@NateS - currently the OS X branch is based on LWJGL 2.8.5 so doesn't include the fixes for the windows control key issue yet but once merged into the main branch should be fixed (almost ready to do that). As for Display.setParent() it should work now (at least it does when tested with Minecraft), if zip below doesn't work do let me know (be nice if you had a small test case or example jar/app that can reproduce the issue).
Thx for testing and reporting issues.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Using latest, setDisplay still doesn't work:
Caused by: com.badlogic.gdx.utils.GdxRuntimeException: Unable to create OpenGL display.
at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.createDisplayPixelFormat(LwjglGraphics.java:220)
at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.setupDisplay(LwjglGraphics.java:181)
at com.badlogic.gdx.backends.lwjgl.LwjglCanvas.create(LwjglCanvas.java:184)
... 15 more
Caused by: org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:51)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:94)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:92)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:92)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:66)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:64)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXDisplay.createWindow(MacOSXDisplay.java:136)
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 com.badlogic.gdx.backends.lwjgl.LwjglGraphics.createDisplayPixelFormat(LwjglGraphics.java:216)
Running without setDisplay seems to work, but crashes sometimes when the app is closed by clicking the close button in the window title. Here are the crash files:
http://pastebin.com/5CJ1vipy
http://pastebin.com/6wbvKJgN
http://pastebin.com/KBg1mMA6
You know, I don't think it's by design that the JavaApplicationStub no longer works, so much as that Oracle is handling Java in a different way, and JavaApplicationStub isn't programmed to recognize it as a valid version of Java, being older and keyed to work specifically with Apple's version.
Minecraft does not work for me when I run it with Java 7, I get the exact same error I previously posted when I try to run it. It runs with Java 6 just fine, but I haven't ever had a problem with that even when I've used these. I provided a link a few posts back that can be used to get an updated launcher app for Minecraft that uses Java 7 instead of Java 6, due to the problem I mentioned in the first half of this post. Try running Minecraft with that instead of the regular app and see if you can successfully run it.
Minor update:
@pizza2004 & @NateS, I had an attempt to try fix the "Could not get the JAWT interface" when running on Java 7, hopefully it should be fixed now, unfortunately don't have access to OS X 10.7+ so can't test to confirm if it works.
Please do test and report any issues.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Quote from: pizza2004 on February 16, 2013, 12:36:16
You know, I don't think it's by design that the JavaApplicationStub no longer works, so much as that Oracle is handling Java in a different way, and JavaApplicationStub isn't programmed to recognize it as a valid version of Java, being older and keyed to work specifically with Apple's version.
http://lists.apple.com/archives/java-dev/2012/Apr/msg00115.html
Scott worked on Java for Apple and now for Oracle, so he's probably right.
@kappa, we've got to get you the latest. :(
I've got a user running OSX 10.7.5 that reports everything is fine until they resize the window, then it locks the whole machine:
http://www.esotericsoftware.com/forum/viewtopic.php?f=3&t=66
@NateS Right, he says it is intended behavior, but I don't think he means that they purposefully changed it so that JavaApplicationStub wouldn't work so much as that Apple won't allow Oracle to install Java 7 directly into the OS like Java 6 is, and because of this change the JavaApplicationStub can't find the copy of Java 7. I also don't think Apple is going to update JavaApplicationStub to be able to find Java 7 because they expect Oracle to take care of that sort of thing now. Hence why it is correct behavior, because JavaApplicationStub only applies to Apple's versions of Java.
@kappa That update doesn't seem to have changed anything at all. In fact, I have gotten the exact same error every time I tried to run Minecraft with this version of LWJGL using Java 7, despite the updates you've made.
@NateS - sounds like a driver crash, also came across it during development however did attempt a fix which worked at the time (at least for my driver) however apparently not for that mac user, anyway I've changed the way resizing works now with Display.setParent(), so shouldn't crash anymore.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Here are my crash reports attempting to launch Minecraft under Java 7
------------------ System Specs ------------------
Operating System: Mac OS X 10.8.2 (Darwin 12.2.0 x86_64)
Java Version: 1.7.0_13
Minecraft Version: 1.4.7
--------------------------------------------------
LWJGL Version: 2.4.2 (Minecraft's default)
----------------- Console Log ------------------
Instance started with command:
"/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/bin/java" -Xdock:icon=icon.png -Xdock:name="MultiMC: Minecraft 1.4.7 (Java 7)" -Xms1024m -Xmx1536m -jar MultiMCLauncher.jar "<username>" "<session ID>" "MultiMC: Minecraft 1.4.7 (Java 7)" "854x480" "Mojang"
Loading jars...
Loading URL: file:/Applications/Games/MultiMC.app/Contents/Resources/instances/Minecraft%201.4.7%20(Java%207)/minecraft/bin/minecraft.jar
Loading URL: file:/Applications/Games/MultiMC.app/Contents/Resources/instances/Minecraft%201.4.7%20(Java%207)/minecraft/bin/lwjgl.jar
Loading URL: file:/Applications/Games/MultiMC.app/Contents/Resources/instances/Minecraft%201.4.7%20(Java%207)/minecraft/bin/lwjgl_util.jar
Loading URL: file:/Applications/Games/MultiMC.app/Contents/Resources/instances/Minecraft%201.4.7%20(Java%207)/minecraft/bin/jinput.jar
Loading natives...
Fixed Minecraft Path: Field was private static java.io.File net.minecraft.client.Minecraft.an
Launching with applet wrapper...
27 achievements
210 recipes
Setting user: <username>, <session ID>
LWJGL Version: 2.4.2
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:49)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:89)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:86)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:64)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:53)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXContextImplementation.create(MacOSXContextImplementation.java:47)
at org.lwjgl.opengl.Context.<init>(Context.java:120)
at org.lwjgl.opengl.Display.create(Display.java:858)
at org.lwjgl.opengl.Display.create(Display.java:784)
at net.minecraft.client.Minecraft.a(SourceFile:223)
at asq.a(SourceFile:56)
at net.minecraft.client.Minecraft.run(SourceFile:515)
at java.lang.Thread.run(Thread.java:722)
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:49)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:89)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:86)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:64)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:53)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXContextImplementation.create(MacOSXContextImplementation.java:47)
at org.lwjgl.opengl.Context.<init>(Context.java:120)
at org.lwjgl.opengl.Display.create(Display.java:858)
at org.lwjgl.opengl.Display.create(Display.java:784)
at org.lwjgl.opengl.Display.create(Display.java:765)
at net.minecraft.client.Minecraft.a(SourceFile:232)
at asq.a(SourceFile:56)
at net.minecraft.client.Minecraft.run(SourceFile:515)
at java.lang.Thread.run(Thread.java:722)
LWJGL Version: 2.8.5 (kappa's latest experimental build as of 2/17/13)
----------------- Console Log ------------------
Instance started with command:
"/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/Contents/Home/bin/java" -Xdock:icon=icon.png -Xdock:name="MultiMC: Minecraft 1.4.7 (Java 7)" -Xms1024m -Xmx1536m -jar MultiMCLauncher.jar "<username>" "<session ID>" "MultiMC: Minecraft 1.4.7 (Java 7)" "854x480" "Mojang"
Loading jars...
Loading URL: file:/Applications/Games/MultiMC.app/Contents/Resources/instances/Minecraft%201.4.7%20(Java%207)/minecraft/bin/minecraft.jar
Loading URL: file:/Applications/Games/MultiMC.app/Contents/Resources/instances/Minecraft%201.4.7%20(Java%207)/minecraft/bin/lwjgl.jar
Loading URL: file:/Applications/Games/MultiMC.app/Contents/Resources/instances/Minecraft%201.4.7%20(Java%207)/minecraft/bin/lwjgl_util.jar
Loading URL: file:/Applications/Games/MultiMC.app/Contents/Resources/instances/Minecraft%201.4.7%20(Java%207)/minecraft/bin/jinput.jar
Loading natives...
Fixed Minecraft Path: Field was private static java.io.File net.minecraft.client.Minecraft.an
Launching with applet wrapper...
27 achievements
210 recipes
Setting user: <username>, <session ID>
LWJGL Version: 2.8.5
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:51)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:91)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:89)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:89)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:66)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:64)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXDisplay.createWindow(MacOSXDisplay.java:136)
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 net.minecraft.client.Minecraft.a(SourceFile:223)
at asq.a(SourceFile:56)
at net.minecraft.client.Minecraft.run(SourceFile:515)
at java.lang.Thread.run(Thread.java:722)
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:51)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:91)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:89)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:89)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:66)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:64)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXDisplay.createWindow(MacOSXDisplay.java:136)
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.lwjgl.opengl.Display.create(Display.java:736)
at net.minecraft.client.Minecraft.a(SourceFile:232)
at asq.a(SourceFile:56)
at net.minecraft.client.Minecraft.run(SourceFile:515)
at java.lang.Thread.run(Thread.java:722)
Great work, also good to see that the resize issue (which I had experienced since LWJGL 2.8.0) is fixed.
Everything is working great here. If you want to be picky then there is a couple of small issues/annoyances.
- Window resize is noticeably slower than previous LWJGL versions (in my case since it was broken throughout 2.8 until now, 2.7 and below on Java 6). I feel that it is struggling to keep up with the pace of the animation of maximising the window.
- Next time you launch the application (in my case, Minecraft), you will a snapshot of the state of the application when it was closed for a second before loading.
These are pretty low priority issues but are the only ones I've noticed so far.
Quote from: kappa on February 17, 2013, 15:21:21
@NateS - sounds like a driver crash, also came across it during development however did attempt a fix which worked at the time (at least for my driver) however apparently not for that mac user, anyway I've changed the way resizing works now with Display.setParent(), so shouldn't crash anymore.
With this on OSX using setParent, w/ Java 6 there seems to be a resizing issue (http://i.imgur.com/CUy3XFG.png). If I resize the window manually it works. On Java 7 it crashes. Without setParent it works on both.
Do you not have a Mac? Is this something we can remedy? Is there anything else I can do to help? I really need this to work and dorking around trying to fix Mac stuff, testing, etc causes my productivity to tank. :(
Edit: using latest experimental it crashes when I close the window on OSX, Java 7, no setParent:
http://pastebin.com/MCPSyxAV
http://pastebin.com/d9LzqcC6
@NateS thx for the close window crash reports, will have a look at getting that fixed for next update.
I had a go at running the Spine demo with the OS X experimental build but couldn't reproduce the resizing issues on Java 6, it all seemed to run nicely. Do have any more info on how to reproduce the resizing issue with setParent on Java 6, you mentioned that it works if resizing manually, what other methods of resizing are you using?
Quote from: NateS on February 19, 2013, 19:05:52
Do you not have a Mac? Is this something we can remedy? Is there anything else I can do to help?
Unfortunately the main problem is lack of time atm and only being able to hack at LWJGL for very short periods of time. Also only have OS X 10.6 atm once I get hold of a newer version of OS X will have a look into the Java 7/setParent issue.
Spine has two modes, the default on OSX currently being to run without setParent. To run it with setParent so you can see the crash and resizing issues, start it like this:
open -n ./Spine.app --args frameless
Can I buy you the latest OSX? Or link you to a torrent? ;) I'd offer to buy you a beer but don't want to cloud your coding skills until after you're done. ;) :D
Quote from: NateS on February 20, 2013, 00:21:28
Spine has two modes, the default on OSX currently being to run without setParent. To run it with setParent so you can see the crash and resizing issues, start it like this:
open -n ./Spine.app --args frameless
Can I buy you the latest OSX? Or link you to a torrent? ;) I'd offer to buy you a beer but don't want to cloud your coding skills until after you're done. ;) :D
Obviously you don't read XKCD: http://xkcd.com/323/
Also I'd like to throw in my own report that with the latest experimental of LWJGL I'm still getting the "Could not get the JAWT interface" error when I replace lwjgl.jar and the jnilib with the experimental version on OS X 10.8.2. (I'm not sure if it matters, but I don't remove any of the other .jars including AppleJavaExtensions.jar and whatnot, I just rename the old .jar/.jnilib and put the new one in its place) This is when using purely Display.create(), and without setParent. Also when using the experimental LWJGL on Java 6, the VM still crashes, like I reported before.
I was testing the latest version with jME application and it seems to work fine, for the SDK / canvas I get a similar exception as above, it ca be replicated with jME3's jme3test.canvas.TestCanvas test class. Looks like you're close though :)
JavaVM WARNING: JAWT_GetAWT must be called after loading a JVM
SEVERE Application 20:53:27 Failed to initialize OpenGL context
org.lwjgl.LWJGLException: Could not get the JAWT interface
at org.lwjgl.opengl.AWTSurfaceLock.lockAndInitHandle(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.access$100(AWTSurfaceLock.java:51)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:91)
at org.lwjgl.opengl.AWTSurfaceLock$1.run(AWTSurfaceLock.java:89)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.opengl.AWTSurfaceLock.privilegedLockAndInitHandle(AWTSurfaceLock.java:89)
at org.lwjgl.opengl.AWTSurfaceLock.lockAndGetHandle(AWTSurfaceLock.java:66)
at org.lwjgl.opengl.MacOSXCanvasPeerInfo.initHandle(MacOSXCanvasPeerInfo.java:64)
at org.lwjgl.opengl.MacOSXDisplayPeerInfo.doLockAndInitHandle(MacOSXDisplayPeerInfo.java:56)
at org.lwjgl.opengl.PeerInfo.lockAndGetHandle(PeerInfo.java:85)
at org.lwjgl.opengl.MacOSXDisplay.createWindow(MacOSXDisplay.java:136)
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 com.jme3.system.lwjgl.LwjglCanvas.createContext(LwjglCanvas.java:468)
at com.jme3.system.lwjgl.LwjglCanvas.restoreCanvas(LwjglCanvas.java:267)
at com.jme3.system.lwjgl.LwjglCanvas.runLoop(LwjglCanvas.java:196)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
at java.lang.Thread.run(Thread.java:722)
Just here to say thanks for your hard work. Carry on. ;)
Quote from: kappa on February 16, 2013, 01:00:19
@refD - Mouse grabbing should be slightly improved now, do let know if you still have issues with it. There is a fix for a resizing problem, do test latest binary to see if you still get the issues you reported.
Resizing is fixed, it no longer gets stuck.
Mouse grabbing & full screen issues persist.
Thanks for the update!
When connected to an external display, users report resizing via the green window button sometimes causes the display to mess up.
http://imgur.com/a/n2Gge
This is on a 15" Retina MacBook Pro with both Java 1.6.0_41 and also Java 7u15. An external Thunderbolt display is being used. When not plugged into the external monitor the problem does not occur.
I was searching around to see if there was a way to fix the error NateS and I seem to be getting about JAWT. I found this thread: http://lwjgl.org/forum/index.php?topic=4326.0 And what Dan said made me attempt to compile the natives on my own 10.7.5 computer to see if it would indeed fix the problem. I don't know if it's because I don't have his 'hacks' or just because I didn't set it up right, but even when I did manage to get it to compile against the JDK for 7 it still gave me the exact same error. Perhaps there's something to that though, I definitely think Kappa needs to get at least Lion, or Mountain Lion if he can ASAP so that he can test it with Java 7 himself. NateS, if you'll get that for him like you offered that would be great.
Yeah, I'd really like this to work. I'd get him a newer version of OSX, a (clean) hooker, whatever it takes, seriously! :)
A user has reported ctrl+? hotkeys sometimes don't work. Not sure if this is related to the fix in the latest LWJGL? When will the new Mac stuff be merged with the latest?
This could easily be because you're using a parented window and the parent eating those keypresses?
Also there could be global shortcuts setup so the keypresses simply do not reach your application.
Do they happen to be normal shortcuts the OS uses? like CTRL-C/V/A/X etc? :D
The user says ctrl+z and ctrl+s, but that they don't work most of the time. If he presses them many times eventually it works once.
I've done it! It took me an entire day of messing with the files, and it doesn't actually work well at all, but I was indeed able to compile it in a way that I could run it using Java 7! The downside to the way I did it being that it broke support for Java 6. Anyway, This brings up the next point. Fullscreen mode seemed to work fine other than being extremely slow, but Windowed mode was just black until I resized the window, and then it had weird problems with not aligning properly, and not detecting the size of the window properly. Plus the entire time I had it running it was just spewing out memory leaks or something to the console, which is definitely not a good sign. Anyway, what I had to do was modify it so it was looking at the libjawt.dylib and libawt.dylib instead of the JavaVM.framework, and that finally made it work, although Java 7 only comes in 64bit on Mac, so I'm not entirely sure how that should be handled. So yeah, I'd say we need to get Kappa a newer version of Mac so that we can have someone competent hacking at it instead of me. :P
While you're at it, how about retina support? Non-retina OpenGL looks awful.
I am from germany and playing around with jPCT.
my environment:
MBP 2010 i7 (german version, qwertz kb layout)
OSX 10.7.5 (german version)
I would like to assist your impressive work with a minor bug report.
It looks like the new keyboard handler doesn't take the keyboard layout into account.
e.g. y and z are inverted on qwertz
With Java 6 and the original lwjgl 2.8.5 release the 'y' keystroke is correct (on my german qwertz keyboard layout).
If I then replace the original libs with the libs provided from kappa (latest experimental build), the 'y' keystroke is wrong. The game code receives a 'z'.
And vice versa. Same "problem" (y<->z) with Java 6 and 7.
Let me know if I can assist with other tests on my environment. (full of expectations on the AWTGLCanvas stuff)
Quote from: UlfJack on February 26, 2013, 09:40:28
While you're at it, how about retina support? Non-retina OpenGL looks awful.
I don't know if that could be built directly into LWJGL, it seems like it's something that would need to be done by the program itself. I don't really know a ton java, or how retina display actually works, so I'm going to look into the issue and see if I can find anything about this.
Edit: Some preliminary searching shows Apple updated Java 6 to use native frameworks entirely a while ago (it avoids Sun2D) so it has no issue with it, however Java 7 does. I have little experience with programming, and none with Java, however, it seems like any attempt to get the standard function we have now in LWJGL that uses AWT in Java 7 will be more of a workaround than anything on Mac, and given Java 7 apparently doesn't support retina display, and it's difficult to tell if it will anytime soon, using Java 7 to run anything probably won't work. We should be able to get it running in the Apple version of Java 6, and there are a few places that talk about that:
http://apple.stackexchange.com/questions/53741/java-and-mac-retina-support
Question: Are there any plans for using the new OS X style of fullscreen, if possible?
Quote from: adamk33n3r on February 26, 2013, 19:49:08
Question: Are there any plans for using the new OS X style of fullscreen, if possible?
This is something that was built into one of the releases of Java when Lion came out. I don't know if LWJGL should have support for this or not (that's something only the devs should/can decide), but you can definitely put this together in your own application right now if you use Display.setParent. This SO question should give you all the information you need to know: http://stackoverflow.com/questions/12751704/how-to-have-a-jframe-maximise-icon?lq=1
Wait, I just noticed, Java 7 uses dylib by default now instead of jnilib. Based on the fact that when I finally did get it to load with Java 7 the old jnilib format still works, but I'm wondering if maybe we could build a 64 bit Java 7 version as dylib after we build the Java 6 32/64 bit versions. Also, I don't think it's been mentioned, but Java 7 on Mac does not have a 32 bit version, this could possibly be because a 64 bit processor is required in OSX Lion and up, so there wouldn't be much point in releasing a 32 bit version for platforms that require 64 bit anyway.
Here's the second issue: By default, LWJGL is going to want the full JDK installed on Mac in order to run with Java 7, due to the differences in how Java 7 is implemented on Mac versus Java 6. Basically, installing the JRE seems to only install a copy of the internet plugin, which is located in a different place than the JDK, and you have to build against a specific location for the libraries to sit otherwise it won't know where they are. The main problem being that I also don't have any idea how to package the JRE with LWJGL in a way that allows it to work like it needs to. I'll keep looking at things to see if there is another way, but I'm not sure if I'll have any results.
Quote from: pizza2004 on February 26, 2013, 19:14:37
Edit: Some preliminary searching shows Apple updated Java 6 to use native frameworks entirely a while ago (it avoids Sun2D) so it has no issue with it, however Java 7 does. I have little experience with programming, and none with Java, however, it seems like any attempt to get the standard function we have now in LWJGL that uses AWT in Java 7 will be more of a workaround than anything on Mac, and given Java 7 apparently doesn't support retina display, and it's difficult to tell if it will anytime soon, using Java 7 to run anything probably won't work. We should be able to get it running in the Apple version of Java 6, and there are a few places that talk about that:
http://apple.stackexchange.com/questions/53741/java-and-mac-retina-support
While you're right that AWT and Swing support rendering on a retina display (though it is not possible to detect reliably whether retina is en- or disabled, so no sharp images or double-buffering), OpenGL appears to be a different story. Apparently, you can only get high-DPI rendering with OpenGL using CocoaGL, and you need to enable it explicitly with setWantsBestResolutionOpenGLSurface (whatever that means, exactly):
http://www.opengl.org/discussion_boards/showthread.php/178916-Using-the-retina-display-on-a-macbook-pro
Also see:
http://markmail.org/message/ceydhtlvzes7geqw
http://lists.apple.com/archives/java-dev/2012/Jul/msg00010.html
@UlfJack Well, but aren't we reworking it to use Native Cocoa now instead of having to rely on Java things? So wouldn't that work anyway? Isn't what you're saying a good thing? Why does it sounds like your saying it in a letting us down kind of way...
I seriously don't understand. Why does there need to be special support for retina displays. They are not magic, just high resolution. Opengl should have no issue with that.
Since i am now somewhat forced to work on a mac for a while, I am much more interested in the state of the mac support. Since we all have retina displays, it kinda needs to work with them. But then again the fill rate of the cards tends to be on the low side for such resolutions IMO.
Also the term retina is terrible.
@delt0r The reason there has to be special support is due to the way OS X handles retina display. By default it uses 1/2 the actual resolution, and just tells the operating system to treat the display like every 4 pixels are one pixel. It knows the difference however, and it's possible to bypass this, by using .5 instead of 1 to refer to an individual pixel. So yeah, the reason it needs special support is because you have to tell your program it's 2x the resolution that you're program can see and then output things to half pixels instead of regular pixels. I'm not even sure what happens if the people decide they want to use one of the 3 or 4 other scaling options available through retina displays.
Sounds totally retarded. Why would they do that. Its not even like they are that high a resolution.
Still I never need to consider pixels with opengl. I just care about polys. Sounds like there is almost hardware abstraction.
I wouldn't say totally silly, it's so that programs stay the same size instead of becoming tiny on your display. So basically, first you have to tell the OS you're capable of displaying in HiDPI, and then you have to act like you're printing to 1/4 size pixels to hit the actual pixels. I think it's so the system doesn't have to try to interpret things several different ways just because one program is high resolution and one isn't, it just has to act like 1 equals 4 pixels instead of just one, and 1/4 equals one pixel. Is it the best way to handle things from a developer point of view? Probably not. It still makes some sense though.
Surely a getDPI() api call would have been more sensible. Then we could simply choose what to do ourselves. There are three two metrics for a display: its resolution, and its density. So perhaps getDPI() would be an extremely useful addition to LWJGL; and we'd return actual physical pixel sizes from getWidth()/getHeight() under any OS.
Cas :)
[ot]
[rant]
I write all my programs to be as resolution independent as possible. What the hell a TT Fonts for if not to be resolution independent! its 2013 and we need a different version of every app for different screen resolutions? seriously?
[/rant]
[/ot]
rant away but this isn't lwjgl's fault its apple's and the way it implements its OpenGL canvas.
There is a simple fix though
https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW33 (https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html#//apple_ref/doc/uid/TP40012302-CH10-SW33)
Its just adding
[self setWantsBestResolutionOpenGLSurface:YES];
To the NSOpenGLView implementation
Quote from: UlfJack on February 26, 2013, 09:40:28
While you're at it, how about retina support? Non-retina OpenGL looks awful.
Retina support should be relatively easy to add. It uses new OS X 10.7+ API's so we'll have to bump the minimum requirements for compiling LWJGL from OS X 10.6 to 10.7 and carefully code around those API's so it all still works on OS X 10.5 and 10.6.
As its an OS X only feature and something you need to opt-in to use might be better to add it as a LWJGL switch (http://www.lwjgl.org/wiki/index.php?title=LWJGL_Hidden_Switches) instead of a new API, so users that need it can just toggle it on.
A rather messy issue with implementing retina support is when switching it on the high resolution mode only applies to the OpenGL context (normally 4x the normal pixel size but not guaranteed to be so and can change in future). The size used by the windowing API's (Cocoa/Quartz, etc) still remains the original non retina pixel size, so API calls like Display.getWidth(), Display.getHeight(), Mouse.getX(), Mouse.getY(), etc won't match the context size (often used in calls like glViewport, glScissor, glReadPixels, glTexImage2D, etc).
So its either we manually convert/scale the values of the LWJGL API calls internally when retina mode is switched on so Display.getWidth()/getHeight(), Mouse.getX()/getY(), etc) return correct high res values or we add a new API which provides a scale or size of the context to the user so they can do the conversions themselves (IMO its a bit ugly to add an API into LWJGL which is platform specific).
Anyway do think that retina support should be in a separate RFE and probably something we should focus on after getting this RFE done (and the LWJGL 2.9 release) as its more important to get a working OS X version of LWJGL out before going for more features.
QuoteAnyway do think that retina support should be in a separate RFE and probably something we should focus on after getting this RFE done (and the LWJGL 2.9 release) as its more important to get a working OS X version of LWJGL out before going for more features.
I agree completely. Steady Stable and Solid now without retina, is better than issues on both newer and older macs.
Quote from: delt0r on March 01, 2013, 12:02:15
[ot]
[rant]
I write all my programs to be as resolution independent as possible. What the hell a TT Fonts for if not to be resolution independent! its 2013 and we need a different version of every app for different screen resolutions? seriously?
[/rant]
[/ot]
As near as I can tell, for something as simple as using fonts you can just act like it's the regular resolution and Mac makes it all nice and double resolution for you. I think the only time you have to be more specific about the resolution is when you're doing something like rendering using OpenGL instead of just using UI elements, but it's really hard to get a clear answer about how that works just by searching the internet.
Edit: @kappa Yay! It's been far too long since we heard from you last. You should get in contact with NateS about upgrading your version of Mac. Also, I'd love to see your opinion on the other things we've been talking about lately.
Sorry for double posting, but where did everyone go? There hasn't been an update to the code since February 20, so it's approaching a month with no change. And we haven't even had a post in this thread for over 10 days now. Any update on what's going on?
I am using it daily on osx for some dev work and have had no issues at all. Also kappa is quite busy.
I would be happy to install coda or whatever its called and help. But i am also busy and I haven't done any mac dev work since the macintosh 512. It had 512k or ram!
Apologies for the recent lack of activity, just had very little free time.
Anyway new update:
- Implemented AWTGLCanvas
- fixed a glViewport issue when using Display.setParent as reported by NateS (stretched Display on startup).
Support for AWTGLCanvas was the last missing feature in the new OS X backend, which means the OS X branch is now ready to be merged into the main LWJGL branch (probably tonight)(now merged with master).
The last stopper for the LWJGL 2.9 release is the JAWT+Java 7 issue (seems pizza2004 had some luck with it (http://lwjgl.org/forum/index.php/topic,4711.msg26431.html#msg26431)). I took a detour trying to get OS X 10.8 working on VMWare/VirutalBox, it all worked nicely including Apple's Java 6 but apparently Oracle's Java 7 doesn't work at all there!!! see here (http://communities.vmware.com/thread/422493?tstart=0)and here (https://forums.oracle.com/forums/thread.jspa?threadID=2477369&tstart=0). Anyway should be getting access to a proper OS X 10.8 setup soon so will get a chance to look at the issue.
Anyway thx for testing and reporting issues.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Hi Kappa, thanks for posting an update. I still get the "JAWT_GetAWT must be called after loading a JVM" issue, so I'll have to wait for that fix before I can test it properly for applets. Also, I still get the cursor issue (apologies - I don't think I replied to your earlier question). We're just using a standard AWT Cursor as far as I can tell.
Quote from: ajr_1 on March 14, 2013, 11:44:13
Hi Kappa, thanks for posting an update. Also, I still get the cursor issue (apologies - I don't think I replied to your earlier question). We're just using a standard AWT Cursor as far as I can tell.
Hi thanks for testing, unfortunately can't reproduce the cursor issue, is it possible you could create a quick small test that reproduces the issue? should make it a lot easier to pin point and fix.
Also you using Display.setParent or just the native Display? and which version of OS X are you on?
I'll try to get a test case set up. I'm on OS X 10.8.2, using AWTGLCanvas. It's a Retina display, so not sure if that would make any difference.
EDIT: Also, it can be intermittent - I've run my app a couple of times and it's been fine, but the majority of the time it has the issue.
Quote from: ajr_1 on March 15, 2013, 09:33:12
I'll try to get a test case set up. I'm on OS X 10.8.2, using AWTGLCanvas. It's a Retina display, so not sure if that would make any difference.
Oh you're using AWTGLCanvas, which means that its not actually LWJGL loading and displaying the cursor but AWT (which completely bypasses LWJGL). LWJGL only does native cursor handling when using the native Display with its Mouse.setNativeCursor() method.
Just curious, AWTGLCanvas support was only implemented yesterday in the new branch, how were to you able to reproduce the above over a month ago? using another LWJGL method?
Sorry, had a bit of a brain freeze there, thinking about applets but typing about the application. We run as both an applet with AWTGLCanvas, and application using the native display. Both are created using JME2. It was the application that I'm having the cursor issues with.
I downloaded lwjgl-2.8.5 and unzipped it and moved it to ~/work/lwjgl. I also grabbed src and docs.
I unzipped kappa's latest from above, putting lwjgl.jar in ./jar and the others in ./native/macosx
I ran the test program as described in the wiki
java -cp .:res:jar/lwjgl.jar:jar/lwjgl_test.jar:jar/lwjgl_util.jar:jar/jinput.jar: -Djava.library.path=native/macosx org.lwjgl.test.WindowCreationTest
The program responded with
The following keys are available:
ESCAPE: Exit test
ARROW Keys: Move window when in non-fullscreen mode
L: List selectable display modes
0-8: Selection of display modes
F: Toggle fullscreen
SHIFT-F: Toggle fullscreen with Display.destroy()/create() cycle
Found 34 display modes
Problem retrieving mode with 640x480x24@-1
Problem retrieving mode with 800x600x24@-1
Problem retrieving mode with 1024x768x24@-1
The program opened a window and is pulsing between white and black.
When I clicked the red close button, the program seg faults. If I use esc to exit, it exits normally.
# SIGSEGV (0xb) at pc=0x00007fff8d39de90, pid=96505, tid=8967
#
# JRE version: 7.0_17-b02
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.7-b01 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libobjc.A.dylib+0x9e90] objc_msgSend+0x10
Environment:
╭─skelter@macbook-pro-2 ~/work/lwjgl-2.8.5
╰─$ uname -a 134 ↵Darwin charles-suehss-macbook-pro-2.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
╭─skelter@macbook-pro-2 ~/work/lwjgl-2.8.5
╰─$ java -version
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
╭─skelter@charles-suehss-macbook-pro-2 ~/work/lwjgl-2.8.5
╰─$ javac -version
javac 1.7.0_17
If there is any other info about my system I can provide, please let me know.
If there is another version I can test, I'm willing to give it a try.
Thank y'all for working on it.
Finally got access to OS X 10.8 (and hence Java 7).
New update:
- Fixed the now infamous "Could not get the JAWT interface" exception when running on Java 7.
- Fixed crash on exit on Java 7 as reported by @skelter above.
- Tiny bit of clean up and removed dependancies on some unused frameworks.
- Broke and then re-fixed builds on the new nightly build server (http://ci.newdawnsoftware.com/) :)
The native Display should now run pretty well on OSX and Java 7 (no more JAWT exceptions!), unfortunately AWT on Java 7 has some behaviour changes with the way it works so Display.setParent/AWTGLCanvas isn't behaving correctly yet and needs some more fixing. Getting very close to the LWJGL 2.9 release now.
Anyway thx for testing and reporting issues.
Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip
Latest nightly builds of the upcoming LWJGL 2.9.0 can be found here: http://ci.newdawnsoftware.com/job/LWJGL-git-dist/
Great work on getting rid of that exception! It's nice to actually have my program start in Java 7 now ;D
That said, I do have several bug reports:
Assume all following bugs use the native Display:
- When the Display is resizable, the moment that it is resized I seem to "lose" the framebuffer. Calling glClear or even glCheckFramebufferStatus throws "Invalid framebuffer operation". The stable version of LWJGL does not have this happen.
- With an OpenGL 3.2 setup, I can't see the cube that I'm currently drawing. When I switched back to the stable version, I can again see it. I have no idea how to even begin providing information for debugging this. My current code that I am working on is at: https://github.com/Freezerburn/cmsc425-engine (https://github.com/Freezerburn/cmsc425-engine). (if you DO look at the code, the main stuff is in game.Project1, game.shaders.fragcolor.glsl, game.shaders.vertexcolor.glsl)
- I will, occasionally, get this error:
Quote#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fff88e0a250, pid=30996, tid=5891
#
# JRE version: 7.0_10-b18
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.6-b04 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libobjc.A.dylib+0x6250] objc_msgSend+0x10
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/freezerburn/Dropbox/cmsc425-project2/hs_err_pid30996.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
I do not know what is causing it though. Possibly by attempting to destroy the window too quickly.
Assume the following bugs use setParent with a simple Frame:
- I get a similar error for resizing here, but instead with glUseProgram (same invalid framebuffer exception)
- Similarly to the native Display, I still do not see anything that I am drawing.
- Occasionally, the OpenGL component seems to fail to attach to the Frame, causing a "window" that is 0 width and 0 height. Resizing when this happens causes no errors, but destroying the window caused this:
Quote#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fff88e0a24c, pid=31080, tid=5891
#
# JRE version: 7.0_10-b18
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.6-b04 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C [libobjc.A.dylib+0x624c] objc_msgSend+0xc
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/freezerburn/Dropbox/cmsc425-project2/hs_err_pid31080.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
And I believe those are all of the problems that I have observed so far.
Thanks for the latest build kappa. I've got a major issue with running it on Java 6 though - when I load it as an applet (in Eclipse), then close it down with the red x button at the top left it causes the computer to crash out with a full restart.
I get a crash report when OS X restarts, not sure if it's of much use:
Interval Since Last Panic Report: 66312 sec
Panics Since Last Report: 2
Anonymous UUID: D91619B8-7DB3-882E-F46B-8D8BD4C9635F
Wed Mar 27 10:56:17 2013
panic(cpu 2 caller 0xffffff802dab7e95): Kernel trap at 0xffffff7faf1f0a38, type 14=page fault, registers:
CR0: 0x0000000080010033, CR2: 0x00000000000089f4, CR3: 0x000000005bed5002, CR4: 0x00000000001606e0
RAX: 0x0000000020000103, RBX: 0x00000000000000fc, RCX: 0x0000000000000000, RDX: 0xffffff81f26161e0
RSP: 0xffffff8201c8b8e0, RBP: 0xffffff8201c8b910, RSI: 0x0000000000000000, RDI: 0x0000000000000000
R8: 0xffffff81f26a6000, R9: 0x0000000000010000, R10: 0x0000000000000012, R11: 0x0000000000000001
R12: 0xffffff81cf292813, R13: 0xffffff81cf28e000, R14: 0xffffff8201c8ba28, R15: 0x0000000000000000
RFL: 0x0000000000010202, RIP: 0xffffff7faf1f0a38, CS: 0x0000000000000008, SS: 0x0000000000000010
Fault CR2: 0x00000000000089f4, Error code: 0x0000000000000000, Fault CPU: 0x2
Backtrace (CPU 2), Frame : Return Address
0xffffff8201c8b580 : 0xffffff802da1d626
0xffffff8201c8b5f0 : 0xffffff802dab7e95
0xffffff8201c8b7c0 : 0xffffff802dacd4dd
0xffffff8201c8b7e0 : 0xffffff7faf1f0a38
0xffffff8201c8b910 : 0xffffff7faf1bc34f
0xffffff8201c8ba90 : 0xffffff7faf1ece39
0xffffff8201c8bb50 : 0xffffff7faf1bade8
0xffffff8201c8bba0 : 0xffffff802de650c9
0xffffff8201c8bbc0 : 0xffffff802de66670
0xffffff8201c8bc20 : 0xffffff802de6408f
0xffffff8201c8bd70 : 0xffffff802da984a1
0xffffff8201c8be80 : 0xffffff802da20aed
0xffffff8201c8beb0 : 0xffffff802da10448
0xffffff8201c8bf00 : 0xffffff802da1961b
0xffffff8201c8bf70 : 0xffffff802daa5dd6
0xffffff8201c8bfb0 : 0xffffff802dacdd43
Kernel Extensions in backtrace:
com.apple.GeForce(8.1)[A15BB65E-3501-340F-87CB-2FD2BAD33E35]@0xffffff7faf1a9000->0xffffff7faf275fff
dependency: com.apple.NVDAResman(8.1.0)[A26D2A3D-C06F-3A0F-BCFF-901A98C93C3D]@0xffffff7fae116000
dependency: com.apple.iokit.IONDRVSupport(2.3.7)[38C214C0-83C8-3594-8A4C-DC6AC3FEC163]@0xffffff7fae102000
dependency: com.apple.iokit.IOPCIFamily(2.7.3)[1D668879-BEF8-3C58-ABFE-FAC6B3E9A292]@0xffffff7fae081000
dependency: com.apple.iokit.IOGraphicsFamily(2.3.7)[74E3E50F-E50A-3073-8C96-06F854292A91]@0xffffff7fae0bf000
BSD process name corresponding to current thread: java
Mac OS version:
12D78
Kernel version:
Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64
Kernel UUID: 3EB7D8A7-C2D3-32EC-80F4-AB37D61492C6
Kernel slide: 0x000000002d800000
Kernel text base: 0xffffff802da00000
System model name: MacBookPro10,1 (Mac-C3EC7CD22292981F)
System uptime in nanoseconds: 92806479431
last loaded kext at 13498973302: com.apple.driver.AppleBluetoothHIDKeyboard 170.2 (addr 0xffffff7fafaaf000, size 24576)
loaded kexts:
com.sophos.kext.sav 8.0.4
com.apple.driver.AppleBluetoothMultitouch 75.19
com.apple.filesystems.msdosfs 1.8
com.apple.driver.AppleHWSensor 1.9.5d0
com.apple.driver.AudioAUUC 1.60
com.apple.iokit.IOBluetoothSerialManager 4.1.3f3
com.apple.filesystems.autofs 3.0
com.apple.driver.ApplePlatformEnabler 2.0.6d1
com.apple.driver.AGPM 100.12.87
com.apple.driver.X86PlatformShim 1.0.0
com.apple.driver.AppleMikeyHIDDriver 122
com.apple.driver.AppleHDAHardwareConfigDriver 2.3.7fc4
com.apple.driver.AppleHDA 2.3.7fc4
com.apple.GeForce 8.1.0
com.apple.iokit.IOUserEthernet 1.0.0d1
com.apple.iokit.IOBluetoothUSBDFU 4.1.3f3
com.apple.driver.ACPI_SMC_PlatformPlugin 1.0.0
com.apple.Dont_Steal_Mac_OS_X 7.0.0
com.apple.iokit.BroadcomBluetoothHCIControllerUSBTransport 4.1.3f3
com.apple.driver.AppleSMCLMU 2.0.3d0
com.apple.driver.AppleMikeyDriver 2.3.7fc4
com.apple.nvidia.NVDAStartup 8.1.0
com.apple.driver.AppleUpstreamUserClient 3.5.10
com.apple.driver.AppleSMCPDRC 1.0.0
com.apple.driver.AppleLPC 1.6.0
com.apple.driver.ApplePolicyControl 3.3.0
com.apple.driver.AppleBacklight 170.2.5
com.apple.driver.AppleMCCSControl 1.1.11
com.apple.driver.AppleIntelHD4000Graphics 8.1.0
com.apple.driver.AppleIntelFramebufferCapri 8.1.0
com.apple.driver.AppleMuxControl 3.3.0
com.apple.driver.AppleUSBTCButtons 237.1
com.apple.driver.AppleUSBTCKeyEventDriver 237.1
com.apple.driver.AppleUSBTCKeyboard 237.1
com.apple.driver.AppleFileSystemDriver 3.0.1
com.apple.AppleFSCompression.AppleFSCompressionTypeDataless 1.0.0d1
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib 1.0.0d1
com.apple.BootCache 34
com.apple.driver.XsanFilter 404
com.apple.iokit.IOAHCIBlockStorage 2.3.1
com.apple.driver.AppleUSBHub 5.5.5
com.apple.driver.AppleSDXC 1.4.0
com.apple.iokit.AppleBCM5701Ethernet 3.6.0b1
com.apple.driver.AirPort.Brcm4331 614.20.16
com.apple.driver.AppleAHCIPort 2.5.1
com.apple.driver.AppleUSBEHCI 5.5.0
com.apple.driver.AppleUSBXHCI 5.5.5
com.apple.driver.AppleEFINVRAM 1.7
com.apple.driver.AppleSmartBatteryManager 161.0.0
com.apple.driver.AppleRTC 1.5
com.apple.driver.AppleACPIButtons 1.7
com.apple.driver.AppleHPET 1.8
com.apple.driver.AppleSMBIOS 1.9
com.apple.driver.AppleACPIEC 1.7
com.apple.driver.AppleAPIC 1.6
com.apple.driver.AppleIntelCPUPowerManagementClient 196.0.0
com.apple.nke.applicationfirewall 4.0.39
com.apple.security.quarantine 2
com.apple.driver.AppleIntelCPUPowerManagement 196.0.0
com.apple.driver.AppleBluetoothHIDKeyboard 170.2
com.apple.driver.AppleHIDKeyboard 170.2
com.apple.driver.IOBluetoothHIDDriver 4.1.3f3
com.apple.driver.AppleMultitouchDriver 235.29
com.apple.iokit.IOSerialFamily 10.0.6
com.apple.kext.triggers 1.0
com.apple.iokit.IOSCSIArchitectureModelFamily 3.5.5
com.apple.driver.DspFuncLib 2.3.7fc4
com.apple.iokit.IOAudioFamily 1.8.9fc11
com.apple.kext.OSvKernDSPLib 1.6
com.apple.nvidia.gk100hal 8.1.0
com.apple.NVDAResman 8.1.0
com.apple.iokit.IOSurface 86.0.4
com.apple.iokit.IOBluetoothFamily 4.1.3f3
com.apple.driver.IOPlatformPluginLegacy 1.0.0
com.apple.iokit.AppleBluetoothHCIControllerUSBTransport 4.1.3f3
com.apple.driver.X86PlatformPlugin 1.0.0
com.apple.driver.AppleSMBusPCI 1.0.11d0
com.apple.driver.IOPlatformPluginFamily 5.3.0d51
com.apple.driver.AppleSMBusController 1.0.11d0
com.apple.driver.AppleHDAController 2.3.7fc4
com.apple.iokit.IOHDAFamily 2.3.7fc4
com.apple.iokit.IOAcceleratorFamily 30.14
com.apple.driver.AppleGraphicsControl 3.3.0
com.apple.driver.AppleBacklightExpert 1.0.4
com.apple.iokit.IONDRVSupport 2.3.7
com.apple.iokit.IOGraphicsFamily 2.3.7
com.apple.driver.AppleSMC 3.1.4d2
com.apple.driver.AppleThunderboltEDMSink 1.1.8
com.apple.driver.AppleThunderboltEDMSource 1.1.8
com.apple.driver.AppleThunderboltDPOutAdapter 1.8.9
com.apple.driver.AppleUSBMultitouch 237.3
com.apple.iokit.IOUSBHIDDriver 5.2.5
com.apple.driver.AppleUSBMergeNub 5.5.5
com.apple.driver.AppleUSBComposite 5.2.5
com.apple.driver.AppleThunderboltDPInAdapter 1.8.9
com.apple.driver.AppleThunderboltDPAdapterFamily 1.8.9
com.apple.driver.AppleThunderboltPCIUpAdapter 1.2.6
com.apple.driver.AppleThunderboltPCIDownAdapter 1.2.6
com.apple.driver.AppleThunderboltNHI 1.6.3
com.apple.iokit.IOThunderboltFamily 2.2.6
com.apple.iokit.IOEthernetAVBController 1.0.2b1
com.apple.iokit.IO80211Family 522.4
com.apple.iokit.IONetworkingFamily 3.0
com.apple.iokit.IOUSBUserClient 5.5.5
com.apple.iokit.IOAHCIFamily 2.3.1
com.apple.iokit.IOUSBFamily 5.5.5
com.apple.driver.AppleEFIRuntime 1.7
com.apple.iokit.IOHIDFamily 1.8.1
com.apple.iokit.IOSMBusFamily 1.1
com.apple.security.sandbox 220.2
com.apple.kext.AppleMatch 1.0.0d1
com.apple.security.TMSafetyNet 7
com.apple.driver.DiskImages 345
com.apple.iokit.IOStorageFamily 1.8
com.apple.driver.AppleKeyStore 28.21
com.apple.driver.AppleACPIPlatform 1.7
com.apple.iokit.IOPCIFamily 2.7.3
com.apple.iokit.IOACPIFamily 1.4
com.apple.kec.corecrypto 1.0
Model: MacBookPro10,1, BootROM MBP101.00EE.B02, 4 processors, Intel Core i7, 2.6 GHz, 16 GB, SMC 2.3f35
Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 512 MB
Graphics: NVIDIA GeForce GT 650M, NVIDIA GeForce GT 650M, PCIe, 1024 MB
Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434314753364D465238432D50422020
Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434314753364D465238432D50422020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xEF), Broadcom BCM43xx 1.0 (5.106.98.100.16)
Bluetooth: Version 4.1.3f3 11349, 2 service, 18 devices, 1 incoming serial ports
Network Service: Thunderbolt Ethernet, Ethernet, en2
Network Service: Wi-Fi, AirPort, en0
PCI Card: Apple 57762-A0, sppci_ethernet, Thunderbolt@10,0,0
Serial ATA Device: APPLE SSD SM512E, 500.28 GB
USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1a100000 / 2
USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8510, 0x1a110000 / 3
USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1d100000 / 2
USB Device: hub_device, 0x0424 (SMSC), 0x2512, 0x1d180000 / 3
USB Device: BRCM20702 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x1d181000 / 5
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8286, 0x1d181300 / 6
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0263, 0x1d182000 / 4
With Java 7, the applet starts loading, and I don't get any errors, but it doesn't fully load. Not sure what's happening exactly, but I'll investigate further in case it's an issue at my end.
thanks people for all the testing will try to fix as many of those as possible.
@ajr_1 yeh noticed the applet close button crash thing, its caused by a driver crash (and hence a system crash) will be fixing that urgently.
Just further to that last message, it looks like the applet is fully loaded, but it's just not displaying anything. If I click the mouse, drag it about etc I get the debug feedback that I should be getting. Could be the AWT display issues you were referring to before I guess.
I've also seen the applet issue, seems like some odd new behaviour with Java 7, if you resize the applet then it starts displaying. Will have to look into why it happens only with Java 7 and not Java 6.
I just created an account to thank you guys for your hard work. I installed Java 7 on OS X 10.6.8 (Snow Leopard) using Pacifist. I also installed the latest nightly build of lwjgl-2.9.0-SNAPSHOT from the jenkins server. Since I'm using Maven, I manually copied over all of the dependencies and pom's to my local m2 repo, renaming them as appropriate. It's working great so far.
I'm also using NiftyGui, which seems unaffected by these changes.
Keep up the great work!
@Freezerburn unfortunately not been able to reproduce your issues, what would help is if you could make small single class test cases that reproduces them.
@ajr_1 the not displaying anything when using Display.setParent on Java 7 should be fixed now in the nightly builds. Still looking into the driver crash on close issue.
Hi kappa, that seems to be working now! Once the crash issue is done and I've sorted my mouse issue then I should be good to go. Thanks for all the hard work you've put in.
Kappa is my hero
@kappa don't forget my offer of a gift :)
Cas :)
New update:
- Fixed OpenAL-Soft for 32bit macs and updated to latest OpenAL-Soft 1.15.1+ (which also addresses a few issues).
- Implemented workaround to fix the setParent/AWTGLCanvas OS crash on exist. Turned out to actually be a nasty Nvidia driver bug, so likely can remove the workaround once Nvidia releases a fix.
- Fixed a crash that sometimes occurred when setting Display.setTitle().
- Fixed another Java 7 only crash with OSX/CALayer's when switching to/from fullscreen.
- Implemented cleaning up of Display.setParent/AWTGLCanvas resources on exit.
- Fix an AWTGLCanvas resize issue on Java 7.
- Fix no scroll wheel events when shift key is held down (thx to Grum for reporting).
Latest nightly builds can be found here:
http://ci.newdawnsoftware.com/job/LWJGL-git-dist/
We've reached a point where LWJGL 2.9.0 is now ready to go, so a release should follow shortly. I'm aware that there may be a few small niggles that remain but we'll get those in subsequent LWJGL 2.9.x releases, so do please keep testing and reporting. There are also plans to add support for HiDPI retina mode and OS X's new fullscreen api where fullscreen apps get their own 'space'.
Anyway special thanks to the LWJGL community, all the contributors and testers (you know who you are) that allowed us to get to this point.
Hello,
I have been reading about the problems with java 7 on the mac.
I recently tried to get our in house editor (which uses lwjgl) to run on a mac and have been having problems with the AWTGLCanvas.
The canvas always seems to draw in the bottom left of the main window and calling repaint() does not seem to update the canvas (see included screenshot).
We have been using this editor on the PC for years without any issues and only recently have I needed to get it working on a mac (dam artists!).
The editor requires java 1.7 features unfortunately so I have to get it working.
I am not sure if this is a bug with lwjgl or something that I am doing wrong on the mac side of things.
Any insights into what I might need to do to fix the canvas would be appreciated.
thx for reporting, will look into it tonight and see if I can reproduce it.
edit: I have been able to reproduce this problem, currently working on a fix.
Turns out the above is actually a Mac Java 7 bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187
Suggested fix is to use Java 8 ???
Your nightly builds link appears to be broken. It doesn't work for me at all.
Looks fine to me
*whistles innocently*
Endolf
Quote from: kappa on April 18, 2013, 22:47:42
Turns out the above is actually a Mac Java 7 bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187
Suggested fix is to use Java 8 ???
Thanks for having a look! I have been trying different versions of java, see if I can work around the problem ^_^
Quote from: DanDanger on April 20, 2013, 08:24:30
Quote from: kappa on April 18, 2013, 22:47:42
Turns out the above is actually a Mac Java 7 bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187
Suggested fix is to use Java 8 ???
Thanks for having a look! I have been trying different versions of java, see if I can work around the problem ^_^
I've implemented a fix to workaround the Java 7 bug, so should work now.
Do test the next nightly build (http://ci.newdawnsoftware.com/job/LWJGL-git-dist/) and report any issues that you may have.
Tested your latest build with the latest jMonkeyEngine nightly and Java 7u21 on OS X 10.8.3 and everything works fantastically now. Thanks a lot for your efforts!
Hello
Thanks for fixing it for OSX. I tried out the nightly build and i think it works more or less. Is it correct that the java.awt.Canvas is the fastest "Display" component which allows swing integration? Because maximum FPS is like 20 which isn't enough to display a video in a modern way.Can you give me any hints how i can increase performance? I already tried using a JavaFX/swing combination the result isn't as bad but still not as super fast as OpenGL used to be :) The same machine was able to play FullHD MP4 video with 50 fps in fullscreen with JOGL1 and Java6 (on OSX 10.7 using swing).
Thanks for your help and great work!
Regards,
Martin
@norman thank for the report will have a look to see if I can reproduce and hopefully get a fix up.
@schwaller, unfortunately due to the changes made by Apple/Oracle to AWT/Swing (moving from NSView to CALayer embedding and removing NSView option altogether) its no longer technically possible to get the speeds with OpenGL we previously enjoyed with JOGL and LWJGL (2.8.5 and lower). This is because content needs to be drawn at least twice due to the way CALayers work. JavaFX is likely to run into the same issue when using a third party OpenGL binding. The fastest OpenGL option would be to use the native Display window instead, you could use one of the a feature rich OpenGL GUI systems like TWL or Nifty (http://www.lwjgl.org/wiki/index.php?title=Game_Engines_and_Libraries_Using_LWJGL#GUI_Libraries) to replace the AWT/Swing bits (impressively Eclipse has been ported to run on TWL! which shows how capable and mature the library can be). If you still want to go for AWT/Swing for the gui you could try the separate window option where you have separate controls window (AWT/Swing) and a separate native Display window for the video rendering (like VLC media player).
Thanks @Kappa,
I'm still undergoing deep testing with my bitty OpenGL app, but the initial display errors already reported seem to have been taken care of by your changes.
*cheers*
Quote from: kappa on April 23, 2013, 16:33:18
Eclipse has been ported to run on TWL!
Where did you see this? I want to see it! I am using TWL and it is fantastic (it needs a better homepage!)
I hope I make enough with a game to donate or contribute to the cause here, you are doing tremendous and fantastic work, it's really saving me and it matters a lot.
Quote from: bobbo on April 27, 2013, 09:40:04
Quote from: kappa on April 23, 2013, 16:33:18
Eclipse has been ported to run on TWL!
Where did you see this?
Its called Bling (http://www.l33tlabs.com/bling.html), a 3d development platform. Don't think there are any video's or screenshots available on its site yet (although the author has shared them on LWJGL's IRC and must say that it looks very impressive). It was shown of publicly at a EclipseCon talk (http://www.eclipsecon.org/2013/sessions/experience-bling-gpu-powered-game-ide), haven't been able to find a video for the talk but a quick google shows this (https://twitter.com/holgerschill/status/317329572460896256/photo/1) blurry screenshot. I'm sure author will reveal further details once ready.
Quote from: kappa on April 27, 2013, 10:50:56Its called Bling (http://www.l33tlabs.com/bling.html), a 3d development platform.
Found a couple direct screenshots of it in this PDF after searching from your info: http://www.eclipsecon.org/2012/sites/eclipsecon.org.2012/files/modeledUI2012.pdf Very interesting thing.
Edit: 2.9.1 has zero problems for me, fantastic!