I just updated the cvs tried the test and here are the results
run-testchooser:
2008-01-15 00:12:32.479 java[857] CFLog (0): CFMessagePort: bootstrap_register(): failed 1103 (0x44f), port = 0x10703, name = 'java.ServiceProvider'
See /usr/include/servers/bootstrap_defs.h for the error codes.
2008-01-15 00:12:32.480 java[857] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (java.ServiceProvider)
Jan 15, 2008 12:12:32 AM jmetest.TestChooser start
INFO: Composing Test list...
Jan 15, 2008 12:12:32 AM jmetest.TestChooser find
INFO: Searching for Demo classes in "jmetest".
Jan 15, 2008 12:12:33 AM com.jme.scene.Node <init>
INFO: Node created.
Jan 15, 2008 12:12:50 AM com.jme.app.BaseGame start
INFO: Application started.
Jan 15, 2008 12:12:50 AM com.jme.system.PropertiesIO <init>
INFO: PropertiesIO created
Jan 15, 2008 12:12:50 AM com.jme.system.PropertiesIO load
INFO: Read properties
Jan 15, 2008 12:12:51 AM com.jme.input.joystick.DummyJoystickInput <init>
INFO: Joystick support is disabled
Jan 15, 2008 12:12:51 AM com.jme.system.lwjgl.LWJGLDisplaySystem <init>
INFO: LWJGL Display System created.
Jan 15, 2008 12:12:51 AM com.jme.system.PropertiesIO save
INFO: Saved properties
Jan 15, 2008 12:12:51 AM com.jme.app.BaseSimpleGame initSystem
INFO: jME version 1.0
Jan 15, 2008 12:12:52 AM com.jme.renderer.lwjgl.LWJGLRenderer <init>
INFO: LWJGLRenderer created. W: 1024H: 768
Jan 15, 2008 12:12:52 AM com.jme.app.BaseSimpleGame initSystem
INFO: Running on: null
Driver version: null
ATI Technologies Inc. - ATI Radeon X1600 OpenGL Engine - 2.0 ATI-1.4.56
Jan 15, 2008 12:12:52 AM com.jme.renderer.AbstractCamera <init>
INFO: Camera created.
Jan 15, 2008 12:12:52 AM com.jme.util.lwjgl.LWJGLTimer <init>
INFO: Timer resolution: 1000 ticks per second
Jan 15, 2008 12:12:52 AM com.jme.scene.Node <init>
INFO: Node created.
Jan 15, 2008 12:12:52 AM com.jme.scene.Node <init>
INFO: Node created.
Jan 15, 2008 12:12:52 AM com.jme.scene.Node attachChild
INFO: Child (FPS label) attached to this node (FPS node)
Jan 15, 2008 12:12:52 AM com.jme.scene.Node <init>
INFO: Node created.
Jan 15, 2008 12:12:52 AM com.jme.scene.Node attachChild
INFO: Child (test internalFrame) attached to this node (desktop node)
Jan 15, 2008 12:12:52 AM com.jme.scene.Node attachChild
INFO: Child (desktop node) attached to this node (rootNode)
Jan 15, 2008 12:12:52 AM com.jme.scene.Node attachChild
INFO: Child (top border) attached to this node (desktop node)
Jan 15, 2008 12:12:52 AM com.jme.scene.Node attachChild
INFO: Child (bottom border) attached to this node (desktop node)
Jan 15, 2008 12:12:52 AM com.jme.scene.Node attachChild
INFO: Child (left border) attached to this node (desktop node)
Jan 15, 2008 12:12:52 AM com.jme.scene.Node attachChild
INFO: Child (right border) attached to this node (desktop node)
Jan 15, 2008 12:12:53 AM com.jme.scene.Node attachChild
INFO: Child (Box) attached to this node (rootNode)
Jan 15, 2008 12:12:53 AM com.jme.scene.Node attachChild
INFO: Child (cursor) attached to this node (FPS node)
Invalid memory access of location 000001f4 eip=1b527750
Java Result: 138
However jMEDesktopState and jMEDesktopTestDragAndDrop work. So I started thinking maybe it was the hardware mouse (since mouse was the last thing) but no testHardwareMouse worked fine.
I did not remembere that there was also a thong…
Though, about JMEDesktop, if you have any interesting observations, as the one above (not the thong ) it could be useful. Though, if I remember well for me there was not any SWING based test that worked.
I just ran some tests: jmetest.awt.swingui.HelloJMEDesktop and subsequently jmetest.base.TestSimpleGame.
I observed that jmetest.awt.swingui.HelloJMEDesktop shows the mouse pointer and, if I move over the close button of the LWJGL window title bar (I allways run windowed mode, if testing, so, I can kill applications easy if any problems), the pointer remains visible and I can press the button to close the application. It was the only available option to close the application, except killing it, because of the poor frame rate and ESC key did not respond.
jmetest.base.TestSimpleGame, instead, shows no visible mouse pointer - that is usal behaviour - and, (most important) even if I move the pointer out of the GL canvas, system mouse pointer does not become visible: and this is usual too, I observed it either on Linux and Windows.
Those observations lead me to think that there is something to do with the mouse input system and event handlers.
For what I know JMEDesktop is responsible to convert jME input events(?) to SWING input events(?).
Though, I made a simple test. I placed some code in an exact copy of HelloJMEDesktop to debug the actual reaction to inputs.
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.out.println("Please tell me that you are working!!!");
// Other code [...]
}
}
// action that gets executed in the update thread:
button.addActionListener(new JMEAction("my action", input) {
public void performAction(InputActionEvent evt) {
System.out.println("Please tell me that you are working!!!");
// Other code [...]
}
}
The result have been that no output was printed to the console.
Now I am trying to understand what's going on with JMEDesktop. I created a copy of that class in a project of mine and I am going to make some tests...
Please can you post exactly how you modified JMEDesktop.setFocusOwner().
The fact you have Java 6 makes me think that is something related on how Java 5 manages resources. I have, in fact, Java 5. Unfortunatelly I fear that Apple will release Java 6 stable only for Leopard and currently I am unable to install Java 6 developers beta, because I already updated my Tiger Java release to the last Java 5 available. Java 6 db cannot be installed over it.
I could upgrade to Leopard because I already have the DVD but I read some weird hardware problems with the ATI X1900 XT video card coupled with Leopard and I wisely decided to wait before install it.
EDIT:
Tried disabling JMEDesktop.setFocusOwner() but this change does not resolve poor framerate.
As soon as the app starts under Java 6, the framerate is good, so yes, I think those issues are related to Java 5. Really do wish Apple would bring Java up to date for Tiger and Leopard.
I disabled setFocusOwner by having the first line as if(true) return;
Okay, FINALLY got a chance to look at JDesktop again
the testJMEDesktop has a bug in it (MAC only), commenting out this line:
createBoxBorder();
resolves the above mention error (Dont know why, bad memory address of jDesktop I assume)
however, the frame rate is HORRIBLE. 1 FPS on a MacBook pro w/ ATI x1600 256MB. When run in windows (virtual, 16MB generic gfx) I get 25fps.
Additionally there are problems with the swing widgets; no borders, no buttons, not title bars, generally ugly. The drop in FPS is due to the Mac-OS shadowing hardware widgets (a hack is available but requires Cocoa-Java :(). And it may be possible that if the swing UI is taking to long to render it may abandon leaving stuff unrendered; but this is just a guess.
Maybe tonight I will try Java 6.0 and see if that helps as Ridgewalker stated.
One of the biggest problems with Mac is that Mac OS X LWJGL implementation is based on AWT to provide an OpenGL context for drawing (in short Mac OS X implementation is not so native as like as Windows implementation). This could be one of the causes of the bad FPS and other general problems with jMEDesktop.
Considering this thing, in fact, jMEDesktop actually tries to create another AWT environment where there is already one active. I do not know if it is reccomended to have 2 concurrent AWT environments, but I guess not. Then one solution could be to find a way to make jMEDesktop behave differently in Mac OS X and trying to use already created AWT environment. But I do not know if it is possible.
In my opinion, the best solution to resolve all those problems is to find a way to implement Mac OS X LWJGL in a similar way then Windows implementation. Soon or later I will try an attempt to do it, but considering I am not expert Obj-C/Cocoa developer.
Though Cocoa/Java is deprecated. So it cannot be the right solution. I think that Java 6 for Mac, if any, will not support anymore Cocoa/Java.
