There's no need to do the slicing since the gl...Pointer methods already take the current position of a buffer into account.

A post on the apple OpenGL mailing list provides some ideas on how to work around the POLYGON_SMOOTH artifacts.

NVPerfHUD is a Direct3D tool. Since it doesn't work with OpenGL it won't work with jogl either.

They've been updated to 1.1.1rc3 in the meantime

If you just want to get rid of the concurrent modification exception you can also use Iterator#remove.

If you set your profiler to sampling instead of code instrumentation, you shouldn't have that problem.

http://www-128.ibm.com/developerworks/java/library/j-jtp11253/
Lists the different options in a table about halfway the article

I'll second that.

The JNI spec says you're only allowed to use get*Critical for small bits of code. I don't think you can pin objects in memory for an extended period of time. The spec also mentions that these methods don't necessarily pin the object. You still might get a copy.

To be honest, I'm surprised you got this working. Java objects aren't necessarily located at a fixed place in memory. What happens if the GC decides to move the mapped Object to a different place in memory?

If you have a guaranteed winding you could use cross products. Given a point p and a triangle a,b,c that is wound clockwise ab x ap, bc x bp and ca x cp all have to be greater or equal to zero in order for the point to lie inside the triangle.

Since I don't work in the games industry, I don't really know how people work in that sector on a day to day basis, but from my point of view it seems that a lot of existing tools already cover the features you're asking for. Using basic stuff like a version control system and some build system, an instant messenger or plain old  telephones, and existing tools such as blender and the gimp it seems like you should be able to set up a pretty decent working environment. I don't see why you would want to put so much time (it really sounds like a  huge project) in basically reinventing stuff that already exists. In other words, do you really think this kind of 'integrate everything' tool is commercially viable?

A big boost in number crunching performance too. JSquish (pure java s3tc texture compressor) compresses images about twice as fast under jse6 compared to jse5.

James Gosling is refering to the possibility to integrate jogl and java2d. One of the java2d implementations (not the default one) in jse6 is based on opengl. It has been designed so that you can take the opengl rendering context of a component and render on it using both java2d and jogl. In other words you can easily combine 2d and 3d rendering in a single component without having to render to intermediate images. See the Java2D/JOGL Interoperability thread for more detailed info.

Whatever I can get my hands on that seems relevant to my work. In college I worked my way through books on OSes, compiler construction, AI, hardware architecture, programming alngauges, software design, user inteface design, computer graphics, ...
Currently on my desk (work related):

• The OpenGL programming guide (red book)
• The OpenGL shading language book (orange book)
• Designing interfaces by Jeniffer Tidwell
• Concurrent Programming in Java by Doug Lea
• Mastering the JFC (The big Swing reference book)
• Artifical Intelligence - A Modern Approach by Russel and Norvig
• Visual Explanations by Edward Tufte

I'm not going to pretend I've read all of these back to front, but I have gotten tons of useful information out of each one.

In my spare time I'm currently reading 'The design of everyday things' by Don Norman. Next on the to read pile is 'The Humane Interface' by Jef Raskin.

Each Graphics2D object has a current transformation. By default this is an identity transformation, i.e. do nothing. This transformation is represented by an instance of AffineTransform. You can modify this transformation implictly using methods like Graphics2D#scale, Graphics2D#translate, Graphics2D#shear, ... or explicitly set a transformation using Graphics2D#setTransform.
The problem in your code is that you do

but after that you don't do anything with the transformation. Depending on what you're trying to exactly you'll have to pass this transformation to the Graphics2D object somewhere using one of the methods I mentioned above.
If you want some more info on the mathematics behind all this stuff Martin Baker's math site is a pretty good starting point. I would recommend you make sure you thoroughly understand this stuff. It will all make a lot more sense then...

Asking an actual question might help.

Squish on its own only performs the DXT compression. The output is just a bunch of DXT blocks. It's pretty straightforward to write these to a DDS file afterwards, so offline processing is definitely possible.

Shouldn't

be

?

If not, why do you need to add cOffset * 2 to the packed offset?

You can access files that are located in the classpath using a ClassLoader. More specifically you can use the methods ClassLoader#getSystemResourceAsStream or ClassLoader#getResourceAsStream.
As far as I know j2se doesn't provide any API to update an existing jar file. It's pretty straightforward to create a new one though using a JarOutputStream.

There are only 7 or so error codes, so the switch doesn't seem that big a deal. You can't get a very specific error description out of OpenGL though. You basically have to deduce what actually went wrong based on the context in which the error occurs. DebugGL helps...

You should probably replace "do this" with "the value of this". Otherwise it sounds like ?: is a flow control statement.

Out of curiosity, I had a look at the TextureData code. It seems that for 4BYTE_ABGR it goes through the slowest code path (createFromCustom). You have to do something with the data since OpenGL only supports RGBA and BGRA, not ABGR, but you can do this conversion much faster than via the image apis. I did this by grabbing the bytes directly from the DataBuffer and swizzling them in place.

IIRC I packaged each lesson as a jar containing all the required classes and resources. Those jars should also contain the source code of the lessons. If you prefer you can also download one big zip file containing all the source code.

You can fix this by forcing swing to use heavyweight components for popups, menus and tooltips as follows:

I've noticed similar issues in my application. I tried tracking down the cause of this and as far as I could tell this was (at least partially) due to the prioritizing of events in java.awt.EventQueue. You'll see there that heavyweight paint events get the lowest possible priority. My hunch was that when a new popup menu or tooltip (using heavyweights for both) triggered some event that got low priority and due to my opengl view hogging the EDT, that these events didn't get much chance to actually be processed. After optimizing my rendering code, the delay for the popups and tooltips to actually draw improved considerably. This also seems to point in the direction that some event isn't being processed in a timely fashion.
I don't have exact knowledge of how all the different parts (native side, java side, popup menus, ...) in awt interact though, so I might have drawn a wrong conclusion. Hopefully one of the awt engineers can shed some light on this?

You can access this information from JNI using the jawt stuff (jawt.h and jawt_md.h). Check the JNI documentation for more info.

I've tried this on my machine and it works just fine here. I simply added

to the class containing the main method and this has the expected behavior of making swing french.

I've only implemented the bitmap font technique described in the red book. It's pretty straightforward using BufferedImage and Font. Make an image of type BufferedImage.TYPE_BYTE_BINARY, render the character you want to it and read back the contents of the data buffer. That data can then be used as input for glBitmap. This gives you crisp, non-scaling text.

That's seriously messed up

Does File#canRead return true in this case? If so, that might be an option.