[FIXED] OSX / Java 7

[Matzon]

Heavy moderation
Thread was being completely derailed - split into two. Lets keep this one on OSX / Java 7

[normen]

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

[abcdef]

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.

[abcdef]

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];
}
}

[kappa]

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.

[thebattlebard]

Great news

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

[abcdef]

Good news indeed!

Are the changes in the nightlies yet? I'd be interested in doing some testing.

[princec]

Great news

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

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

[kappa]

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 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 has Leopards last months market share at 10.4% and also confirms the constant and steep loss of market share here.

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, 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 stat) .

Further news stories like this (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.

[abcdef]

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.

[Obsyd]

Great news! 
Thanks for your hard work guys!

[thebattlebard]

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

[EmuMog]

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.

[EmuMog]

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.

[kappa]

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, should make a nice addition for OS X Lion and above.