I’ve found this very annoying too and I submitted a suggestion on it:
The new design is just not logical.
Will.
[quote]The navigation design on the download pages is… well pretty worthless. You have to click on the triangle next to the folders to expand them in the column on the left. Clicking on a folder will only show the files and not any sub folders in the main panel.
So click on the triangle next to the Release Builds 2004 folder, then click on the name of the folder you want.
[/quote]
Ahah! I see what’s wrong. My browser is word-wrapping so the triangle wasn’t on the same line as the title, making it look as if the title was a heading for the line below and “nightly builds” a subtopic.
Thanks for the help!
JOGL 1.1 b03 has been released on April 29, 2004. Please see the following thread for details:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1059055593
Please post comments, questions or problems with this new build on this thread.
Ken, any news on the timing of getting the mappings to the functions that use void** pointers? I could really use glMultiDrawArrays for a couple of things we do right now.
[quote]Ken, any news on the timing of getting the mappings to the functions that use void** pointers? I could really use glMultiDrawArrays for a couple of things we do right now.
[/quote]
It should be somewhat easier now that there is support for const char** (see glShaderSourceARB). I’ll try to get it done soon, but it may be at least a week due to some impending deadlines.
If you or someone else wants to take a shot at it, that would be great. The routines in GlueGen you will need to deal with in particular are:
[]JavaEmitter.typeToJavaType
[]CMethodBindingEmitter (search the source for “needsDataCopy”)
[*]CGLPAWrapperEmitter.emitBodyCallCFunction (look for call to javaArgTypeNeedsDataCopy() – actually, this may not need modification)
Basically the void** needs to be represented as a Buffer[] (array of direct buffers). A void** needs to be malloc’ed and free’d in the implementation of the native method, and the pointers in the direct buffer array need to be stuffed into the temporary void**, just like the String[] -> char** case.
Well, I’m half way there, but keep crashing out on the native compilation step ??? Looking into it though…
JOGL 1.1 b04 has been released on July 16, 2004. Please see the following thread for details:
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1059055593
Please post comments, questions or problems with this new build on this thread.
JOGL 1.1 b05 has been released on August 4, 2004. Please see the following thread for details:
Please post comments about the new release here.
Thanks for the new v1.1 beta-05 release.
Looks good so far. A few small tests with Jogl and Xith (with Jogl) run OK on an ATI 9600pro. I’ll try to test with other ATI carded PCs in the near future.
What I still don’t unterstand is why and when do we need to specify that ATI_WORKAROUND switch?
Someone (you?) wrote some time ago that there’s a difference in not using that parameter at all and using it with true and false. So this means there are three different start modes? What do they do?
-
Using no switch prints:[quote]…
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
Using ATI workaround of dispatching display() on event thread
Using ATI workaround of dispatching display() on event thread
INIT GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
…
[/quote]
(Italics by me) -
Using -DATI_WORKAROUND=true:[quote]…
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
Using ATI workaround of dispatching display() on event thread
INIT GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
…
[/quote] -
Using -DATI_WORKAROUND=false:[quote]…
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
INIT GL IS: net.java.games.jogl.impl.windows.WindowsGLImpl
…
[/quote]
All three methods work fine for my tests (both Jogl and Xith with Jogl). So as long as everything works fine I won’t use that workaround switch, naturally.
why do i get this when using release 1.1b05?
JOGL VERSION: 1.1.0-b04
INIT GL IS: net.java.games.jogl.impl.macosx.MacOSXGLImpl
CANVAS GL IS: net.java.games.jogl.impl.macosx.MacOSXGLImpl
CANVAS GLU IS: net.java.games.jogl.impl.GLUImpl
GL_VENDOR: ATI Technologies Inc.
GL_RENDERER: ATI Radeon 9000 OpenGL Engine
GL_VERSION: 1.3 ATI-1.3.18
is this an error in getVersion() or is it really just b04 on mac os x?
Looks like we forgot to change the version number.
[quote]Looks like we forgot to change the version number.
[/quote]
Yes, sorry about that. The next beta build will have an updated version number.
[quote]What I still don’t unterstand is why and when do we need to specify that ATI_WORKAROUND switch?
[/quote]
Hopefully you should not need to specify it, but the manual enabling/disabling is present just in case of bugs (as was the case with 1.1 b04). Currently it seems to be necessary on ATI cards for stability, which is why it defaults to being enabled there.
When I do NOT use -DATI_WORKAROUND=false, the amount of java.awt.Mouse(Motion)Events (like moving/dragging) drops to like 5% of the usual amount. (average 1 event per second)
As I depend on the mouse for aiming, this is something that completely breaks the ‘game’.
So I’m still using -DATI_WORKAROUND=false in 1.1.0b-05, which works great btw. Why do we need a workaround?
Yes, what is the ATI_WORKAROUND? What does it do or not do? I believe on one of my ATI cards, the flag makes no difference.
And what change introduced this? To date, I’ve still found the oldest jogl versions to be the most reliable/stable across all cards.
Also, with all these versions coming out, I really wish you guys would introduce a version number in the manifest like Java3D has. See RFE #101 in the bug list.
The ATI_WORKAROUND moves the work done inside the display() method from any animation or user threads over to the AWT event queue thread to try to workaround instability seen in ATI’s drivers. Please see the CVS log for e.g. GLCanvas.java.
There seems to be Something Wrong™ with jogl.jar
[quote]C:\dev\newwurmclient\lib_bin>jarsigner -keystore mykeystore -storepass ***** -keypass ********* jogl.jar wurmcert
jarsigner: unable to sign jar: java.util.zip.ZipException: invalid entry compressed size (expected 8727 but got 8679 bytes)
[/quote]
Rejaring it fixes the problem.
A bit off topic but how come the nightly builds (on website) are all 1.1.4 not 1.1.5 ???
sorry that wasn’t clear, I don’t mean the version number which was mentioned above but the actual file name bit, the page I mean is:
Sorry about the problems you’re seeing. Can you please file an issue and attach a test case?