Do this in command line to get the source code:
svn checkout svn://svn.code.sf.net/p/ardor3d-jogl2/code/trunk ardor3d-jogl2-code
I removed the directories containing the JUnit tests but it was empty in the previous JOGL 1.1.1a renderer for Ardor3D. There are some tests in each directory named src/test/ in each sub-project composing Ardor3D. None of them concern NEWT and as I cannot commit anything on ardor3d-examples, I haven't been able to commit my tests of NEWT.
I can make some more tests concerning the bug 455, probably Thursday at night.
I'm going to read some things about Jenkins. You have to be aware that the main pom file used by all Ardor3D sub-projects is mandatory to compile with Maven. Comment the lines about the ardor3d-archetype if it does not work.
Later on (after Jenkins integration) we can remove them from the repo.
> I removed the directories containing the JUnit tests but it was empty in the
> previous JOGL 1.1.1a renderer for Ardor3D. There are some tests in each
> directory named src/test/ in each sub-project composing Ardor3D. None of
> them concern NEWT and as I cannot commit anything on ardor3d-examples, I
> haven't been able to commit my tests of NEWT.
Yeah, it will be a hard transition time, right.
> I can make some more tests concerning the bug 455, probably Thursday at
> I'm going to read some things about Jenkins. You have to be aware that the
> main pom file used by all Ardor3D sub-projects is mandatory to compile with
> Maven. Comment the lines about the ardor3d-archetype if it does not work.
Yup .. maven support for JogAmp .. that was another issue.
Many volunteers .. some work has been done, but then dropped.
Dunno why, but I guess I can write a book about unfinished work by now :)
For our transitional jenkins builds, we may build Ardor3D in the very end,
so it can use the previous JogAmp artifacts.
Ofc .. I don't know how this will work with a 'hybrid',
ie jogl-ant build and latter ardord3d pom build.
As you can see in the SVN history, I already use the build 526 of JOGL since r13.
I have used my nice JoglNewtWindow in the example runner of Ardor3D and after some hours of bug fixing, it works fine. There is only 2 remaining problems:
- when I scroll, NEWT says that I use the mouse button 4 (it is a known bug, isn't it?)
- requestFocus() still crashes
Concerning the bug 455, it seems not to affect Ardor3D because it calls swapBuffers() quite often. I assume the bug is still there when the programmer tries to call it less often which might happen in scientific applications when you show very large meshes. Therefore, it is not a blocker bug for Ardor3D but we have to keep in mind that it is not fixed.
Maven is not mandatory to build Ardor3D but it helps a lot.
While still @ Sun, we had a 'discussion' whether to use a dedicated 'wheel'
event or just representing them as another 'button'.
Well, I favored the latter since it's a more generic approach,
plus we really cannot tell what-else game-pads may have.
Technically it's a button, hence a pass-through button representation
is IMHO best. For sure I can be convinced otherwise with good (tech.) arguments.
Maybe we can make a checklist here how the wheel is
represented on the native platforms:
X11: Usually button4 and button5
If they all use a button representation, I guess it's best to remove the 'wheel' ID.
Let me copy paste this email to the bugzilla entry,
so we can continue it's discussion there (where it belongs IMHO).
The 3 remaining "blocking" bugs of NEWT are these furthers: 413, 525 and 529.
I need to fix something on the disposal by using the dispose() method of the GLEventListener if possible.
I will try to wrap the SWT OpenGL canvas based on NEWT inside Ardor3D.
Finally, I will have to write a kind of NEWT plug-in for JInput so that we can use the mice, the keyboards and the joypads without AWT and with no change of permissions on some files on Linux. Best regards.
The focus requests now work as expected but there is still a separate mouse event generated on mouse release instead of a single mouse wheel event (see bug 413).
The bug 525 is not reproducible on Mageia Linux 1, the problem came from my source code. I still have a small problem in Ardor3D as there is something in the UI that assumes JOGL follows the AWT convention whereas the orbit camera works fine when I assume NEWT does not follow AWT convention for ordinates.
I assume you just did a copy/paste of the whole command line mentioned on my blog but this command line contains the 'svn checkout' command, the repository URL and the name of the default read-only SVN user for this project.
I use the release candidate 4 instead of the build 577 and now the problem with mouse scroll events is gone. All demos of Ardor3D work properly with JOGL 2.0, there are only sometimes an exception when exiting because Ardor3D tries to make the context current whereas the window has already been destroyed.
I'm not comfortable with Netbeans but let me know if you still have some difficulties to use my source code and I will try to use it in Netbeans to be able to tell you what to do, step by step. This is an open source project; if people cannot use my source code, it is just useless.
Maybe look at the way to proceed to install the pre-beta version of TUER in Netbeans 6.9, it should be quite similar, just change the Repository URL and select the project "ardor3d-jogl2":
I managed to connect using svn and the trunk link using NetBeans on Win7.
However, when the project is opened in NetBeans I see that there is a problem with the pom.xml
And when I build the project I get the following:
cd C:\ardor3d\trunk\ardor3d-jogl2; "JAVA_HOME=C:\\Program Files\\Java\\jdk1.6.0_23" "\"C:\\Program Files\\NetBeans 7.0\\java\\maven\\bin\\mvn.bat\"" install
Scanning for projects...
The build could not read 1 project -> [Help 1]
The project com.ardor3d:ardor3d-jogl2:0.8-SNAPSHOT (C:\ardor3d\trunk\ardor3d-jogl2\pom.xml) has 1 error
Non-resolvable parent POM: Could not find artifact com.ardor3d:ardor3d:pom:0.8-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 3, column 11 -> [Help 2]
To see the full stack trace of the errors, re-run Maven with the -e switch.
Re-run Maven using the -X switch to enable full debug logging.