My own custom 3D client uses LWJGL 0.7 directly, and runs on OS X 10.3.3 just fine.
We’re looking at the possibility of rewriting our client using jME. I’m not a Mac programmer. I’m simply required to guarantee both PC and Mac compatibility of our 3D Java client.
(relevant story coming up…)
We recently tried to switch to WebStart, and it wouldn’t work on OS X. Basically the client would launch and be running, but there was no mouse input, and keypresses resulted in the “thunk” noise reserved for keys sent to windows which didn’t want them. However, our client runs fine from the Terminal command line or a script. This led me to believe that perhaps our window wasn’t “foreground” only when launched with JWS.
I just tried to run the jME BezierPath demo in OS X. After manually pulling down LWJGL 0.9a and figuring out the command line, I managed to get the demo to run from the command line… until it went to graphics mode. What happened? No mouse input, and every keypress made the “thunk” noise…
LW’s AlienFlux doesn’t seem to have this problem with JWS on OSX, so I started looking into its code. But haven’t found anything that would explain it yet. I thought maybe that because it was written with LW 0.9, so I tried upgrading our client to 0.9; it showed the same behavior under JWS anyway, so that wasn’t the answer.
- Is jME simply not compatible with Mac right now? How close to being so? How is it incompatible with OSX while LW is?
- What could be the difference between AlienFlux and our LW 0.7 app which works, and jME applications which don’t?
- Why would our client + JWS cause the same failure behavior as the jME demo? Is it because of there’s an opening dialog box in JWS (downloading) and the jME engine (screen modes)?
Does this all somehow involve AWT? Our client doesn’t use AWT at all (I think) And would launching from JWS somehow affect that?
1) Is jME simply not compatible with Mac right now? How close to being so? How is it incompatible with OSX while LW is?
Apparently, from what I have gathered on the LWJGL boards is any use of AWT with LWJGL creates this problem. This, I guess, includes the use of buffered images and the like. So, I think, this is where our problem lies. Cas will be the first to admit that LWJGL on Mac is "broken" in the sense that something that works fine on Windows and Linux will not work on Mac OS X. However, we have no developers that have a Mac OS X machine, so we don't have anyone to work on the problem. I'd absolutely love jME to work properly on OS X, we just don't have the tools to test/fix/test properly.
2) What could be the difference between AlienFlux and our LW 0.7 app which works, and jME applications which don't?
The only thing I know of is our use of AWT (During start up and we have smidgens of AWT code in the texture manager). We are currently working at removing all AWT code from texture loading at the behest of mkienenb. However, I don't know if this will resolve it or not.
3) Why would our client + JWS cause the same failure behavior as the jME demo? Is it because of there's an opening dialog box in JWS (downloading) and the jME engine (screen modes)?
Quite possibly.
Does this all somehow involve AWT? Our client doesn't use AWT at all (I think) And would launching from JWS somehow affect that?
That's the general consensus.
Not to pass the buck, but while we are working towards removal of AWT from our own code, this is still an LWJGL bug.
Bah, I meant to be logged in during that last post. Now I can’t spend the next hour finely tweaking that post, obsessing over the details, and submitting 12 edits like I normally do 
Yes, there is a test in jmetest.renderer.TestLWJGLRendererTriMesh.java This just builds a colored trimesh (triangle) with no textures.
To stop the dialog box, edit the file and in main
change: app.setDialogBehaviour(ALWAYS_SHOW_PROPS_DIALOG)
to
app.setDialogBehaviour(NEVER_SHOW_PROPS_DIALOG)
Your JWS demos reference an unknown file when on a Mac. I made one for ya from LW 0.9. Needs to go into mojomonkey.com/webstart:
http://jeramiehicks.no-ip.com/lwjgl-mac.jar
Doh, ya’ll referenced LW and OpenAL as seperate JARs, and I had put 'em both in the same JAR. Let me try that again:
http://jeramiehicks.no-ip.com/lwjgl-mac.jar
http://jeramiehicks.no-ip.com/openal-mac.jar
Sorry to be a nuisance ://
Third time’s the charm… openal-mac.jar needs to be signed.
I didn’t know if that was something you had to do, or if I could with my own… so I just left them unsigned. Never tried a JWS that referenced modules signed by different entities.
Eric/Renanse, can you build this for him? I don’t have access to a dev machine right now at work.
Just FYI, I just built and tried TestLWJGLRendererTriMesh, disabled the opening dialog box, and ran it on the Mac from the command line.
- At first, I accidentally had FULLSCREEN=false. Although the screen rendered correctly, I still got the keypress "thud" sound.
- Then I set FULLSCREEN=true. The screen rendered correctly, and I no longer got the keypress "thud" sound. Looks like it worked correctly.
Next I gotta find an example that has keyboard and mouse input to test, without any AWT usage.
jmetest.input.action.TestFirstPersonController does not have any textures.
Both lwjgl-mac.jar and openal-mac.jar have been signed and uploaded. So, let’s hope that third time is the charm! 
Much obliged, the JWS is working correctly now for OSX. Now just to get the demos themselves working
I’m about to try the input demo and see if I can get that to work.
jmetest.input.action.TestFirstPersonController works fine on OSX.
So aside from skipping the intro dialog box… what work would be required to get AWT out of the system? Ya’ll said the texture loading used it? Would it be just as simple as writing texture loaders?
I’m glad the Webstart stuff works now!
As for removing AWT from jME, it’s slightly more complicated than merely replacing image loaders. A search for “java.awt” in the project reveals 127 references. It’s present in the display system code, screenshot system, and various other places. It’s certainly not an impossible task to extricate it, but it’ll take time and effort.
I just re-enabled the opening dialog box on TestFirstPersonController, and the demo failed. The presence of the opening dialog box is definately the first failure point on OSX.
It appears that ALWAYS_SHOW_PROPS_DIALOG appears 81 times in the /src/jmetest directory. Evidently every test application specifically sets ALWAYS_SHOW_PROPS_DIALOG. That’s ok, the test apps themselves don’t have to work on the Mac immediately.
However, simply removing ALWAYS_SHOW_PROPS_DIALOG does not make TestBoxColor work. It does, however, make it work better (the app at least seems to accept keystrokes).
So the question is… how much AWT stands between TestFirstPersonController and TestBoxColor? We already know texture loading for the box and onscreen text.
If we can fix just that usage of AWT, I think we’ll be in pretty good business on the Mac. Maybe not everything… but onscreen text and textured geometry goes a long way.
Is there a spot that I could rig in a custom texture loader and give that a shot, simply to determine how far that gets us?
how much AWT stands between TestFirstPersonController and TestBoxColor?
I'll look into it.
Is there a spot that I could rig in a custom texture loader and give that a shot, simply to determine how far that gets us?
You can change your local copy of TextureManager to not use AWT. That would be a good first step. There will be scraps of AWT lying around as Eric mentioned, but those can be dealt with as we come across them.
Quote:
how much AWT stands between TestFirstPersonController and TestBoxColor?
I'll look into it.
Looks like what the major difference is: TestBoxColor uses SimpleGame which builds the display of FPS, verts/tris etc. This font is loaded via texture manager.