I noticed the files “gluegen-rt.jar” and “gluegen-rt.dll” are missing in the webstart archive. Is this a bug or are the file optional at runtime?
There should be less work being done overall for BufferedImage-based (including ImageIO-based) texture loading. The ImageIO subsystem is used to handle file formats like PNG. A lot of work used to be done in newTextureData() which is no longer done, but it shouldn’t have necessarily been replaced with work in newTexture(), unless your input data was a TYPE_CUSTOM BufferedImage or other format which doesn’t map to a native OpenGL texture format. If it is, you can circumvent this work by manually converting your loaded BufferedImage into a format supported natively by OpenGL before passing it to newTexture(). TYPE_INT_RGB or TYPE_INT_ARGB are good bets. You can look at the TextureData.createFromCustom() method for a hint on how to do this.
They’re supplied in the separate GlueGen webstart archive available from the GlueGen home page.
After the update to 1.1.0 RC3 I had to do a “javaws -uninstall” in order for JOGL to work again through webstart, otherwhise I got an “no jogl found in java.library.path” exception in all webstart JOGL apps (including the demos on jogl.dev.java.net).
I don’t know why I had to do this, but I post it here in case others have the same problem. I use Windows Vista and Java 6. By the way, it is sad that the javaws from Java 6 has no GUI any more, I found it useful.
EDIT : just found the “javaws -viewer” command, happy again now 
[quote=“Ken Russell,post:22,topic:29039”]
yes, unfortunately they are of type custom. so if i work out a way to convert my CUSTOMs to TYPE_INT_ARGB wouldnt this result in about the same things that are done in the TextureData.createFromCustom(BufferedImage image) function?
thanks!
I saw this problem on a couple of machines but in one case it seemed to fix itself. At the time I assumed that it was due to the timestamps changing on the files coming back from the web server. On the other machine the hard disk was failing and I assumed that was the root cause. If people continue to have problems please post.
It will at least allow the conversion work to be done in a background thread instead of your rendering thread. The conversion work had to be moved to the point at which the OpenGL texture was created or updated in order to honor the new guarantees that updates to the image’s contents will be reflected in the contents of the OpenGL texture.
Ken, is it possible to have access to these signed p200 gzipped files from the download section of jogl ?
I’d like to put them on my web server for JOGLAppletLauncher usage, and the best way to do that seems to get them from an official distribution, like the non p200 ones.
Many thanks !
Lilian 
I’ve updated the jogl-1.1.0-rc3-webstart.zip archive with the .pack.gz versions of jogl.jar, jogl-demos.jar, and jogl-demos-util.jar. There wasn’t any gain to be had by Pack200 compressing the other jar files (including the native jar files), at least as far as I found. We’ll try to remember to include these in this zip bundle in the future. For the record, though, if you just run Pack200 on the (signed) jogl.jar in the webstart archive, you’ll get the same result as these .pack.gz files.
Thanks !
IIRC last year there was a repack needed between two signings (thus my request).
Lilian
I don’t know what happens if you try to sign our jar with another certificate. I am however pretty sure that we are correctly repacking jogl.jar before signing it, which should allow anyone to run Pack200 against it.
Question:
Is gl_pixel_buffer_object_ext is supported?
Yes, it’s been exposed for a long time. There are four enumerated values associated with the extension and the various routines such as glTexSubImage2D and glReadPixels have variants supporting PBOs.
Hello,
my jogl application worked fine thus far, but for all release candidates, I get flipped textures. I.e. they are turned upside down. Is this behaviour wanted, because I read that you flip texture coordinates for some reason?
I tested the release candidates on a linux amd64 and a windows x86 machine and always get mixed up textures. Is this a bug, or should I expect this behaviour in the release version as well?
Regards,
Olufemi Rosanwo
ps: Thank you for the amazing work done with the jogl project. Finally, Java gaming is becoming feasible
This is not a bug but is expected behavior from a change in JOGL 1.1.0-rc2. You need to use the Texture.getSubImageTexCoords() method (or do similar work to what it does internally, especially taking into account the result of Texture.getMustFlipVertically()) to properly compute texture coordinates for displaying a Texture. See this thread for another discussion on this topic.
just being curious…
are there any news on the release date of 1.1.0 final?
again, let me tell you, that the jogl guys, especiall Ken, are doing an amazing job. recently i started to love the TextureRenderer. a really great feature! thanks!
It’ll be out as soon as I have a chance to add support to the Texture classes for hardware mipmapping and propagate those changes up to the TextureRenderer and TextRenderer. Hopefully within a couple of weeks.
The final build of JSR-231 1.1.0 has been posted today, April 22, 2007!
This is the official reference implementation of version 1.1.0 of the JSR-231 specification which was posted earlier this month. The binaries and source code are available at the link above. The on-line JOGL demos have been updated to use this release of the code. An extension JNLP file which will permanently point to the 1.1.0 release is now available at
http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0/webstart/jogl.jnlp
The “current” extension JNLP file listed in the JOGL User’s Guide has also been updated and is the best way to ensure your Java Web Started application is always using the most recent release.
<extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" />
The following changes have been made since Release Candidate 3:
[] Bug fixes relating to the addition of the getChosenGLCapabilities() API.
[] A bug breaking 64-bit X11 platforms (Linux/AMD64, Solaris/AMD64) was finally tracked down thanks to John Martin from Sun Microsystems.
[] Cg support was added for Solaris/x86.
[] Improvements and bug fixes to DDS image loading thanks to user bandures.
[] Bug fixes to the TextRenderer class. Added support for only optionally disabling the depth test in TextRenderer and TextureRenderer based on feedback from Dave Collins from the NASA World Wind project.
[] Changed how the TextureRenderer flushes its contents to OpenGL; added a markDirty() method and removed the sync() method. This improves support for multithreaded access.
[] Bug fixes to the TextureIO classes. Added Texture.getAspectRatio(). On suggestion from Chris Campbell from the Java 2D team, added TextureIO.setTexRectEnabled() and isTexRectEnabled() to make it easier to write pixel shaders operating on textures loaded by TextureIO.
[] Added support for automatic mipmap generation via GL_GENERATE_MIPMAP to the TextureIO classes. Added support for mipmapping to the TextureRenderer and TextRenderer classes.
[] The javadoc was updated to link to the OpenGL SDK on-line man pages thanks to Erik Tollerud.
[] A bug in the Java port of gluScaleImage() was fixed.
[] The TextureIO classes’ cube map support was fixed; thanks to johnrico2000 for pointing out the problem.
[] Tracked down and documented incompatibility between JOGL and JPackage.org’s “compatibility” RPMs thanks to help from Tim Lambert.
[] Fixed a problem in the Java 2D / JOGL bridge when FBOs are in use by the Java 2D / OpenGL pipeline (Issue 274) thanks to help from Chris Campbell.
[] Various other bug fixes.
Thanks to all in the community who tried earlier release builds and provided feedback on the new functionality. You have all helped build a strong base for building portable 3D applications in Java. There are some exciting 3D-related announcements coming up at JavaOne; watch these forums for more information.
On a sad note, Travis Bryson recently left Sun Microsystems. Travis was principally responsible for pushing through the final release of JSR-231; the JSR would not have been completed without him. I’d like to publicly thank Travis for his work on JOGL and wish him well in his travels.
congratulations!
and thanks a lot for all your support here in the forums!
keep up the good work!
I am trying to use
http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0/webstart/jogl.jnlp
but it appears that jogl.jar is not available at this location on the server:
Java Web Start Error:
Unable to load resource: http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0/webstart/jogl.jar
Thanks.