Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (707)
Games in Android Showcase (207)
games submitted by our members
Games in WIP (781)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2
1  Java Game APIs & Engines / JOGL Development / Re: OpenGL 4.0 released on: 2010-03-26 20:36:12
Been busy keeping my eyes out with the GTX480 "out" today. I need to replace my old 880GTX in the worst way to do atomics (openCL), & did not want old stuff.  In my travels I saw this, which out lines ATI's driver release

FYI, I need to credit SemiAccurate.  They listed that Amazon was starting to take orders about 2PM, & I got my order in.  Hopefully, that works!
2  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2010-03-09 16:25:14
Being in development of a commercial product using OpenCL, this about as far away from a waste of time as I can think of.  Guess it boils down to your perspective.

I would point out from an OpenCL perspective,  OpenCL IS NOT an API to be interfaced.  It is "C for the GPU".  Any host language is just OpenCL's bitch.   C is far an away the bitch of choice.  It has a natural advantage which will not be overcome easily.  Even C++, whose bindings are going to be officially part of the next release, is destined for the land of misfit hosts with Java, C#, Delphi, Python, and hell maybe even Cobol ;-)

What is interesting is in that just 6 mos of release, there is already a lunatic fringe out there doing experiments writing hybrid implementations of languages.  By that I mean that while technically there is a host language & OpenCL, the programmer cannot really tell.  There is a Scala implementation written on top of OpenCL4Java (sorry about that lunatic thing Olivier), as just one example.  That is why I encouraged experimenting with some OpenGL like thing, actually in OpenCL.

Any OpenCL system written with a monster # of host calls is probably in trouble anyway.  That's why that little contest is not about OpenCL.  Just using it.  Any visibility that gives to Java as a viable conventional host language is just icing on the cake.

Concentrating on OpenGL, while just keep an eye on OpenCL is probably the best option.
3  Java Game APIs & Engines / JOGL Development / The thriller in Manilla, JNA vs JNI using OpenCL on: 2010-03-08 22:55:18
I personally would not make my OpenCL bindings decision based on this, but I think we all know this is not about OpenCL, rather OpenGL.  OpenCL should be discussed in it's thread.  It is just a proxy here. Michael, sorry if I am forcing your hand too early or messing up your schedule. Just say if you wish to postpone.  As long as you run both sides yourself on the same hardware, you do not have to worry about distribution before you had planned.

The JNA side is using OpenCL4Java.  This is what JavaCL is built on.  We have 2 names so we knew what we were referring to when talking.  I am probably the only person who uses OpenCL4Java directly.

I ran this on a Snow Leopard Macbook wt 2 GPU's & Intel(R) Core(TM)2 Duo CPU P8800 @ 2.66GHz.  I tried to put out some rules, listed right in the source, but they can be improved do so.  I am not the referee, my schedule is pretty tight.

When I did a run of 1000 loops (each loop is 5 calls) , I got an Avg msec per loop: 0.19629501.  When I did 1 million, I got 0.018008577.  The million is probably better, if you are doing 1000 OpenGL calls just for 1 frame, but play with it.
- - - - - - - - - - - - - - - - -
package whatever;
import java.nio.*;
import com.sun.jna.*;
import com.sun.jna.ptr.*;
import com.ochafik.lang.jnaerator.runtime.NativeSize;
import com.ochafik.lang.jnaerator.runtime.NativeSizeByReference;
import com.nativelibs4java.opencl.library.*;

 *  JNA version, using OpenCL4Java(the low level bindings for JavaCL).  Add this jar to project to run.
 *  Goal: test call overhead of JNI vs JNA.  OpenCL has dev info calls which are
 *  short in duration.  They DO NOT touch GPU's.  The type of data returned can be found
 *  by running
 *  Not every possible query performed, only one of each return type.  Too much work for
 *  all.  Control using LOOP_COUNT.
 *  Turn on the clock only after Platform, dev created.
 *  Rules:
 *     - platform must be NVidia 195 or 196 if Windows.  Win7 64-bit if possible.
 *     - Do not even bothering to create a context or command queue.
 *     - The avg time/loop should be compared on exact same hardware.  The value itself is
 *       NOT important, only the difference in values.
 *     - MUST "look" at value, since this could be different.
 *     - MUST include any methods which one would reasonable need to do inside the
 *       loop.  e.g. getPointer() methods for JNA
 *     - assigning return code required, but can be actual checking can be commented out
public class JNIvsJNAviaOpenCL{
    static int LOOP_COUNT = 1000000; // 1M
    static float NANOS_PER_MILLI = 1000000F;

    public static void main(String[] argv){
        // get platform, usually only one, unless mixing NVidia & ATI GPU's
        OpenCLLibrary.cl_platform_id[] platformArray = new OpenCLLibrary.cl_platform_id[1];
        int err = OpenCLLibrary.INSTANCE.clGetPlatformIDs(1, platformArray, null);
        if (err != OpenCLLibrary.CL_SUCCESS)
            throw new RuntimeException("failed to get platform " + err);

        // get any device, the device itself not important, but need to do queries against something
        OpenCLLibrary.cl_device_id[] deviceArray = new OpenCLLibrary.cl_device_id[1];
        err = OpenCLLibrary.INSTANCE.clGetDeviceIDs(platformArray[0], OpenCLLibrary.CL_DEVICE_TYPE_ALL, 1, deviceArray, null);
        if (err != OpenCLLibrary.CL_SUCCESS)
            throw new RuntimeException("failed to get device " + err);

        // assorted vars declared out side the loop
        OpenCLLibrary.cl_device_id dev = deviceArray[0];  // do not want to index dev array every call
        long cummTime = 0L;
        long start;

        NativeSize szInt = new NativeSize(Native.LONG_SIZE);
        IntByReference valInt = new IntByReference();
        int lookedAtInt;

        NativeSize szLong = new NativeSize(8);
        LongByReference valLong = new LongByReference();
        long lookedAtLong;

        NativeSize szSizeT = new NativeSize(8);
        NativeSizeByReference valSizeT = new NativeSizeByReference();
        long lookedAtSizeT;

        NativeSize szString = new NativeSize();
        NativeSizeByReference nCharBuf = new NativeSizeByReference();
        ByteBuffer valStringBuf;
        int length;
        String lookedAtString;

        long force_JVM_to_do = 0;

        for(int i = 0; i < LOOP_COUNT; i++){
            start = System.nanoTime();

            // int based info queries
            err = OpenCLLibrary.INSTANCE.clGetDeviceInfo(dev, OpenCLLibrary.CL_DEVICE_VENDOR_ID, szInt, valInt.getPointer(), null);
//            if (err != OpenCLLibrary.CL_SUCCESS)
//                throw new RuntimeException("failed int query " + err);
            lookedAtInt = valInt.getValue();

            // long based info queuies
            OpenCLLibrary.INSTANCE.clGetDeviceInfo(dev, OpenCLLibrary.CL_DEVICE_MAX_MEM_ALLOC_SIZE, szLong, valLong.getPointer(), null);
//            if (err != OpenCLLibrary.CL_SUCCESS)
//                throw new RuntimeException("failed long query " + err);
            lookedAtLong = valLong.getValue();

            // tSize based info queuies
            OpenCLLibrary.INSTANCE.clGetDeviceInfo(dev, OpenCLLibrary.CL_DEVICE_IMAGE2D_MAX_WIDTH, szSizeT, valSizeT.getPointer(), null);
//            if (err != OpenCLLibrary.CL_SUCCESS)
//                throw new RuntimeException("failed tsize query " + err);
            lookedAtSizeT = valSizeT.getValue().longValue();

            // string based info queuies  (2 calls, first to find out size; 2nd to get)
            err = OpenCLLibrary.INSTANCE.clGetDeviceInfo(dev, OpenCLLibrary.CL_DRIVER_VERSION, szString, null, nCharBuf);
//            if (err != OpenCLLibrary.CL_SUCCESS)
//                throw new RuntimeException(ErrorDesc.getErrorDesc(err));

            length = nCharBuf.getValue().intValue();
            valStringBuf = NIO_Utils.getByteBuffer(length);

            // call again to get the actual value
            err = OpenCLLibrary.INSTANCE.clGetDeviceInfo(dev, OpenCLLibrary.CL_DRIVER_VERSION, szString, Native.getDirectBufferPointer(valStringBuf), null);
//            if (err != OpenCLLibrary.CL_SUCCESS)
//                throw new RuntimeException("failed string query " + err);
//            else
                lookedAtString = NIO_Utils.toString(valStringBuf);

            cummTime += System.nanoTime() - start;
            force_JVM_to_do += lookedAtInt - lookedAtLong + lookedAtSizeT - lookedAtString.length();

        System.out.println("Avg ms per loop: " + (cummTime/(LOOP_COUNT * NANOS_PER_MILLI)));
        System.out.println("ignore:  " + force_JVM_to_do);


4  Java Game APIs & Engines / JOGL Development / JOCL da bienator gets it's own thread / context on: 2010-03-07 23:42:39
Catch 22 is not the place to discuss JOCL, due to that threads size /scope.  I did not actually reply there with JOCL in mind.  No great loss.  Just some unrelated comments to start:
- - - - - - - - - - -
I have not observed nor tried to measure contention, done I assume by comparing throughput of multi threaded vs single.  A single thread for all GPUs using synchronized blocking assumes homogeneous GPU's & almost identical work.  One person tried to do load balancing with a single thread and no blocking, but I think he gave up due to all the problems.  My kernels do not do the exact same amount of work every time either, sort of a close range, so sync could hold one or the other up each iteration.  More GPU's make this worse.  With OpenGL sync is of overriding importance, as displaying frames out of order, or irregularly is not likely acceptable.

I have never had fewer CPUs than GPUs, where that would really kick in though.  From Netbeans profiling data of Nvidia's implementation, it is clear their blocking is very CPU intense.  By this I mean all the CPU time is used spinning, waiting for kernels to finish & enqueue or passing args is nothing.  Getting the minimum wait time during a worksize calibration operation, which is wise to do, could be very useful.  You could then put a Thread.sleep(85% min) after the last enqueue in the set & then block.  I am doing this as part of a redesign, but have not fired up the full system to test.
- - - - - - - - - - -
You described low/gluegen built and high/OO level bindings before.  Are you still doing / going to do the high level, cause that stuff is not built by computer?  The high level bindings Olivier continues to improve, called JavaCL (low/JNAerator built is OpenCL4Java), & looks outstanding.  My own OO level is not near as comprehensive, and am going to drop it when I get the chance.  I only built my own, because there weren't any when I started.  That is where enhancements in API will not naturally be realized.
- - - - - - - - - - -
That is it for now.  Good luck on your project! Maybe get a section for JOCL someday, but no hurry.  Actually there are already a lot of OpenCL forums, probably too many right now.
5  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2010-03-07 19:04:30
I was just putting the option out.  I have no direct interest in OpenGL, and no axe to grind.  It would entail some re-write, but Gluegen is aging / self maintained and a resource guzzler by comparison.

OpenCL is a different story.  I have a huge interest.  What happened in the past with OpenGL may not repeat itself with OpenCL.  The primary reason is OpenGL is just an API (ignoring GLSL) and OpenCL is a full C99 language.  There are API calls to manage it (compiling, exec, read/write) from what is called the host language, but the big action is what is running on the GPU.  They are called kernels.  This is attracting a constituency from everywhere, like Research-Engineering-Finance.  Being open has probably caused it to already be bigger than CUDA & CAL.  It seems very little is right now involved with vision.

Do not get me wrong, I am very impressed with Michael, & JOCL as a university thesis.  JOCL could put him in a good position for the future.  OpenCL might change rapidly though, and I am not sure competing for resources with JOGL for updates is a arrangement that is best for me.

I would also point out that the Particles Demo from the above site hands off to JOGL too, when it is done.  Performance seemed impressive to me anyway.  At my max resolution, 2560 x 1600, & old 8800 GTX, it does not really slow down that much with 1M particles.  It also seemed mildly entertaining. It makes me wonder if something similar to an OpenGL pipeline, or Java3D might be implementable as a OpenCL kernel pipeline.  Not suggesting this any direct path forward, but it might be a good proof of concept for some else's studies.
6  Java Game APIs & Engines / JOGL Development / Re: Catch 22 for jogl on: 2010-03-06 00:20:48

generating static methods is one single flag in gluegen (i believe its even on by default). JNA is far more convincing as an alternative as the generator of LWJGL for me.
I know there are a lot more calls in OpenGL vs OpenCL,  but I would consider JNA for JOGL as well (I do not actually know what LWJGL is).  Is the CPU constantly pegged on all or any of the games made using JOGL?  If not, then there might be high price being paid for static calls, and the drop off using JNA negligible.  Even if this was the case, I think not nearly all of it is being tied up in actual Native calls.  Aren't Display Lists an effective mechanism for reducing the volume of calls anyway?

Gluegen is something that needs to be understood, maintained, & you actually have do builds on all the platforms that need support (or maintain cross compilers).  This effectively means that JOGL is being built / maintained from the ground up.  Using JNAerator to build your JNA bindings frees up resources to actually work on the high level bindings for JOGL 3.0, or whatever.  There's JNA support underneath.

Looks like you will be out of school in the not too far future,  reducing the JOGL footprint could allow you to have a hobby project without comprising either it or work.  Olivier manages JNAerator & projects derived from it, specifically JavaCL, & I know he is out of school.  (For other readers who have Nvidia 195 or higher you could run JWS demos from, if interested)

I am only bringing this up now on page 6 of a marathon thread, because I thought it might be a blind spot.

7  Java Game APIs & Engines / JOGL Development / Re: weird mac+fullscreen excl. framerate issue on: 2010-01-31 20:36:55
I have moved on to OpenCL4Java ( and maybe even to JavaCL ), so when I used JOGL it was never for visual purposes.  I do still check here occasionally.

Looking at your code, this is your trigger for fullscreen right, and you are always doing undecorated in your tests?
        //enable/disable the next two lines for fullscreen-excl. mode
        //GraphicsDevice device = getGraphicsConfiguration().getDevice();
        //device.setFullScreenWindow( this );

What happens if you use :

I thought this might be worth a shot, since it is only a one line change.
8  Java Game APIs & Engines / JOGL Development / Re: OpenCL(Open Computer Language) binding for Java on: 2009-08-17 15:18:38
I have started to use the nativelibs4java jar.  I got it to work with the NVidia Vista beta, with a little slight of hand.  That was I took the DLL from the SDK and copied it to system32 , changing the name to openCL.dll.  Nvidia release notes state that when openCL is in production, that it will be built into their video drivers, but not how.  Good enough for now.

I got the simplest program to run, where I get a device id, create a context with it, create a command queue with the context.  When cleaning up, i tried to release the command queue, causes an access violation.  Commenting that out, I cannot get clGetDeviceInfo to return success, and am a little stumped at the moment.

I saw the JOGL release note about OpenCL.  I also saw:

My efforts to get my GLSL shaders to work on ATI were a total disaster.  I resisted Cuda and open streams before, because they were proprietary,  but openCL looks great, and that is where graphics chip makers have their developers focused right now.  I will have my nVidia driver set for 180.x for as long as it takes.  I could help with your example, as well as anything above the binding level, like error description methods, actual objects wrapping the bindings like a device object.

I even have plans for java,util.concurrent interoperability, like maybe a openCL implemenation of the BlockingQueue, or CompletionService interfaces.  The one thing I do not care about is anything to with openGL interoperability.

Send me a mail message through this site if interested, otherwise I will need to continue on my current path.
9  Java Game APIs & Engines / Android / Re: Phone Performance on: 2009-07-31 21:53:47
I think this may actually be a Google Developer Phone,  essentially an OS unlocked G1.  If so, I agree this is not something to concern yourself from a support point of view.  Just give a DDT response (Don't do that).
10  Java Game APIs & Engines / Tools Discussion / Re: Hardware Testing Advice Needed on: 2009-06-19 04:19:59
Well, I dug up some answers.  First PCIe x16 version 1 & 2 cards and motherboards will work with one another, so it is a non-issue.

Second, as far as mixing NVidia & ATI cards, I found a thread on GPGPU.ORG which seems to say it will never work on Vista and beyond  Not interested in fighting gravity.  Will pull the GTX out.

Cost is not a big concern, but Mac notebooks are simply not competitive.  I think I was confusing the need of a new notebook with want.  I'll get a $599 mini with an NVidia 9400M, and be able to test changes on NVidia at the same time.  Testing 2 things at once is only good as long as it works, so I'll keep the GTX just in case of issues.
11  Java Game APIs & Engines / Tools Discussion / Hardware Testing Advice Needed on: 2009-06-18 19:39:29
I have a system with an AI goalseeker.  Have made an optional GPGPU Co-Processor, which shifts large amounts of work on to the GPU, via JOGL.  A typical goal search does about 50 billion texel (database) lookups, and I am guessing about a 0.8 trillion decision branches.

I have two outstanding, JOGL related, hardware testing needs:  ATI graphics cards, & Mac OS.
- - - - - - -
The system I have assembled is on an ASUS Striker Extreme motherboard with 2 PCIe x16 slots.  1 has a Geforce 8800 GTX, where the Co-Processor was developed.  Assuming adequate power supply, can a ATI HD 4000 series be plug-in slot 2 (NO DISPLAY, NO SLI).  Would I need to get a PCIe x16 Gen 1.0 version, since this board is a little old?ÂȘ+HD+4800&f3=&f4=&f5=&f6=Yes&f7=0&f8=0&f9=0&f10=&f11=&f12=&f13=&f14=&f15=&f16=0&

If so, is there a way, in code, to switch which card is used to create a GLPbuffer?  How?  This DOES NOT have to done in production. The reason I say this is it has been a while since I wrote this part.  There are things in the on-line Java Docs, which look like they are for the next version.  Should I just rip the GTX out, because either this won't work, I am too early, or it is not worth the grief?
- - - - - - -
I need a new Mac on a current OS.  I have an old Mac G5, with a pre-OpenGL 2.0 ATI, running the old Tiger version of MacOS.  My GLSL compiles, and technically returns results, immediately, but just garbage. That is why my Co-Processor is optional.  If I didn't also have a very old notebook, I would just go with a cheap Mini, if I thought my Co-Processor would run on it.

Has anyone used a Macbook with 2 GPU's? The webpage describes them as a "NVIDIA GeForce 9400M integrated and NVIDIA GeForce 9600M GT discrete graphics processors".  This integrated & descrete stuff is just marketing speak for they toggle, right?  Does anyone know what happens when it is running Vista/Windows 7?  If I was showing my product to someone who might want to see it on Windows, I would not want the processor to be stuck just on one or the other.  Any suggestions?
12  Java Game APIs & Engines / Tools Discussion / Re: Why doesn't the ProGuard output work? on: 2009-06-15 21:26:35
First Android is a phone OS that just happens to not like that proguard option, disregard.

That website is fairly generic.  The jogl - User's guide,*checkout*/jogl/trunk/doc/userguide/index.html, has a section called 'Java Web Start integration'.  Quickly looking at your jnlp file, get rid of the security, and signing will not be required.  Get rid of jar references to jogl & gluegen-rt, and do not put them in your distribution.  I would get rid of <resources os="Windows"> section.  You don't have a binaries.jar, do you?  Get rid of the localhost arg in application-desc, unless you are actually are reading argv[].

Now the stuff missing that you actually need:
  • The entry for JOGL in resources   
  • Your application-desc does not have an entry point.  This should be kept by Proguard with something like:
    -keep public class* {
        public static void main(java.lang.String[]);
    How this is specified in the GUI version is your job.
  • I would rather be dead than require anything less than j2se version less than 1.5.  I show what I am using, but am thinking about adding the nodraw arg as well, based on the Windows section of JOGL User Guide.  You can probably default on heap size, I just need a lot myself.

The offline-allowed means the use network only required the first time.  Nothing is perfect, but the ace up Webstart's sleeve is:  when the computer starts the program, it checks for updates automatically, and brings down any newer files.  That means you can do enhancements and bug fixes, and they just show up!  FYI, that localhost codebase thing is usually just used for testing. 

Finally, there is a manual somewhere on Webstart, & a console you can turn on for Webstart for testing.  Goto the advanced Tab of the Java Control Panel for the console.

Hope that is enough help to get you thru. Your on your own. Good luck.

<?xml version="1.0" encoding="utf-8"?>
<!-- Test for Astro Prime Web Start Deployment -->
<jnlp spec="1.0+" codebase="file://localhost/C:/Users/Me/Desktop/test/" href="test.jnlp">
    <homepage href=""/>
    <description>This is a test.</description>
    <description kind="short">A test.</description>
    <icon href="testpic.gif"/>
    <icon kind="splash" href="testpic.gif"/>
    <j2se version="1.5" max-heap-size="200m" java-vm-args=""/>
    <jar href="test.jar"/>
    <extension name="jogl" href="" />
  <application-desc main-class="mypackage.My_Main">

13  Java Game APIs & Engines / Tools Discussion / Re: Why doesn't the ProGuard output work? on: 2009-06-15 03:06:59
Lets handle the easiest of your questions first. repackaging & overloading.  A Package hierarchy is useful information.  Why else would anyone make them?  This also makes it invaluable for reverse engineering.  Unless you specify to repackage, only the classes get renamed, so you might end up with something like:

Repackaging into a package, say 'q', would yield just q.a - q.e, making it a bigger job to make out how a system works.  On the proguardgui.jar program you are using, it is specified on the Obfuscation Tab. 

Unless you specify overloadaggressively, a class with 26 methods would get renamed a-z.  With overloadaggressively, unless the arguments are the same, they all will get named a.  Not going to stop anyone from decompiling and "reading" your source.  Understanding is another matter.  It too is specified on the Obfuscation tab.  FYI, Android applications Will not work, when this is used.
- - - - - - -
Next easiest is your lack of configuration file.  The proguardgui.jar program provides for not only viewing the configuration file generated, but saving it as well.  You can also load a previously saved configuration file from the Proguard tab to avoid specifying things every time.
- - - - - - -
Finally, Proguard is always much easier when you are dealing with all your own code, because you generally know if you are doing any classForNames, native methods, callbacks & can make sure those get both preserved and unchanged.  When dealing with the jars of other's things can get really complicated.  JOGL is a very indirect mechanism.  JOGL.JAR has classes for all the OS's (linux, mac, solaris, & windows).   Temporarily change the extension to ZIP, and browse with Explorer to see for yourself.

If you got Proguard to work with JOGL.JAR you would have make sure the classes of the other os's were kept to be multi-platform.  Seeing all the messages the Proguard session produced does not bode well for even getting one system to work.  Part of the reason you got such great compression is it got rid of probably everything, because nothing is being called directly by gluegen, so proguard gets rid of it.  This is very nice for cleaning out unused code from libraries, but that unused code is the other platforms, in this case.
- - - - - - -
I would recommend that in Eclipse you opt for generating a jar of just your own code.  Never used it, so you are on your own there.  Then using proguardgui.jar, specify your jar as in, and JOGL & gluegen-rt as libraries.  Then distribute the output jar and a JavaWebstart jnlp file.  No other jars or dlls AT ALL!!  JavaWebstart does everything for you on all platforms, including Windows i586 & Windows amd64.

You can even use JavaWebstart, when you are not using the web for distribution.  Just put the 2 files, and maybe an Icon into a directory, my_product, and tell people to install to c:\ . 

In your jnlp put a tag like:
<jnlp spec="1.0+" codebase="file://localhost/c:/my_product/" href="my.jnlp">. 

There is more to it than that, but there are other threads here and at sun which talk about this.
14  Java Game APIs & Engines / Tools Discussion / Re: Why doesn't the ProGuard output work? on: 2009-06-12 21:27:29
I do not do anything visual with OpenGL (only GPGPU), but I have used Proguard with JOGL.  It is hard to help you, when you did not include your Proguard configuration file.

First, you need to specify the JOGL libraries with a path:
-libraryjars  path/jogl.jar
-libraryjars  path/gluegen-rt.jar

You are have to be doing this already, or Proguard would probably not even work.

Wait, looking at the error message, just a wild guess, are you specifying jogl.jar and gluegen-rt.jar as -injars?  There probably is no class in called k, but I am too lazy to confirm.

If I am correct above, actually putting the jogl libraries into the final jar obviously causes a lot of issues to fight through.  It also ties you to a specific platform.  Do you plan on only deploying to the Windows platform?

If you goal is just ruining would be copycatter's day, specifying
# jam everything down to into 1 package, '_'
-repackageclasses _
does a pretty good job.
15  Java Game APIs & Engines / Tools Discussion / Re: any free de-bloaters?? on: 2009-01-25 18:55:15
There is a selection of Obfuscators, which are very effective. allows you to shrink & optimize, but this can be done without turning everything to gibberish, if you so wish.

You can also collapse your package hierarchy, which saves space, and still read the Exception stack traces.  This might be a problem, if you did not write those libraries, but again this is optional.
16  Java Game APIs & Engines / Tools Discussion / Re: NetBeans' gui and Java3D on: 2008-08-04 22:43:37
What version of Netbeans are you running?  Running 6.1, I do not even see a Canvas3D.  I thought Java 3D was deadish.

Do you really mean GLCanvas, that you get with JOGL plug-in?
17  Java Game APIs & Engines / Tools Discussion / Re: Transition problem to Netbean 6.1 from 6.0 on: 2008-05-16 18:08:35
That was it! Thanks.
18  Java Game APIs & Engines / Tools Discussion / Transition problem to Netbean 6.1 from 6.0 on: 2008-05-16 16:55:02
Today installed Netbeans 6.1 on a Vista machine which had Netbeans 6.0 and the JOGL plug-in.  Said yes to copy settings found of the previous version.

When started,  any classes referencing* have compile problems.  Installed plug-in to 6.1, and got the same jogl-runtime & jogl-project directories in the 6.1 subdirectory of .netbeans.

All code now compiles, and runs until JOGL operations, then just terminates.  The JOGL Capabilities Dialog generates the Exception below.  Does the JOGL plug-in work on 6.1, or is this a transition problem?  My 6.0 installation still works fine, and FYI I never do manual installs of JOGL outside of putting in the plug-in.

java.lang.UnsatisfiedLinkError: no jogl in java.library.path
   at java.lang.ClassLoader.loadLibrary(
   at java.lang.Runtime.loadLibrary0(
   at java.lang.System.loadLibrary(
   at com.sun.opengl.impl.NativeLibLoader.loadLibraryInternal(
   at com.sun.opengl.impl.NativeLibLoader.access$000(
   at com.sun.opengl.impl.NativeLibLoader$DefaultAction.loadLibrary(
   at com.sun.opengl.impl.NativeLibLoader.loadLibrary(
   at com.sun.opengl.impl.NativeLibLoader.access$200(
   at com.sun.opengl.impl.NativeLibLoader$
   at Method)
   at com.sun.opengl.impl.NativeLibLoader.loadCore(
   at java.lang.Class.forName0(Native Method)
   at java.lang.Class.forName(
   at org.openide.util.actions.CallableSystemAction$
   at org.netbeans.modules.openide.util.ActionsBridge.doPerformAction(
   at org.openide.util.actions.CallableSystemAction.actionPerformed(
   at javax.swing.AbstractButton.fireActionPerformed(
   at javax.swing.AbstractButton$Handler.actionPerformed(
   at javax.swing.DefaultButtonModel.fireActionPerformed(
   at javax.swing.DefaultButtonModel.setPressed(
   at javax.swing.AbstractButton.doClick(
   at javax.swing.plaf.basic.BasicMenuItemUI.doClick(
   at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(
   at java.awt.Component.processMouseEvent(
   at javax.swing.JComponent.processMouseEvent(
   at java.awt.Component.processEvent(
   at java.awt.Container.processEvent(
   at java.awt.Component.dispatchEventImpl(
   at java.awt.Container.dispatchEventImpl(
   at java.awt.Component.dispatchEvent(
   at java.awt.LightweightDispatcher.retargetMouseEvent(
   at java.awt.LightweightDispatcher.processMouseEvent(
   at java.awt.LightweightDispatcher.dispatchEvent(
   at java.awt.Container.dispatchEventImpl(
   at java.awt.Window.dispatchEventImpl(
   at java.awt.Component.dispatchEvent(
   at java.awt.EventQueue.dispatchEvent(
   at org.netbeans.core.TimableEventQueue.dispatchEvent(
[catch] at java.awt.EventDispatchThread.pumpOneEventForFilters(
   at java.awt.EventDispatchThread.pumpEventsForFilter(
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(
   at java.awt.EventDispatchThread.pumpEvents(
   at java.awt.EventDispatchThread.pumpEvents(

19  Java Game APIs & Engines / JOGL Development / Re: Possible bug wt GLSL access of GL_TEXTURE_2D on Geforce 8 on: 2008-02-14 15:28:56

Thanks!  I guess, I created unnecessary problems in trying to do some future proofing of my app.  I had not found any info which contrasts all of the various texture targets, in enough detail, in a way I understood, for me to spot this.   GL_TEXTURE_RECTANGLE_ARB is not even mentioned in Redbook..

I need exact texels from my texture lookups, so I'll just use GL_TEXTURE_RECTANGLE_ARB.
20  Java Game APIs & Engines / JOGL Development / Re: Possible bug wt GLSL access of GL_TEXTURE_2D on Geforce 8 on: 2008-02-13 21:19:11
import java.nio.*;
import com.sun.opengl.util.BufferUtil;

public class Texture2DProblem implements GLEventListener{
    public static void main(String[] argv) throws Exception{
        System.out.println("\nresults of GL_TEXTURE_RECTANGLE_ARB:  ");
        Texture2DProblem card = new Texture2DProblem(false);        
        System.out.println("\nresults of GL_TEXTURE_2D:  ");
        card = new Texture2DProblem(true);        
    final int       textureTarget;
    final String    texUniform;
    final String    texFunc;
    final GLPbuffer pBuffer;

    static final int WDITH = 10; // changing this, changes the amount of screw-up
    static final int HEIGHT = 1;
    static final int TEX_UNIT_NO = 0; // texture units sequential, so offset
    public Texture2DProblem(boolean isNPO2){
        if (isNPO2) {
            textureTarget = GL.GL_TEXTURE_2D;
            texUniform = " sampler2D ";
            texFunc = "texture2D";
        } else {
            textureTarget = GL.GL_TEXTURE_RECTANGLE_ARB;
            texUniform = " sampler2DRect ";
            texFunc = "texture2DRect";
        GLCapabilities caps = new GLCapabilities();

        // using fbo for all rendering, so get minimum sized pbuffer
        pBuffer = GLDrawableFactory.getFactory().createGLPbuffer(caps, null, 1, 1, null);        
        // not thread safe to let 'this' escape in constructor, do not do in production
    public void init(GLAutoDrawable drawable) {
        GL gl = drawable.getGL();
//        gl = new TraceGL(gl, System.err);
        int shaderId = createFragmentShader(gl,
                "uniform " + texUniform + " texNm;" +
                "\nvoid main() {" +
                "\n    vec4 tCoords = floor(gl_TexCoord[0]);" +
                "\n    vec4 texture = " + texFunc + "(texNm, vec2(tCoords) );" +
                "\n    texture.x = tCoords.x;" +
                "\n    gl_FragColor = texture;"+
        int prgmId = createAttachLinkUseProgram(gl, new int[]{shaderId});
        // load identity texture, and associate with sampler & bind to texture unit
        int texId = loadTexture(gl, get4ElementIdentityBuffer(WDITH, HEIGHT) );  
        associateTexture(gl, prgmId, TEX_UNIT_NO, "texNm", texId);
        // create and assign FBO to above texture,  can get away with only 1 fbo,
        // since only reading the same texel as writing
         int[] fb = new int[1];
        gl.glGenFramebuffersEXT(1, fb, 0);
    gl.glBindFramebufferEXT(GL.GL_FRAMEBUFFER_EXT, fb[0]);
       gl.glFramebufferTexture2DEXT(GL.GL_FRAMEBUFFER_EXT, FBO_ATTACHMENT, textureTarget, texId, 0);
    public void display(GLAutoDrawable drawable) {
        GL gl = drawable.getGL();
//        gl = new TraceGL(gl, System.err);
        renderQuad(gl, FBO_ATTACHMENT, WDITH, HEIGHT);
        // copy Attachment to a float buffer
        FloatBuffer buf = BufferUtil.newFloatBuffer(4 * WDITH * HEIGHT);        
        gl.glReadBuffer (FBO_ATTACHMENT);
        gl.glReadPixels(0, 0, WDITH, HEIGHT, GL.GL_RGBA, GL.GL_FLOAT, buf);
        // read thru float buffer and display results
        String coord = "Frag X coord :  ";
        String value = "Texture Value:  ";
        float[] pix = new float[4];
        for (int w = 0; w < WDITH; w++) {
            coord += ((w> 0) ? ", " : "") + pix[0];
            value += ((w> 0) ? ", " : "") + pix[1];
    public void reshape(GLAutoDrawable drawable, int x, int y, int width, int height) {}
    public void displayChanged(GLAutoDrawable drawable, boolean modeChanged, boolean deviceChanged) {}

    int createFragmentShader(GL gl, String source, boolean display){
        int shaderID = gl.glCreateShader(GL.GL_FRAGMENT_SHADER);

        String[] srcArray = source.split("\n");
        int count = srcArray.length;

        int[] lengths = new int[count];
        for (int i = 0; i < count; i++) {
            if (display) System.out.println(srcArray[i]);
            lengths[i] = srcArray[i].length();
        gl.glShaderSource(shaderID, count, srcArray, lengths, 0);

        return shaderID;
    int createAttachLinkUseProgram(GL gl, int[] shaderIDs){
        // create the program
        int prgmID = gl.glCreateProgram();
        // attach each of the shaders
        for(int i = 0; i < shaderIDs.length; i++){
             gl.glAttachShader(prgmID, shaderIDs[i] );
        //link & use the program
        return prgmID;
    int loadTexture(GL gl, FloatBuffer buf){        
        int[] texID = new int[1];
        // create a new texture name
        gl.glGenTextures(1, texID, 0);

        // bind the texture name to a texture target
        gl.glBindTexture(textureTarget, texID[0]);
        gl.glTexParameteri(textureTarget, GL.GL_TEXTURE_MIN_FILTER, GL.GL_NEAREST);
        gl.glTexParameteri(textureTarget, GL.GL_TEXTURE_MAG_FILTER, GL.GL_NEAREST);
        gl.glTexParameteri(textureTarget, GL.GL_TEXTURE_WRAP_S, GL.GL_CLAMP);
        gl.glTexParameteri(textureTarget, GL.GL_TEXTURE_WRAP_T, GL.GL_CLAMP);

        gl.glTexImage2D(textureTarget, 0, GL.GL_RGBA32F_ARB, WDITH, HEIGHT, 0, GL.GL_RGBA, GL.GL_FLOAT, buf);

        return texID[0];
     void associateTexture(GL gl, int prgmID, int unitNo, String samplerNm, int textureID) {        
        int sampler = gl.glGetUniformLocation(prgmID, samplerNm);
        gl.glUniform1i(sampler, unitNo);

        gl.glActiveTexture(GL.GL_TEXTURE0 + unitNo);
        gl.glBindTexture(textureTarget, textureID );
     FloatBuffer get4ElementIdentityBuffer(int width, int height) {
        int nTexels = width * height;
        int tVals = 4 * nTexels;
        FloatBuffer buffer = BufferUtil.newFloatBuffer(tVals);

        for (int i = 0; i < nTexels; i++)
            buffer.put(new float[] {i, i, i, i} );

        return buffer;
     void renderQuad(GL gl, int buffer, int width, int height){
        gl.glViewport(0, 0, width, height);
        (new GLU()).gluOrtho2D(0, width, 0, height);
        // assign buffer to render
        // ensure Texture unit 0 has the coordinates, explicitly
        gl.glTexCoord2i(0    , 0     ); gl.glVertex2i(0    , 0     );
        gl.glTexCoord2i(width, 0     ); gl.glVertex2i(width, 0     );
        gl.glTexCoord2i(width, height); gl.glVertex2i(width, height);
        gl.glTexCoord2i(0    , height); gl.glVertex2i(0    , height);

21  Java Game APIs & Engines / JOGL Development / Possible bug wt GLSL access of GL_TEXTURE_2D on Geforce 8 on: 2008-02-13 21:18:35
I believe I can demonstrate a bug with the GeForce 8800 GTX/PCI/SSE2 renderer, version 2.1.2 (ForceWare 169.25, on Vista).  I wish very much to be wrong, since then it will be within my control to fix .  Please take class below, and let me know of results of trying to reproduce on same or different hardware.

First, like the JOGL Texture class, I wish to dynamically use OpenGL 2.0 features when detected.  For textures, that means using GL_TEXTURE_2D textures, instead of GL_TEXTURE_RECTANGLE_ARB.

I am using GLSL, so doing this also requires that the source for the shader be generated on the fly.  This is not an obstacle, since I am already doing this to do things like specify sizes of arrays.

My self contained JOGL class, Texture2DProblem,  takes a boolean argument isNPO2, which sets 3 members that control which type of texture to use.  A PBuffer is created, but a framebuffer is used to all rendering / retrieving results from.  This is what the program does in init():
  • Creates a fragment shader, which returns it's X gl_TexCoord & the value from a texture read using it's coordinate.
  • Builds a texture, containing the offset from the beginning in each of it's 4 elements.
  • Associates that texture with the sampler in the shader
  • Creates a frame buffer with single attachment, mapped to above texture

The display() method, renders a 1 row quad, and displays a row of X coord & texture value.

When using GL_TEXTURE_RECTANGLE_ARB everything works as expected.  The GL_TEXTURE_2D version gets the X coord right, the texture lookup returns the first texel, or the last texel.  Is there a way this could not be a bug?

FYI, this class is meant to be as straight forward as possible.  Not included but also checked was:
  • Using older ARG version of shaders produces the same results.
  • Using a PBuffer by itself also produces the same results.

This is my output::
uniform  sampler2DRect  texNm;
void main() {
    vec4 tCoords = floor(gl_TexCoord[0]);
    vec4 texture = texture2DRect(texNm, vec2(tCoords) );
    texture.x = tCoords.x;
    gl_FragColor = texture;
Frag X coord :  0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0
Texture Value:  0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0

results of GL_TEXTURE_2D: 
uniform  sampler2D  texNm;
void main() {
    vec4 tCoords = floor(gl_TexCoord[0]);
    vec4 texture = texture2D(texNm, vec2(tCoords) );
    texture.x = tCoords.x;
    gl_FragColor = texture;
Frag X coord :  0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0
Texture Value:  0.0, 9.0, 9.0, 9.0, 9.0, 9.0, 9.0, 9.0, 9.0, 9.0
22  Java Game APIs & Engines / JOGL Development / Re: Determining the maximum size for pbuffers in jogl on: 2008-02-08 18:44:04
Sorry forgot this:
       int floatBits = 32;
       int floatAlphaBits = 32;
       int floatDepthBits = 0;

23  Java Game APIs & Engines / JOGL Development / Re: Determining the maximum size for pbuffers in jogl on: 2008-02-08 18:37:04
I looked at that previous thread, and it helped, but thought it time to find out via code, so I wrote the following code:
    public void getPBufferSz(GL gl, GLCapabilities caps){
        GLDrawableFactory factory = GLDrawableFactory.getFactory();
        GLPbuffer tstBuffer;
        // check width until it no longer works
        int sz = 512;
        boolean stillWorking = true;
        int highVal = 0;
                tstBuffer = factory.createGLPbuffer(caps, null, sz, 1, null);
                stillWorking = tstBuffer != null;
                if (stillWorking) tstBuffer.destroy();
            }catch(Exception ex){
                stillWorking = false;
             if (stillWorking){
                highVal = sz;
                sz *= 2;
        System.out.println("max width " + highVal);
        // check height until it no longer works
        sz = 512;
        stillWorking = true;
        highVal = 0;
                tstBuffer = factory.createGLPbuffer(caps, null, 1, sz, null);
                stillWorking = tstBuffer != null;
                if (stillWorking) tstBuffer.destroy();

            }catch(Exception ex){
                stillWorking = false;
            if (stillWorking){
                highVal = sz;
                sz *= 2;
        System.out.println("max height " + highVal);
        // check girth until it no longer works
        sz = 512;
        stillWorking = true;
                tstBuffer = factory.createGLPbuffer(caps, null, sz, sz, null);
                stillWorking = tstBuffer != null;
                if (stillWorking) tstBuffer.destroy();

            }catch(Exception ex){
                stillWorking = false;
            if (stillWorking){
                highVal = sz;
                sz *= 2;
        System.out.println("max girth " + highVal);

Now you have to already have a PBuffer, or Drawable to run this, but using Render GeForce 8800 GTX/PCI/SSE2, version 2.1.2 gets the following sysout:

max width 33554432
max height 8388608
max girth 4096

This suggests that on this renderer it not address bound.  However, if one is copying to texture or pingpong-ing , the practical limit would be the lower of the max girth and GL_MAX_TEXTURE_SIZE.

FYI, the capabilities used were:
        caps = new GLCapabilities();

Any comments?
24  Java Game APIs & Engines / JOGL Development / Re: Determining the maximum size for pbuffers in jogl on: 2008-02-07 16:27:49
I cannot say, but you should define the unit of size that is of interest to you, # of addressable pixels or memory.

There could also be a lot of factors which could play a part::
- whether double buffering or not
- the # of red, green, blue, alpha, & depth bits
- maybe whether or not you are using a floating point pBuffer or not.

I think any program is just going to have ask for what it wants, and report back when there are problems.
25  Java Game APIs & Engines / JOGL Development / Re: Accessing GL_LUMINANCE_ALPHA32F_ARB texture with Shader on: 2008-02-06 19:55:13

It makes sense that the luminance, the first element, would be spread across the 3 colors & and the alpha, the second element, would be in the alpha.  What a shock.

I find it easiest to specify vec4's as arrays rather than a color structure, because my data has nothing to do with color.  I need to take it more into account that color is the reason for OpenGL in the first place.
26  Java Game APIs & Engines / JOGL Development / Accessing GL_LUMINANCE_ALPHA32F_ARB texture with Shader on: 2008-02-05 22:51:35
I have a fully functional set of 3 textures, and a fragment shader with functions that access the textures and return structures, to effective have a database.

What I am concerned with is that one of them is comprised of 2 element, 32 bit float, texels. I access it like:

vec4 texel = texture2DRect(sampler_nm, addr);

What happens is texel[0], texel[1], & texel[2] all have the value of the first element that went in.  texel[3] has the value of the second element.  This sort of scares me.  I was hoping the first 2 elements would have the values, and [2] & [3] either be the next texel or be garbage.

This is occurring on a GeForce 8800 GTX/PCI/SSE2 renderer, but compiled using the ARB version of shaders.  How thin is the ice I am on, in terms of portability?  Should I redesign?  Does anyone know what 3 element texels do?
27  Java Game APIs & Engines / JOGL Development / Re: nVidia GLSL linking errors when uniforms mixed with array access on: 2008-01-31 23:39:22
Trying to do what you ask results in compile errors:
(1) : error C0000: syntax error, unexpected integer constant at token "<int-const>"
(1) : error C0501: type name expected at token "<int-const>"
(1) : warning C7011: implicit cast from "int" to "float"
(1) : error C1010: expression left of ."x" is not a struct or array
(1) : error C1010: expression left of ."y" is not a struct or array

Those after the first two, are just repercussions of the initial error, later in the source.

Michael (I believe);
I was only documenting this for others.  I think I am good.

It looks like just expressing the uniPair as a structure(.x or .y) fixes that issue in a shader am still test running.  Pretty sure you would get this error regardless of whether it is in dead code or not.

I changed my design in another shader to avoid the issue I had using a uniform to index an array.  Kind of cheated, and am not even using a uniform.  That shader completely tested!

It fails on GF 8, so it is very likely to fail on GF 7.

Thanks guys.

28  Java Game APIs & Engines / JOGL Development / nVidia GLSL linking errors when uniforms mixed with array access on: 2008-01-31 19:00:52
Have observed some problems when linking successfully compiled shaders using the GeForce 8800 GTX/PCI/SSE2 render, using ForceWare version 169.25.

uniform int   uniSingle;
uniform ivec2 uniPair;
void main() {
float myArray[25];

// using a uniform to access an array causes "error C1011: cannot index a non-array value"

// accessing a uniform itself as an array also causes the same link error

// this links though

I have employed permanent workarounds, but though I would document this when I could not it done so before.
29  Java Game APIs & Engines / JOGL Development / Re: JOGL OSX Leopard.. Stumped.. on: 2007-12-19 18:47:43
I think this mailing distribution list might be a good place to ask this question.

Searching previous threads for UnsatisfiedLinkError might also help.
30  Java Game APIs & Engines / JOGL Development / Re: Problem with JOGL/Interoperability bridge for MacOS X, Java 1.6 DP1 on: 2007-11-30 21:11:09
That was the problem.  I am now more familiar with JOGL then when I submitted the bug report.  Looking at the JOGL source code, I see the throwing of the "Not yet implemented" exception.  I am a GPGPU guy, and do not even use this, but thanks.  I ran this withdrawn JOGL demo, called twinkle, and am just the one who reported it.
Pages: [1] 2
Galdo (370 views)
2017-01-12 13:44:09

Archive (526 views)
2017-01-02 05:31:41

0AndrewShepherd0 (995 views)
2016-12-16 03:58:39

0AndrewShepherd0 (925 views)
2016-12-15 21:50:57

Lunch (1058 views)
2016-12-06 16:01:40

ral0r2 (1290 views)
2016-11-23 16:08:26

ClaasJG (1387 views)
2016-11-10 17:36:32

CoffeeChemist (1384 views)
2016-11-05 00:46:53

jay4842 (1468 views)
2016-11-01 19:04:52

theagentd (1243 views)
2016-10-24 17:51:53
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!