diff --git a/engine/lib/jheora/LICENSE.jheora b/engine/lib/jheora/LICENSE.jheora deleted file mode 100644 index b40af560b..000000000 --- a/engine/lib/jheora/LICENSE.jheora +++ /dev/null @@ -1,23 +0,0 @@ -/* Jheora - * Copyright (C) 2004 Fluendo S.L. - * - * Written by: 2004 Wim Taymans - * - * Many thanks to - * The Xiph.Org Foundation http://www.xiph.org/ - * Jheora was based on their Theora reference decoder. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU Library General Public License - * as published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU Library General Public License for more details. - * - * You should have received a copy of the GNU Library General Public - * License along with this program; if not, write to the Free Software - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - */ diff --git a/engine/lib/jheora/cortado-0.6.0.tar.gz b/engine/lib/jheora/cortado-0.6.0.tar.gz deleted file mode 100644 index a8b57300f..000000000 Binary files a/engine/lib/jheora/cortado-0.6.0.tar.gz and /dev/null differ diff --git a/engine/lib/jheora/jheora-debug-0.6.0.jar b/engine/lib/jheora/jheora-debug-0.6.0.jar deleted file mode 100644 index f7d83e6fc..000000000 Binary files a/engine/lib/jheora/jheora-debug-0.6.0.jar and /dev/null differ diff --git a/engine/lib/jheora/jheora-jst-debug-0.6.0.jar b/engine/lib/jheora/jheora-jst-debug-0.6.0.jar deleted file mode 100644 index fc1c0a34e..000000000 Binary files a/engine/lib/jheora/jheora-jst-debug-0.6.0.jar and /dev/null differ diff --git a/engine/lib/jogl/CHANGELOG.txt b/engine/lib/jogl/CHANGELOG.txt deleted file mode 100644 index 1455bec55..000000000 --- a/engine/lib/jogl/CHANGELOG.txt +++ /dev/null @@ -1,101 +0,0 @@ -Changes between JOGL 1.1.0 and 1.1.1: - - - Fixed a bug in the checking of incoming buffers' sizes to - glTexImage1D, glTexImage2D, and glTexImage3D. - -Changes between JOGL 1.0.0 and 1.1.0: - - - The glext.h and associated header files JOGL uses have been updated - to OpenGL 2.1 with NVidia's GeForce 8 series extensions. The new - functions are available as methods in the GL interface. - - - The developer build bundles have been changed to zip archives, so - instead of having to download multiple jars, you can now just - download the zip archive for your particular platform. The new zip - archives are versioned with the build date. - - - The source distribution now contains the generated sources like - GL.java, GLU.java, etc. for more convenient use in IDEs. - - - The chosen GLCapabilities are now exposed from the GLDrawable via - GLDrawable.getChosenGLCapabilities(); this functionality works on - all platforms even in cases where the GLCapabilitiesChooser is not - supported, and attempts to provide correct answers so programs can - make decisions based on the results. - - - The native code for the "DRI hack" (to support the open-source DRI - drivers on Linux and other X11 platforms) has been removed; JOGL - now uses the GlueGen NativeLibrary class for this purpose. - Reliability improvements have been made to the implementation of - this class; it has been confirmed as working again with ATI's - proprietary drivers on Linux and should also work better with - NVidia's drivers. - - - The GlueGen runtime classes have been removed from jogl.jar. These - have been factored out into gluegen-rt.jar and are referenced by - both the JOGL and JOAL projects. - - - Thanks to John Burkey some optimizations have been made to the - buffer object-related validity checks in glVertexPointer, etc. as - well as a buffer size query that was being made in the glMapBuffer - implementation. This improves performance for applications - performing a lot of VBO- or vertex array-based rendering, in - particular with the multithreaded OpenGL implementation on Mac OS - X. - - - The JOGL applet launcher now supports deployment of applets which - use both OpenGL for 3D graphics via JOGL as well as OpenAL for - spatialized audio via JOAL. It now prompts the user on Windows - platforms to allow it to enable the -Dsun.java2d.noddraw=true - system property for best robustness. It has been updated for the - changes in the GlueGen runtime classes and native library - structure. Some bugs have been fixed, some of which were preventing - different JOGL-based applets from being deployed from the same - codebase. The documentation and on-line examples have been updated - as well. - - - The TextureIO implementation has been changed to no longer copy the - data associated with BufferedImage TextureData objects. Instead, - the necessary vertical flip is now implemented by flipping the - texture coordinates vertically. - - - An API for updating a sub-image of a Texture object from a - sub-portion of a TextureData object has been added. - - - A GLContext.copy() operation has been added based on community - feedback. - - - Three helper classes have been added to the com.sun.opengl.util.j2d - package to improve interoperability between JOGL and Java 2D: - TextureRenderer, Overlay and TextRenderer. The TextureRenderer - supports drawing into an OpenGL texture using Java 2D. The Overlay - class provides a convenient Java 2D-based overlay on top of an - arbitrary GLDrawable. The TextRenderer class supports drawing of - Java 2D text into an OpenGL context. Thanks to Chris Campbell of - the Java 2D team for collaboration and to the JOGL community for - extensive feedback and testing assistance. - - - Various bug fixes and robustness improvements were made to the - GlueGen runtime, JOGL and GLU implementations. - - - Fixes to the DDSImage class were contributed by the community: a - bug fix to mipmap handling and support for cubemap textures. Thanks - to java.net user bandures. - - - TextureIO.setTexRectEnabled() and isTexRectEnabled() were added - based on feedback from Chris Campbell, in order to simplify the - writing of pixel shaders which have different samplers for - GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE_ARB targets. - - - Thanks to Erik Tollerud, the links to the OpenGL documentation in - the JOGL javadoc were revised to point to the new on-line man pages - in the OpenGL SDK. - - - Support for automatic mipmap generation via GL_GENERATE_MIPMAP was - added to the TextureIO, TextureRenderer and TextRenderer classes. - - - Windows/AMD64 binaries, including the JOGL Cg binding, are now - supplied. - - - Worked around breakage of JOGL with 5.0u10; see Sun bug IDs 6504460 - and 6333613. diff --git a/engine/lib/jogl/COPYRIGHT.txt b/engine/lib/jogl/COPYRIGHT.txt deleted file mode 100644 index 360d3748b..000000000 --- a/engine/lib/jogl/COPYRIGHT.txt +++ /dev/null @@ -1,31 +0,0 @@ - -Copyright 2007 Sun Microsystems, Inc., 4150 Network -Circle, Santa Clara, California 95054, U.S.A. All rights -reserved. - -U.S. Government Rights - Commercial software. Government -users are subject to the Sun Microsystems, Inc. -standard license agreement and applicable provisions of -the FAR and its supplements. - -Use is subject to license terms. - -This distribution may include materials developed by third -parties. - -Sun, Sun Microsystems, the Sun logo and Java are trademarks -or registered trademarks of Sun Microsystems, Inc. in the -U.S. and other countries. - -OpenGL is a registered trademark of Silicon Graphics, Inc. - -This product is covered and controlled by U.S. Export -Control laws and may be subject to the export or import -laws in other countries. Nuclear, missile, chemical -biological weapons or nuclear maritime end uses or end -users, whether direct or indirect, are strictly prohibited. -Export or reexport to countries subject to U.S. embargo or -to entities identified on U.S. export exclusion lists, -including, but not limited to, the denied persons and -specially designated nationals lists is strictly prohibited. - diff --git a/engine/lib/jogl/LICENSE-JOGL-1.1.1.txt b/engine/lib/jogl/LICENSE-JOGL-1.1.1.txt deleted file mode 100644 index cd35e8827..000000000 --- a/engine/lib/jogl/LICENSE-JOGL-1.1.1.txt +++ /dev/null @@ -1,152 +0,0 @@ -JOGL is released under the BSD license. The full license terms follow: - - Copyright (c) 2003-2007 Sun Microsystems, Inc. All Rights Reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions are - met: - - - Redistribution of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - - Redistribution in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - - Neither the name of Sun Microsystems, Inc. or the names of - contributors may be used to endorse or promote products derived from - this software without specific prior written permission. - - This software is provided "AS IS," without a warranty of any kind. ALL - EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, - INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A - PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN - MICROSYSTEMS, INC. ("SUN") AND ITS LICENSORS SHALL NOT BE LIABLE FOR - ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR - DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR - ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR - DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE - DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, - ARISING OUT OF THE USE OF OR INABILITY TO USE THIS SOFTWARE, EVEN IF - SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. - - You acknowledge that this software is not designed or intended for use - in the design, construction, operation or maintenance of any nuclear - facility. - -The JOGL source tree contains code ported from the OpenGL sample -implementation by Silicon Graphics, Inc. This code is licensed under -the SGI Free Software License B (Sun is redistributing the modified code -under a slightly modified, alternative license, which is described two -paragraphs below after "NOTE:"): - - License Applicability. Except to the extent portions of this file are - made subject to an alternative license as permitted in the SGI Free - Software License B, Version 1.1 (the "License"), the contents of this - file are subject only to the provisions of the License. You may not use - this file except in compliance with the License. You may obtain a copy - of the License at Silicon Graphics, Inc., attn: Legal Services, 1600 - Amphitheatre Parkway, Mountain View, CA 94043-1351, or at: - - http://oss.sgi.com/projects/FreeB - - Note that, as provided in the License, the Software is distributed on an - "AS IS" basis, with ALL EXPRESS AND IMPLIED WARRANTIES AND CONDITIONS - DISCLAIMED, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES AND - CONDITIONS OF MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A - PARTICULAR PURPOSE, AND NON-INFRINGEMENT. - - NOTE: The Original Code (as defined below) has been licensed to Sun - Microsystems, Inc. ("Sun") under the SGI Free Software License B - (Version 1.1), shown above ("SGI License"). Pursuant to Section - 3.2(3) of the SGI License, Sun is distributing the Covered Code to - you under an alternative license ("Alternative License"). This - Alternative License includes all of the provisions of the SGI License - except that Section 2.2 and 11 are omitted. Any differences between - the Alternative License and the SGI License are offered solely by Sun - and not by SGI. - - Original Code. The Original Code is: OpenGL Sample Implementation, - Version 1.2.1, released January 26, 2000, developed by Silicon Graphics, - Inc. The Original Code is Copyright (c) 1991-2000 Silicon Graphics, Inc. - Copyright in any portions created by third parties is as indicated - elsewhere herein. All Rights Reserved. - - Additional Notice Provisions: The application programming interfaces - established by SGI in conjunction with the Original Code are The - OpenGL(R) Graphics System: A Specification (Version 1.2.1), released - April 1, 1999; The OpenGL(R) Graphics System Utility Library (Version - 1.3), released November 4, 1998; and OpenGL(R) Graphics with the X - Window System(R) (Version 1.3), released October 19, 1998. This software - was created using the OpenGL(R) version 1.2.1 Sample Implementation - published by SGI, but has not been independently verified as being - compliant with the OpenGL(R) version 1.2.1 Specification. - - -The JOGL source tree contains code from the LWJGL project which is -similarly covered by the BSD license: - - Copyright (c) 2002-2004 LWJGL Project - All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions are - met: - - * Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - * Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - - * Neither the name of 'LWJGL' nor the names of - its contributors may be used to endorse or promote products derived - from this software without specific prior written permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED - TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR - PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR - CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, - EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, - PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR - PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF - LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING - NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS - SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -The JOGL source tree also contains a Java port of Brian Paul's Tile -Rendering library, used with permission of the author under the BSD -license instead of the original LGPL: - - Copyright (c) 1997-2005 Brian Paul. All Rights Reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions are - met: - - - Redistribution of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - - - Redistribution in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - - Neither the name of Brian Paul or the names of contributors may be - used to endorse or promote products derived from this software - without specific prior written permission. - - This software is provided "AS IS," without a warranty of any - kind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND - WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY - EXCLUDED. THE COPYRIGHT HOLDERS AND CONTRIBUTORS SHALL NOT BE - LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, - MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES. IN NO - EVENT WILL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY - LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, - CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND - REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR - INABILITY TO USE THIS SOFTWARE, EVEN IF THE COPYRIGHT HOLDERS OR - CONTRIBUTORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. diff --git a/engine/lib/jogl/README.txt b/engine/lib/jogl/README.txt deleted file mode 100644 index 98a1ee32b..000000000 --- a/engine/lib/jogl/README.txt +++ /dev/null @@ -1,45 +0,0 @@ - -Java (TM) Binding for the OpenGL (r) API, version 1.1.1 -------------------------------------------------------- - -This software is licensed by Sun Microsystems, as specified -in the LICENSE-JOGL-1.1.1.txt file. You must use this software -in accordance with the terms under which the code is licensed. - - - -Instructions for unzipping Java Binding for the OpenGL API, version 1.1.1 --------------------------------------------------------------------- - -After downloading and unzipping the zip file containing the -JOGL release for your target platform, you will see the -following files in the top directory: - - COPYRIGHT.txt - LICENSE-JOGL-1.1.1.txt - Userguide.html - README.txt README file (you are reading it now) - -and the following subdirectory: - - lib contains JOGL implementation - -All of the JOGL implementation files (jar files and native -libraries) are in the lib subdirectory. For instructions on -how to use these implementation files to build or run a JOGL -program see the enclosed JOGL user guide (Userguide.html). - - - -Project source code and getting assistance ------------------------------------------- - -JOGL source code and project information can be found at: - - https://jogl.dev.java.net/ - - -Numerous answers to common questions can be found on the JOGL -forum: - - http://www.javagaming.org/forums/index.php?board=25.0 diff --git a/engine/lib/jogl/Userguide.html b/engine/lib/jogl/Userguide.html deleted file mode 100644 index 3dfd57568..000000000 --- a/engine/lib/jogl/Userguide.html +++ /dev/null @@ -1,999 +0,0 @@ - - - -Jogl - User's Guide - - - -

Jogl - User's Guide

- -

- -

- -

Overview

- -

- -Jogl is a Java programming language binding for the OpenGL 3D graphics -API. It supports integration with the Java platform's AWT and Swing -widget sets while providing a minimal and easy-to-use API that handles -many of the issues associated with building multithreaded OpenGL -applications. Jogl provides access to the latest OpenGL routines -(OpenGL 2.0 with vendor extensions) as well as platform-independent -access to hardware-accelerated offscreen rendering ("pbuffers"). Jogl -also provides some of the most popular features introduced by other -Java bindings for OpenGL like GL4Java, LWJGL and Magician, including a -composable pipeline model which can provide faster debugging for -Java-based OpenGL applications than the analogous C program. - -

-

- -Jogl was designed for the most recent versions of the Java platform -and for this reason supports only J2SE 1.4 and later. It also only -supports truecolor (15 bits per pixel and higher) rendering; it does -not support color-indexed modes. It was designed with New I/O (NIO) in -mind and uses NIO internally in the implementation. The Jogl binding -is itself written almost completely in the Java programming language. -There are roughly 150 lines of handwritten C code in the entire Jogl -source base (100 of which work around bugs in older OpenGL drivers on -Windows); the rest of the native code is autogenerated during the -build process by a new tool called GlueGen, the source code of -which is available from its own java.net project. - -

-

- -The JOGL source tree in its current form is an experimental workspace -for the JSR-231 Java -Bindings for OpenGL JSR. JOGL is not the official reference -implementation, but an evolving workspace. Snapshots of the JOGL -source tree are run through the JSR-231 Technology Compatibility Kit -(TCK) to become the official reference implementation (RI). As of this -writing the JSR has not been finalized, so the first official RI of -the JSR has not yet been produced. - -

- -

Developing with JOGL

- -

Building the source tree

- -

- -Most developers using JOGL will download the most current release -build. Separate instructions are available on how to build -the source tree. - -

- -

Local installation for development

- -

- -The JOGL distribution for developers comes in the form of a zip -archive which contains the Java classes to call OpenGL from Java, as -well as the associated JNI native libraries. JOGL depends on some -run-time support classes and native code provided by the GlueGen -project; these classes and native code are also provided in the zip -bundles. - -

-

- -If you are developing a new application which uses JOGL, download the -zip archive for your platform (for example., -jogl-[version]-windows-i586.zip) and unzip it. Modify your CLASSPATH -environment variable to include the full paths to jogl.jar and -gluegen-rt.jar; for example, -".;C:\Some\Other\Package\foo.jar;C:\Users\myhome\jogl-[version]-windows-i586\lib\jogl.jar;C:\Users\myhome\jogl-[version]-windows-i586\lib\gluegen-rt.jar". -(If you did not previously set the CLASSPATH environment variable, you -may want to make sure that ".", the current directory, is on your new -CLASSPATH.) Modify your PATH environment variable (Windows), -LD_LIBRARY_PATH environment variable (Solaris and Linux), or -DYLD_LIBRARY_PATH environment variable (Mac OS X) to contain the full -path to the "lib" directory; for example, on Windows, add -"C:\Users\myhome\jogl-[version]-windows-i586\lib" to your PATH using -the System control panel, Advanced tab, Environment Variables -button. At this point your Java installation should be able to see the -JOGL class files. Users of IDEs such as NetBeans and Eclipse should -consult the IDE's documentation to see how to add jar files and native -libraries to their current project. - -

-

- -Dropping the JOGL jar and native library into the extension directory -of the JRE is strongly discouraged. Doing so can cause -conflicts with third-party applications launched via Java Web Start, -and causes confusion later when upgrading the distribution. - -

-

- -If you are on the Linux platform, please see the Linux-specific -platform notes, below, with information on incompatibility between the -JPackage Java RPMs and JOGL. - -

- -

Java Web Start integration

- -

- -The recommended distribution vehicle for applications using JOGL is -Java Web Start. JOGL-based applications do not even need to be signed; -all that is necessary is to reference the JOGL extension JNLP file. -Because the JOGL jar files are signed, an unsigned application can -reference the signed JOGL library and continue to run inside the -sandbox. - -

-

- -To reference JOGL within your application's JNLP file, simply place -the following line in the <resources> section: - -

-  <extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp" />
-
- -This JNLP file points to the current JSR-231 unofficial development -build. For reference, the extension JNLP file for the most recent -official JSR-231 build is available at - -
-  <extension name="jogl" href="http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.0/webstart/jogl.jnlp" />
-
- -Note that before JOGL transitioned to the JSR-231 APIs, there were -releases of the library in the net.java.games.jogl -namespace under version numbers "1.0", "1.1", and "1.1.1". All of -these releases have been superseded by JSR-231. Please update your -applications. - -

- -

Applet support

- -

- -Lilian Chamontin, in conjunction with several other members of the -JOGL community, has contributed a JOGL applet installer. This -installer uses some clever tricks to allow deployment of unsigned -applets which use JOGL into existing web browsers and JREs as far back -as 1.4.2, which is the earliest version of Java supported by JOGL. - -

-

- -The JOGLAppletInstaller is distributed inside jogl.jar as a utility -class in com.sun.opengl.util. It requires that the developer host a -local, signed copy of jogl.jar and all of the jogl-natives jars; the -certificates must be the same on all of these jars. Note that in the -release builds of JOGL all of these jars are signed by Sun -Microsystems, so the developer can deploy applets without needing any -certificates. - -

-

- -The JOGLAppletInstaller javadoc describes the basic steps for -deployment of an applet utilizing JOGL. Please refer to this -documentation for more information. A live example of deploying an -unsigned JOGL applet will be added to this documentation shortly once -the first signed build of the JOGLAppletInstaller has been shipped. - -

- -

GLDrawable and GLContext

- -

- -The JSR-231 APIs specify interfaces two low-level OpenGL abstractions: -drawables and contexts. An OpenGL drawable is effectively a surface -upon which OpenGL rendering will be performed. In order to perform -rendering, an OpenGL rendering context is needed. Contexts and -drawables typically go hand-in-hand. More than one context may be -created for a particular drawable. In the JSR-231 abstractions, a -context is always associated with exactly one drawable. - -

-

- -Most end users will not need to use these abstractions directly. -However, when sharing textures, display lists and other OpenGL objects -between widgets, the concrete identifier for the "namespace" for these -objects is the GLContext. - -

- -

Creating a GLAutoDrawable

- -

- -Jogl provides two basic widgets into which OpenGL rendering can be -performed. The GLCanvas is a heavyweight AWT widget which supports -hardware acceleration and which is intended to be the primary widget -used by applications. The GLJPanel is a fully Swing-compatible -lightweight widget which supports hardware acceleration but which is -not as fast as the GLCanvas because it typically reads back the frame -buffer in order to draw it using Java2D. The GLJPanel is intended to -provide 100% correct Swing integration in the circumstances where a -GLCanvas can not be used. See this -article on The -Swing Connection for more information about mixing lightweight and -heavyweight widgets. See also the section on "Heavyweight and -Lightweight Issues" below. Recent work in the Mustang release of the -JDK has sped up the GLJPanel significantly when the Java2D OpenGL -pipeline is enabled; see this -forum discussion for more details. - -

-

- -Both the GLCanvas and GLJPanel implement a common interface called -GLAutoDrawable so applications can switch between them with minimal -code changes. The GLAutoDrawable interface provides - -

- -

-

- -When creating GLCanvas and GLJPanel instances, the user may request a -certain set of OpenGL parameters in the form of a GLCapabilities -object, customize the format selection algorithm by specifying a -GLCapabilitiesChooser, share textures and display lists with other -GLDrawables, and specify the display device on which the -GLAutoDrawable will be created (GLCanvas only). - -

-

- -A GLCapabilities object specifies the OpenGL parameters for a -newly-created widget, such as the color, alpha,, z-buffer and -accumulation buffer bit depths and whether the widget is -double-buffered. The default capabilities are loosely specified but -provide for truecolor RGB, a reasonably large depth buffer, -double-buffered, with no alpha, stencil, or accumulation buffers. - -

-

- -An application can override the default pixel format selection -algorithm by providing a GLCapabilitiesChooser to the GLCanvas or -GLJPanel constructor. (Not all platforms support the -GLCapabilitiesChooser mechanism, however; it may be ignored, in -particular on Mac OS X where pixel format selection is very different -than on other platforms.) The chooseCapabilities method will be called -with all of the available pixel formats as an array of GLCapabilities -objects, as well as the index indicating the window system's -recommended choice; it should return an integer index into this -array. The DefaultGLCapabilitiesChooser uses the window system's -recommendation when it is available, and otherwise attempts to use a -platform-independent selection algorithm. - -

-

- -The GLJPanel can be made non-opaque according to Swing's rendering -model, so it can act as an overlay to other Swing or Java2D drawing. -In order to enable this, set up your GLCapabilities object with a -non-zero alpha depth (a common value is 8 bits) and call -setOpaque(false) on the GLJPanel once it has been created. Java2D -rendering underneath it will then show through areas where OpenGL has -produced an alpha value less than 1.0. See the JGears and JRefract -demos for examples of how to use this functionality. - -

- -

Writing a GLEventListener

- -

- -Applications implement the GLEventListener interface to perform OpenGL -drawing via callbacks. When the methods of the GLEventListener are -called, the underlying OpenGL context associated with the drawable is -already current. The listener fetches the GL object out of the -GLAutoDrawable and begins to perform rendering. - -

-

- -The init() method is called when a new OpenGL context is -created for the given GLAutoDrawable. Any display lists or textures -used during the application's normal rendering loop can be safely -initialized in init(). It is important to note that -because the underlying AWT window may be destroyed and recreated while -using the same GLCanvas and GLEventListener, the GLEventListener's -init() method may be called more than once during the -lifetime of the application. The init() method should therefore be -kept as short as possible and only contain the OpenGL initialization -required for the display() method to run properly. It is -the responsibility of the application to keep track of how its various -OpenGL contexts share display lists, textures and other OpenGL objects -so they can be either be reinitialized or so that reinitialization can -be skipped when the init() callback is called. - -

-

- -Note also that the GLEventListener should be added to the -GLAutoDrawable before the GLAutoDrawable is shown or rendered to for -the first time. If this is not done, it is possible that the init() -method will not be called on the GLEventListener. JOGL does not -maintain internal state to keep track of whether init() has been -called on a particular GLEventListener since the last time an OpenGL -context was created for that GLAutoDrawable. - -

-

- -The display() method is called to perform per-frame -rendering. The reshape() method is called when the -drawable has been resized; the default implementation automatically -resizes the OpenGL viewport so often it is not necessary to do any -work in this method. The displayChanged() method is -designed to allow applications to support on-the-fly screen mode -switching, but support for this is not yet implemented so the body of -this method should remain empty. - -

-

- -It is strongly recommended that applications always refetch the GL -object out of the GLAutoDrawable upon each call to the -init(), display() and reshape() -methods and pass the GL object down on the stack to any drawing -routines, as opposed to storing the GL in a field and referencing it -from there. The reason is that multithreading issues inherent to the -AWT toolkit make it difficult to reason about which threads certain -operations are occurring on, and if the GL object is stored in a field -it is unfortunately too easy to accidentally make OpenGL calls from a -thread that does not have a current context. This will usually cause -the application to crash. For more information please see the section -on multithreading. - -

- -

Using the Composable Pipeline

- -

- -Jogl supports the "composable pipeline" paradigm introduced by the -Magician Java binding for OpenGL. The DebugGL pipeline calls -glGetError after each OpenGL call, reporting any errors -found. It can greatly speed up development time because of its -fine-grained error checking as opposed to the manual error checking -usually required in OpenGL programs written in C. The TraceGL prints -logging information upon each OpenGL call and is helpful when an -application crash makes it difficult to see where the error occurred. - -

-

- -To use these pipelines, call GLAutoDrawable.setGL at the -beginning of the init method in your GLEventListener. For -example, - -

-class MyListener implements GLEventListener {
-  public void init(GLDrawable drawable) {
-    drawable.setGL(new DebugGL(drawable.getGL()));
-    // ...
-  }
-
-  // ...
-}
-
- -

-

- -Note that the GLAutoDrawable.setGL() method simply calls setGL() on -the default OpenGL context created by the GLAutoDrawable, so -sophisticated applications creating their own OpenGL contexts can use -the composable pipeline with these contexts by setting the GL object -in the context object itself. The composable pipeline needs to be -re-installed every time GLContext.makeCurrent() returns -CONTEXT_CURRENT_NEW. - -

- -

Heavyweight and Lightweight Issues

- -

- -As mentioned above, JOGL supplies both a heavyweight (GLCanvas) and a -lightweight (GLJPanel) widget to be able to provide the fastest -possible performance for applications which need it as well as 100% -correct Swing integration, again for applications which need it. The -GLCanvas usually provides higher performance than the GLJPanel, though -in recent releases the GLJPanel's speed has been improved when the -Java2D/OpenGL pipeline is active as described in this -forum discussion. Nonetheless, the GLCanvas can be used in almost -every kind of application except those using JInternalFrames. Please -see the Swing Connection article mentioned above for details on mixing -heavyweight and lightweight widgets. A couple of common pitfalls are -described here. - -

-

- -When using JPopupMenus or Swing tool tips in conjunction with the -GLCanvas, it is necessary to disable the use of lightweight widgets -for the popups. See the methods -ToolTipManager.setLightWeightPopupEnabled, -JPopupMenu.setLightWeightPopupEnabled, and -JPopupMenu.setDefaultLightWeightPopupEnabled. - -

-

- -There are occasionally problems with certain LayoutManagers and -component configurations where if a GLCanvas is placed in the middle -of a set of lightweight widgets then it may only grow and never -shrink. These issues are documented somewhat in JOGL Issue -135 and most recently in the thread "Resize -behaviour" in the JOGL forum. The root cause is behavior of the -Canvas, and in particular its ComponentPeer. The implementation of -getPreferredSize() calls getMinimumSize() and getMinimumSize() turns -around and calls Component.getSize(). This effectively means that the -Canvas will report its preferred size as being as large as the -component has ever been. For some layout managers this doesn't seem to -matter, but for others like the BoxLayout it does. See the test case -attached to Issue 135 for an example. Replacing the GLCanvas with an -ordinary Canvas yields the same behavior. - -

-

- -One suggestion was to override getPreferredSize() so that if a -preferred size has not been set by the user, to default to (0, -0). This works fine for some test cases but breaks all of the other -JOGL demos because they use a different LayoutManager. There appear to -be a lot of interactions between heavyweight vs. lightweight widgets -and layout managers. One experiment which was done was to override -setSize() in GLCanvas to update the preferred size. This works down -to the size specified by the user; if the window is resized any -smeller the same problem appears. If reshape() (the base routine of -setSize(), setBounds(), etc.) is changed to do the same thing, the -demo breaks in the same way it originally did. Therefore this solution -is fragile because it isn't clear which of these methods are used -internally by the AWT and for what purposes. - -

-

- -There are two possible solutions, both application-specific. The best -and most portable appears to be to put the GLCanvas into a JPanel and -set the JPanel's preferred size to (0, 0). The JPanel will cause this -constraint to be enforced on its contained GLCanvas. The other -workaround is to call setPreferredSize(new Dimension(0, -0)) on a newly-created GLCanvas; this method is new in 1.5. - -

-

- -Another issue that occasionally arises on Windows is flickering during -live resizing of a GLCanvas. This is caused by the AWT's repainting -the background of the Canvas and can not be overridden on a per-Canvas -basis, for example when subclassing Canvas into GLCanvas. The -repainting of the background of Canvases on Windows can be disabled by -specifying the system property --Dsun.awt.noerasebackground=true. Whether to specify this -flag depends on the application and should not be done universally, -but instead on a case-by-case basis. Some more detail is in the thread -"TIP: -JOGL + Swing flicker" in the JOGL forum. - -

- -

Multithreading Issues

- -

- -Jogl was designed to interoperate with the AWT, an inherently -multithreaded GUI toolkit. OpenGL, in contrast, was originally -designed in single-threaded C programming environments. For this -reason Jogl provides a framework in which it is possible to write -correct multithreaded OpenGL applications using the GLEventListener -paradigm. - -

-

- -If an application written using Jogl interacts in any way with the -mouse or keyboard, the AWT is processing these events and the -multithreaded aspects of the program must be considered. - -

-

- -OpenGL applications usually behave in one of two ways: either they -repaint only on demand, for example when mouse input comes in, or they -repaint continually, regardless of whether user input is coming in. In -the repaint-on-demand model, the application can merely call -GLAutoDrawable.display() manually at the end of the mouse -or keyboard listener to cause repainting to be done. Alternatively if -the application knows the concrete type of the GLDrawable it can call -repaint() to have the painting scheduled for a later time. - -

-

- -In the continuous repaint model, the application typically has a main -loop which is calling GLAutoDrawable.display() -repeatedly, or is using the Animator class, which does this -internally. In both of these cases the OpenGL rendering will be done -on this thread rather than the internal AWT event queue thread which -dispatches mouse and keyboard events. - -

-

- -Both of these models (repaint-on-demand and repaint continually) still -require the user to think about which thread keyboard and mouse events -are coming in on, and which thread is performing the OpenGL rendering. -OpenGL rendering may not occur directly inside the mouse or -keyboard handlers, because the OpenGL context for the drawable is not -current at this point (hence the warning about storing a GL object in -a field, where it can be fetched and accidentally used by another -thread). However, a mouse or keyboard listener may invoke -GLAutoDrawable.display(). - -

-

- -It is generally recommended that applications perform as little work -as possible inside their mouse and keyboard handlers to keep the GUI -responsive. However, since OpenGL commands can not be run from -directly within the mouse or keyboard event listener, the best -practice is to store off state when the listener is entered and -retrieve this state during the next call to -GLEventListener.display(). - -

-

- -Furthermore, it is recommended that if there are long computational -sequences in the GLEventListener's display method which -reference variables which may be being simultaneously modified by the -AWT thread (mouse and keyboard listeners) that copies of these -variables be made upon entry to display and these copies -be referenced throughout display() and the methods it calls. This will -prevent the values from changing while the OpenGL rendering is being -performed. Errors of this kind show up in many ways, including certain -kinds of flickering of the rendered image as certain pieces of objects -are rendered in one place and other pieces are rendered elsewhere in -the scene. Restructuring the display() method as described has solved -all instances of this kind of error that have been seen with Jogl to -date. - -

-

- -Prior to Jogl 1.1 b10, the Jogl library attempted to give applications -strict control over which thread or threads performed OpenGL -rendering. The setRenderingThread(), -setNoAutoRedrawMode() and display() APIs -were originally designed to allow the application to create its own -animation thread and avoid OpenGL context switching on platforms that -supported it. Unfortunately, serious stability issues caused by -multithreading bugs in either vendors' OpenGL drivers or in the Java -platform implementation have arisen on three of Jogl's major supported -platforms: Windows, Linux and Mac OS X. In order to address these -bugs, the threading model in Jogl 1.1 b10 and later has changed. - -

-

- -All GLEventListener callbacks and other internal OpenGL context -management are now performed on one thread. (In the current -implementation, this thread is the AWT event queue thread, which is a -thread internal to the implementation of the AWT and which is always -present when the AWT is being used. Future versions of Jogl may change -the thread on which the OpenGL work is performed.) When the -GLAutoDrawable.display() method is called from user code, -it now performs the work synchronously on the AWT event queue thread, -even if the calling thread is a different thread. The -setRenderingThread() optimization is now a no-op. The -setNoAutoRedrawMode() API still works as previously -advertised, though now that all work is done on the AWT event queue -thread it no longer needs to be used in most cases. (It was previously -useful for working around certain kinds of OpenGL driver bugs.) - -

-

- -Most applications will not see a change in behavior from this change -in the Jogl implementation. Applications which use thread-local -storage or complex multithreading and synchronization may see a change -in their control flow requiring code changes. While it is strongly -recommended to change such applications to work under the new -threading model, the old threading model can be used by specifying the -system property -Djogl.1thread=auto or --Djogl.1thread=false. The "auto" setting is equivalent to -the behavior in 1.1 b09 and before, where on ATI cards the -single-threaded mode would be used. The "false' setting is equivalent -to disabling the single-threaded mode. "true" is now the default -setting. - -

-

- -In the JSR-231 APIs the single-threaded behavior continues to be the -default and the setRenderingThread() and -setNoAutoRedrawMode() APIs have been removed. The public -Threading class still provides some control over the -internal use of threads in the library as well as external access to -these mechanisms. - -

- -

Pbuffers

- -

- -Jogl exposes hardware-accelerated offscreen rendering (pbuffers) with -a minimal and platform-agnostic API. Several recent demos have been -successfully ported from C/C++ to Java using Jogl's pbuffer APIs. -However, the pbuffer support in Jogl remains one of the more -experimental aspects of the package and the APIs may need to change in -the future. - -

-

- -To create a pbuffer, call -GLDrawableFactory.createGLPbuffer(). It is wise to call -GLDrawableFactory.canCreateGLPbuffer() first to ensure -the graphics card has pbuffer support first. The pbuffer is created -immediately and is available for rendering as soon as -createGLPbuffer returns. - -

-

- -A pbuffer is used in conjunction with the GLEventListener mechanism by -calling its display() method. Rendering, as always, occurs while the -pbuffer's OpenGL context is current. There are render-to-texture -options that can be specified in the GLCapabilities for the pbuffer -which can make it easier to operate upon the resulting pixels. These -APIs are however highly experimental and not yet implemented on all -platforms. - -

- -

GLU

- -

- -Jogl contains support for the GLU (OpenGL Utility Library) version -1.3. Jogl originally supported GLU by wrapping the C version of the -APIs, but over time, and thanks to the contributions of several -individuals, it now uses a pure-Java version of SGI's GLU library. The -pure Java port is enabled by default, and addresses stability issues -on certain Linux distributions as well as the lack of native GLU 1.3 -support on the Windows platform. In case of problems with the Java -port, the C version of the GLU library may be used by specifying the -system property -Djogl.glu.nojava on the command -line. All of the same functionality is exposed with both the Java and -C versions of the GLU library; currently NURBS support is the only -missing feature on both sides. If you run into problems with the Java -port of the GLU library please file a bug using the Issue Tracker on -the Jogl home page. - -

-

- -To use the GLU, simply instantiate a GLU object via new -GLU() at the beginning of your program. The methods on the GLU -object may be called at any point when an OpenGL context is current. -Because the GLU implementation is not thread-safe, one GLU object -should be created for each GLEventListener or other entity performing -OpenGL rendering in a given thread. - -

- -

More Resources

- -

- -The JOGL -forum on javagaming.org is -the best place to ask questions about the library. Many users, as well -as the Jogl developers, read this forum frequently, and the archived -threads contain a lot of useful information (which still needs to be -distilled into documentation). - -

-

- -The JOGL demos provide -several examples of usage of the library. - -

-

- -Pepijn Van Eeckhoudt, Kevin Duling and Abdul Bezrati have done JOGL ports of -many of the the NeHe demos. These are small examples of various -pieces of OpenGL functionality. See also the NeHe web site. - -

-

- -Pepijn also did a JOGL port of -Paolo Martella's GLExcess -demo. To see the news update about this port, go to the main GLExcess -site and scroll down. - -

-

- -Gregory Pierce's introduction -to JOGL is a useful tutorial on starting to use the JOGL library. - -

-

- -For release information about the JOGL library, please see the JOGL Release -Information thread on the JOGL forum on javagaming.org. - -

-

- -Please post on the JOGL forum if you have a resource you'd like to add -to this documentation. - -

- -

Platform Notes

- -

All Platforms

- -

- -The following issues, among others, are outstanding on all platforms: - -

- - - -

Windows

- -

- -For correct operation, it is necessary to specify the system property --Dsun.java2d.noddraw=true when running JOGL applications -on Windows; this system property disables the use of DirectDraw by -Java2D. There are driver-level incompatibilities between DirectDraw -and OpenGL which manifest themselves as application crashes, poor -performance, bad flickering, and other artifacts. This poor behavior -may exhibit itself when OpenGL and DirectDraw are simply used in the -same application, not even just in the same window, so disabling -Java2D's DirectDraw pipeline and forcing it to use its GDI pipeline is -the only way to work around these issues. Java Web Start applications -may set this system property by adding the following line to the -<resources> section of the JNLP file: 

-<property name="sun.java2d.noddraw" value="true"/>
- -

-

- -There is a serious memory leak in ATI's OpenGL drivers which is -exhibited on Windows XP on Mobility Radeon 9700 hardware. It's -possible it will be present on other hardware as well though it was -not reproducible at the time of this writing on desktop Radeon -hardware or older ATI mobile chips. The bug is documented in JOGL Issue -166 and a bug has been filed with ATI. You can confirm the -presence of the bug either with the test case in that bug report or by -simply running the Gears demo; if the process size grows over time in -the Task Manager, the memory leak is present on your hardware. For the -time being, you can work around this memory leak by specifying the -system property -Djogl.GLContext.nofree on the command -line when launching your JOGL applications. There is no good -general-purpose workaround for this bug which behaves well on all -hardware. - -

- -

Linux

- -

- -The Sun JDK "compatibility" RPMs (java-1.5.0-sun-compat, -java-1.6.0-sun-compat) provided by jpackage.org are incompatible with -JOGL. These RPMs symlink an internal JDK directory to /usr/lib, which -overrides how both NVidia and ATI currently provide their drivers to -some Linux distributions, which is through an override in -/etc/ld.so.conf (actually, in /etc/ld.so.conf.d). The implicit -presence of /usr/lib on LD_LIBRARY_PATH forces the /usr/lib/libGL.so.1 -version of OpenGL to be used, which is typically Mesa and which will -provide only software rendering. - -

-

- -Unfortunately the JPackage maintainers have so far been unreceptive to -changing their installation mechanism; see this -mailing list posting. Until this is resolved, we strongly -discourage the use of the JPackage installers for the Sun JDK. -Instead, download the JRE or JDK installers directly from Sun's -website. - -

-

- -Archived forum postings illustrating this problem are here -and here. - -

- -

Solaris, Linux (X11 platforms)

- -

- -Support has been added to the JOGL library for allowing multiple -threads to each have an OpenGL context current simultaneously, for -example to implement multi-head CAVE-like environments. Normally a -global AWT lock is held between calls to GLContext.makeCurrent() / -release() for on-screen heavyweight contexts (for example, those -associated with a Canvas or GLCanvas). We have found this to be -necessary for stability purposes on all supported X11 platforms, even -with relatively robust drivers such as those from NVidia. - -

-

- -To enable multiple GLContexts to be made current simultaneously on X11 -platforms, specify the command line argument --Djogl.GLContext.optimize when starting the JVM. Note -that this may incur robustness problems, in particular when resizing -or moving windows. We have also found that ATI's proprietary drivers -do not work at all with this flag, apparently because they cause GLX -tokens to be sent to the X server for various GL calls even for direct -contexts. For this reason if the GLX vendor is ATI then this flag -currently has no effect. - -

- -

Mac OS X

- -

- -There are some problems with visual artifacts and stability problems -with some of the Jogl demos on Mac OS X. It appears that at least some -of these problems are due to bugs in Apple's OpenGL support. Bugs have -been filed about these problems and it is hoped they will be addressed -in the near future. - -

-

- -The Mac OS X port of Jogl, in particular the GL interface and its -implementation, can be used either with the provided GLCanvas widget -or with the Cocoa NSOpenGLView. In order to use it with Cocoa the -following steps should be taken: - -

- -NOTE: the Cocoa interoperability has not been retested -recently, though similar interoperability has been tested on other -platforms. Please report any problems found with using Jogl with an -NSOpenGLView. - -

-

- -The following issues remain with the Mac OS X port: - -

- -

- -

Version History

- -

- -JOGL's version history can be found online in the "JOGL Release -Information" thread in the JOGL forum. Comments about the 1.1 -release train are in the thread "JOGL 1.1 -released". - - - - diff --git a/engine/lib/jogl/gluegen-rt.jar b/engine/lib/jogl/gluegen-rt.jar deleted file mode 100644 index 7ac10a354..000000000 Binary files a/engine/lib/jogl/gluegen-rt.jar and /dev/null differ diff --git a/engine/lib/jogl/jME3-jogl-natives.jar b/engine/lib/jogl/jME3-jogl-natives.jar deleted file mode 100644 index 5b8c877d9..000000000 Binary files a/engine/lib/jogl/jME3-jogl-natives.jar and /dev/null differ diff --git a/engine/lib/jogl/jogl.jar b/engine/lib/jogl/jogl.jar deleted file mode 100644 index 305e99873..000000000 Binary files a/engine/lib/jogl/jogl.jar and /dev/null differ diff --git a/engine/lib/jogl/macosx_ppc/libgluegen-rt.jnilib b/engine/lib/jogl/macosx_ppc/libgluegen-rt.jnilib deleted file mode 100644 index 0ed9ba1b2..000000000 Binary files a/engine/lib/jogl/macosx_ppc/libgluegen-rt.jnilib and /dev/null differ diff --git a/engine/lib/jogl/macosx_ppc/libjogl.jnilib b/engine/lib/jogl/macosx_ppc/libjogl.jnilib deleted file mode 100644 index 66ba6d12c..000000000 Binary files a/engine/lib/jogl/macosx_ppc/libjogl.jnilib and /dev/null differ diff --git a/engine/lib/jogl/macosx_ppc/libjogl_awt.jnilib b/engine/lib/jogl/macosx_ppc/libjogl_awt.jnilib deleted file mode 100644 index 55d38655e..000000000 Binary files a/engine/lib/jogl/macosx_ppc/libjogl_awt.jnilib and /dev/null differ diff --git a/engine/lib/jogl/macosx_ppc/libjogl_cg.jnilib b/engine/lib/jogl/macosx_ppc/libjogl_cg.jnilib deleted file mode 100644 index d9d06dced..000000000 Binary files a/engine/lib/jogl/macosx_ppc/libjogl_cg.jnilib and /dev/null differ diff --git a/engine/lib/jogl/macosx_universal/libgluegen-rt.jnilib b/engine/lib/jogl/macosx_universal/libgluegen-rt.jnilib deleted file mode 100644 index 195628012..000000000 Binary files a/engine/lib/jogl/macosx_universal/libgluegen-rt.jnilib and /dev/null differ diff --git a/engine/lib/jogl/macosx_universal/libjogl.jnilib b/engine/lib/jogl/macosx_universal/libjogl.jnilib deleted file mode 100644 index eb8719aa9..000000000 Binary files a/engine/lib/jogl/macosx_universal/libjogl.jnilib and /dev/null differ diff --git a/engine/lib/jogl/macosx_universal/libjogl_awt.jnilib b/engine/lib/jogl/macosx_universal/libjogl_awt.jnilib deleted file mode 100644 index 2f16fbfb6..000000000 Binary files a/engine/lib/jogl/macosx_universal/libjogl_awt.jnilib and /dev/null differ diff --git a/engine/lib/jogl/macosx_universal/libjogl_cg.jnilib b/engine/lib/jogl/macosx_universal/libjogl_cg.jnilib deleted file mode 100644 index 562712108..000000000 Binary files a/engine/lib/jogl/macosx_universal/libjogl_cg.jnilib and /dev/null differ diff --git a/engine/lib/jogl/win32/gluegen-rt.dll b/engine/lib/jogl/win32/gluegen-rt.dll deleted file mode 100644 index 281d389d1..000000000 Binary files a/engine/lib/jogl/win32/gluegen-rt.dll and /dev/null differ diff --git a/engine/lib/jogl/win32/jogl.dll b/engine/lib/jogl/win32/jogl.dll deleted file mode 100644 index ee7a6a590..000000000 Binary files a/engine/lib/jogl/win32/jogl.dll and /dev/null differ diff --git a/engine/lib/jogl/win32/jogl_awt.dll b/engine/lib/jogl/win32/jogl_awt.dll deleted file mode 100644 index 2b47eee6e..000000000 Binary files a/engine/lib/jogl/win32/jogl_awt.dll and /dev/null differ diff --git a/engine/lib/jogl/win32/jogl_cg.dll b/engine/lib/jogl/win32/jogl_cg.dll deleted file mode 100644 index c64e2a2ea..000000000 Binary files a/engine/lib/jogl/win32/jogl_cg.dll and /dev/null differ diff --git a/engine/lib/jogl/win64/gluegen-rt.dll b/engine/lib/jogl/win64/gluegen-rt.dll deleted file mode 100644 index a7eb6f5b9..000000000 Binary files a/engine/lib/jogl/win64/gluegen-rt.dll and /dev/null differ diff --git a/engine/lib/jogl/win64/jogl.dll b/engine/lib/jogl/win64/jogl.dll deleted file mode 100644 index 990986f19..000000000 Binary files a/engine/lib/jogl/win64/jogl.dll and /dev/null differ diff --git a/engine/lib/jogl/win64/jogl_awt.dll b/engine/lib/jogl/win64/jogl_awt.dll deleted file mode 100644 index d247b4a0b..000000000 Binary files a/engine/lib/jogl/win64/jogl_awt.dll and /dev/null differ diff --git a/engine/lib/jogl/win64/jogl_cg.dll b/engine/lib/jogl/win64/jogl_cg.dll deleted file mode 100644 index 9e2f371b0..000000000 Binary files a/engine/lib/jogl/win64/jogl_cg.dll and /dev/null differ diff --git a/engine/lib/jogl2/gluegen-rt.jar b/engine/lib/jogl2/gluegen-rt.jar deleted file mode 100644 index 60e871f72..000000000 Binary files a/engine/lib/jogl2/gluegen-rt.jar and /dev/null differ diff --git a/engine/lib/jogl2/jogl.all.jar b/engine/lib/jogl2/jogl.all.jar deleted file mode 100644 index d8b6da4ee..000000000 Binary files a/engine/lib/jogl2/jogl.all.jar and /dev/null differ diff --git a/engine/lib/jogl2/linux32/libgluegen-rt.so b/engine/lib/jogl2/linux32/libgluegen-rt.so deleted file mode 100644 index e6730cec5..000000000 Binary files a/engine/lib/jogl2/linux32/libgluegen-rt.so and /dev/null differ diff --git a/engine/lib/jogl2/linux32/libjogl_desktop.so b/engine/lib/jogl2/linux32/libjogl_desktop.so deleted file mode 100644 index a88ae3f1d..000000000 Binary files a/engine/lib/jogl2/linux32/libjogl_desktop.so and /dev/null differ diff --git a/engine/lib/jogl2/linux32/libnativewindow_awt.so b/engine/lib/jogl2/linux32/libnativewindow_awt.so deleted file mode 100644 index 77a189a8f..000000000 Binary files a/engine/lib/jogl2/linux32/libnativewindow_awt.so and /dev/null differ diff --git a/engine/lib/jogl2/linux32/libnativewindow_x11.so b/engine/lib/jogl2/linux32/libnativewindow_x11.so deleted file mode 100644 index 1b9d885fd..000000000 Binary files a/engine/lib/jogl2/linux32/libnativewindow_x11.so and /dev/null differ diff --git a/engine/lib/jogl2/linux32/libnewt.so b/engine/lib/jogl2/linux32/libnewt.so deleted file mode 100644 index 6159024a3..000000000 Binary files a/engine/lib/jogl2/linux32/libnewt.so and /dev/null differ diff --git a/engine/lib/jogl2/nativewindow.all.jar b/engine/lib/jogl2/nativewindow.all.jar deleted file mode 100644 index 8e9fa19e9..000000000 Binary files a/engine/lib/jogl2/nativewindow.all.jar and /dev/null differ diff --git a/engine/lib/jogl2/nativewindow.os.x11.jar b/engine/lib/jogl2/nativewindow.os.x11.jar deleted file mode 100644 index 6a8303be6..000000000 Binary files a/engine/lib/jogl2/nativewindow.os.x11.jar and /dev/null differ diff --git a/engine/lib/jogl2/newt.all.jar b/engine/lib/jogl2/newt.all.jar deleted file mode 100644 index de21435d7..000000000 Binary files a/engine/lib/jogl2/newt.all.jar and /dev/null differ diff --git a/engine/lib/jogl2/newt.os.x11.jar b/engine/lib/jogl2/newt.os.x11.jar deleted file mode 100644 index da8d04be7..000000000 Binary files a/engine/lib/jogl2/newt.os.x11.jar and /dev/null differ