Opengl With Java

[Staci Mauger]

SoI asked a question not long ago that was similar but it wasn't my best work. What I'm trying to do is make a small jar with no other files but the jar (maybe natives if needed) that handles a window and graphics for games. I'm making this for some people I know who don't want to get into advanced graphics and stuff to make games, plus I figure it would be easier to stick everything they need into one jar that they know how to use. Anyway I found JOGL but after like the past 3 hours or so all I got with JOGL was the memory to never use it because it's a pain to install (at least for me) and everyone says a different way to install it and I need like 100 files along with my jar to get it to work. So since I'm not dealing with JOGL i figured that it's best to try and find something else. So does anyway know any way to get OpenGL into java without libraries that add more files and if so just like 1 file? I'm trying to get it so it's just that jar and nothing else. I just want this done but I'm very confused. I would also like it to be able to run on Windows, Linux and Mac. I only have a Windows machine although I can get Linux to test it on and I know someone who has a Mac but keep in mind I'm building it on a Windows machine. So my question really is how would I be able to stick OpenGL (I would like OpenAL and maybe OpenCL too) in a single jar and nothing else? I have a few exceptions such as I'm kinda ok if I need a few natives but I don't want 10 jars and 50 natives and I need it to work on all kind of machines, and also I would like to be able to use swing to handle the window.

No, OpenGL is a library written in C. You will need some binary file for each platform to interface correctly with OpenGL. There has to be some platform specific part because the JavaVM does not virtualize the OpenGL device for you.

However when developing with Java you can use Maven which is a sort of advanced build system, like Ant but done right I heard people call it (I never used Ant though). You can just pull JOGL into Maven and it will use the correct binaries for each platform when building or releasing.

(Note: I totally feel your pain when using JOGL without an automated system to do it for you, men their documentation is worthless I usually end up just placing all the natives in the same file as the JAR and hoping it works)

An alternative to JOGL is LWJGL. It really is "lightweight", as the name suggests, both in terms of installation and in terms of provided functionality - it's a pure wrapper to the C functions, with some additional (and really helpful) checkers.

The documentation is certainly sufficient for me to install it on Windows, Linux and Mac; however, while 32-bit Windows is basically straightforward, adding 64-bit Java on Windows is a bit more of a hassle. And Linux is, as always, a bit harder for it's own reasons.

From all of that, you'll see that it's quite impossible for any language to support OpenGL by itself. OpenGL is not provided by a language; it cannot be provided by a language; it must be provided by the hardware vendor. Don't think of OpenGL as a library; think of it as a device driver (which is not too far off the truth). It's quite low level, it's very hardware-dependent.

So what would it mean for OpenGL to be natively supported by a language? It would mean that the parts of OpenGL that are hardware dependent (i.e. the interface as it's seen from the hardware side) could not exist. It would mean that something else would be needed to sit between the program and the hardware. But that "something else" would not be OpenGL, because OpenGL already clearly defines what it is, and it's not that "something else".

(All of this is deliberately ignoring pure software implementations - like Mesa3D - which you don't want to use as they are slow - I don't mean "slow" like 50% or 25% of the performance of a hardware implementation; I mean "slow" as in "you're lucky if you get 1 frame per second.)

You may choose to place all the JogAmp JOGL 2.0 JARs inside your main JAR when you export your application using Eclipse.Use the "Package required libraries into generated JAR" in the Eclipse Runnable JAR export dialogue.By exporting like this will create a single jar file that will run on all platforms. -tp4029053p4029054.html

This document describes several unsupported properties that youcan use to customize how the 2D painting system operates. You mightuse these properties to improve performance, fix incorrectrendering, or avoid system crashes under certain configurations.For example, on a small set of Microsoft Windows computers with badDirectDraw or Direct3D drivers, the use of hardware-acceleratedrendering might cause system crashes. You can use properties tospecify that on these computers, the Java 2D system shouldn't useDirectDraw or Direct3D.

2D properties have the prefix sun.java2d.. Tospecify them, you can use either command-line flags or the_JAVA_OPTIONS environment variable. For example, youcan specify the 2D trace property with a flag whenrunning an application, like this:

Some system properties are also settable using environmentvariables. For example, the d3d property has theequivalent environment variable J2D_D3D. The propertydescription lists the equivalent environment variable, if oneexists.

An OpenGL-based pipeline for Java 2D was introduced in 1.5 Beta1 for Solaris/Linux and 1.5 Beta 2 for Microsoft Windows platforms.This pipeline is currently disabled by default. It provideshardware acceleration for simple rendering operations (text,images, lines, and filled primitives) as well as those that involvecomplex transforms, paints, composites, and clips.

The methodname represents the basic graphicsoperation that is used to do the actual rendering work of aGraphics method invocation. These method names willnot necessarily map directly to methods on theGraphics object, nor will the number of calls made onthe Graphics object map directly to the number ofprimitive operations performed.

The composite names match the names in theAlphaComposite class fairly closely with the suffix"NoEa" meaning that theAlphaComposite instance had an "extra alpha"attribute of 1.0. The "SrcNoEa" type is the most commonlyused composite type and represents the simplest way of transferringpixels with no blending required. "SrcNoEa" is often usedbehind the scenes even though the default composite is"SrcOver" when opaque colors and images are renderedbecause the two operations are indistinguishable for opaque sourcepixels.

Platform rendering pipelines are sometimes used for doing opaqueoperations on surfaces accessible by a platform renderer, such asX11, GDI, or DirectDraw. Their names currently use a simplifiednaming format, which has a prefix for the platform renderer and thename of the operation but without any classname or operand typelist. Examples are "X11DrawLine","GDIFillOval", and "DXFillRect". In the futurethese names should more closely approximate the names of the otherprimitives.

What the flag really does is override what the JRE reads fromthe user's desktop settings as the user's desktop antialiased textpreferences. Swing instructs Java 2D to render Swing text to matchthat preference, so by overriding it you can control Swing text.This applies to standard Swing components (like JTextArea, JButton)in the Metal L&F (aka Java L&F) and native (Windows, GTK)Swing L&Fs. It should also apply to any custom component orL&F which picks up the same property.

This property can be used to eliminate the initial delay inrendering when the images are being copied to the VRAM after thefirst few copies. Instead, the delay is effectively shifted to theimage creation time.

This could be useful behavior when you know that yourapplication will be able to take advantage of image management;just get the overhead of the copy over with at the start instead ofincurring some number of slower copies to begin with and thenhaving the copy overhead at some later time.

When this property is set to 16, it forces the acceleratedsurfaces for managed images (created withGraphicsConfiguration.createCompatibleImage(w,h,TRANSLUCENT)) or translucent images loaded withToolkit.getImage to be in 4444 format. The systemmemory surface for these images will be in 4444 format as well.

This option is also useful for computers with video boards (suchas 3dfx Voodoo3) that don't support 32-bit textures. When the Java2D system uses 32-bit textures, as it does by default, then when itencounters a card without 32-bit texture support it disablessupport for accelerated translucent images. If you wantacceleration of translucent images on a video board that doesn'tsupport 32-bit textures, set the d3dtexbpp property to16.

Obsoleted in: Java SE 6 Update 10

Intended use: To turn on hardware-accelerated scaling whenthe DirectDraw/Direct3D pipeline is in use.

Introduced: 1.2

Default value: false

How to use: Setting this flag to true enableshardware-accelerated scaling if the DirectDraw/Direct3D pipeline isin use. DirectDraw/Direct3D hardware scaling is disabled by defaultto avoid rendering artifacts in existing applications. Theserendering artifacts are caused by possible inconsistencies betweenthe scale method that the software scaling operation uses (nearestneighbor) and the different scale methods that video cards use.Certain events that occur while an application is running mightcause a scaled image to be rendered partially with hardware scalingoperations and partially with software scaling operations,resulting in an inconsistent appearance. For now, you can enableacceleration by setting the ddscale flag to true.

When both these properties are true, the Java 2D system attemptsto put translucent images into VRAM and use Direct3D for rendering(compositing) them to the screen or to aVolatileImage. Only translation transforms aresupported (no rotation, scaling, and so on). Before 1.5, to beaccelerated a translucent image had to be created in one of thefollowing ways:

3a8082e126