Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
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]
1  Java Game APIs & Engines / JOGL Development / OpenGL ES 2.0 Support? on: 2009-09-23 15:39:43
Please excuse this post if it's redundant --  I searched the forum, and found a relevant post from last May 23, which ended, "More discussion to come here on the forum."

My question: can anyone advise me on the state of being able to access OpenGL ES 2.0 from within JOGL?  I understand that there is a plan to allow developers to toggle among the various OpenGL versions using something called a "profile."  Am interested in converting some existing JOGL code to run under Android and would be glad to learn more about how I might do that.

Thanks in advance.
2  Java Game APIs & Engines / JOGL Development / Re: Memory leak with GLJPanel on: 2009-05-07 12:03:42
I would just like to add that I have noticed a similar memory leak running jogl 1.1.1 under Debian Linux.  When using PBuffers for rendering a sequence of offscreen images (one pbuffer per image), the memory usage rises steadily although I call pbuffer.destroy() after each rendering call.  When I hack the code to always use the same pbuffer there is no such memory usage increase.
3  Java Game APIs & Engines / JOGL Development / Re: Error - Please port CPU detection (32/64 bit) to your platform (mac os x/x86 on: 2009-03-15 09:15:11
I found the offending copy of gluegen-rt.jar (I'm embarrassed to admit it was in ~/Library/Java/Extensions!) and after removing it everything runs fine.  Thanks for the help.
4  Java Game APIs & Engines / JOGL Development / Re: [SOLVED]Mac OS X Intel 64-bit + Java 6 + jsr-231-webstart-current = exceptio on: 2009-03-15 09:13:32
I found the offending copy of glugen-rt.tar, removed it, and everything works fine.
5  Java Game APIs & Engines / JOGL Development / Re: Error - Please port CPU detection (32/64 bit) to your platform (mac os x/x86 on: 2009-03-13 20:06:08
I've got this problem too.  I've searched  everywhere I can think of for stray copies of gluegen-rt.jar, but without success -- I've found some copies but the problem is still there.  Can you give any hints about where one can look to find these unwanted copies? 

Also, I only see this problem with webstarts.  I try to activate the vm option "-verbose:class" in the jnlp file by adding
1  
java-vm-args="-verbose:class"
in the <j2se> tag,  but I don't see any verbose output on the java console. 

Thanks in advance for any tips.
6  Java Game APIs & Engines / JOGL Development / Re: Mac OS X Intel 64-bit + Java 6 + jsr-231-webstart-current = exception? on: 2009-03-13 19:45:30
Thanks for the quick reply.  The link to the source code of CPU.java was enlightening.

In the meantime I found the following thread in this forum regarding this problem:

http://www.java-gaming.org/topics/error-please-port-cpu-detection-32-64-bit-to-your-platform-mac-os-x-x86-64/19673/view.html

 Now I'm trying to follow the advice in the above thread, where  the blame is laid on old copies of gluegen-rt.jar lying around in system folders.


7  Java Game APIs & Engines / JOGL Development / [SOLVED]Mac OS X Intel 64-bit + Java 6 + jsr-231-webstart-current = exception? on: 2009-03-13 17:00:02
Has anyone else experienced the following exception when running JOGL under the conditions listed in the posting subject line? I had no problems developing with JOGL or running JOGL webstarts (using jsr-231-webstart-current) when using Java 5, but when I switch to Java 6 (for webstarts) I get the following exception:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError
   at com.sun.opengl.impl.JAWT.size(JAWT.java:17)
   at com.sun.opengl.impl.JAWT.create(JAWT.java:25)
   at com.sun.opengl.impl.JAWT$1.run(JAWT.java:97)
   at java.security.AccessController.doPrivileged(Native Method)
   at com.sun.opengl.impl.JAWT.getJAWT(JAWT.java:95)
   at com.sun.opengl.impl.macosx.MacOSXOnscreenGLDrawable.lockSurface(MacOSXOnscreenGLDrawable.java:144)
   at com.sun.opengl.impl.macosx.MacOSXOnscreenGLContext.makeCurrentImpl(MacOSXOnscreenGLContext.java:57)
   at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:134)
   at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
   at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:412)
   at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
   at de.jreality.jogl.Viewer.run(Viewer.java:421)
   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:300)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:210)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:200)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:195)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:187)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Caused by: java.lang.RuntimeException: Please port CPU detection (32/64 bit) to your platform (mac os x/x86_64)
   at com.sun.gluegen.runtime.CPU.<clinit>(CPU.java:73)
   ... 20 more
Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Attempt to make the same context current twice on thread Thread[AWT-EventQueue-0,6,main]
   at com.sun.opengl.impl.GLContextLock.lock(GLContextLock.java:83)
   at com.sun.opengl.impl.GLContextImpl.makeCurrent(GLContextImpl.java:131)
   at com.sun.opengl.impl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:182)
   at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:412)
   at javax.media.opengl.GLCanvas.display(GLCanvas.java:244)
   at de.jreality.jogl.Viewer.run(Viewer.java:421)
   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:300)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:210)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:200)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:195)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:187)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)


Any hints appreciated.
8  Java Game APIs & Engines / JOGL Development / Re: Integration of JOGL (JSR-231) into standard Java SE? on: 2007-07-15 16:15:47
Ken, 
Thanks for the information.  I'm content  with the situation as it is. The motivation for the original post was an inquiry by a possible user of our software (www.jreality.de), who was concerned that JOGL somehow might be less "official" than Java3D.  What is the status of Java3D in this respect?  Is it also a JSR project?  Is it slated to be included in the standard release? (I did read the post regarding the possibility that JOGL might become the default OpenGL backend for Java3D, so obviously the two packages are not considered competitors (nor in my opinion should they be)).

If it's not going too far, it would also interest me to know what is the significance of the "JSR" process; my impression was that, when successful,  it led to inclusion in the standard release.  Your reply implied that JSR validation means that the Java community officially recognizes JSR-231 as a "standard extension".  Is there a more specific definition of what that term means?

bienator -- thanks also for your post.  Unfortunately I don't know anything about the Consumer Runtime Environment.  It sounds like the core runtime would be actually reduced and many packages would become like JOGL, to be loaded on demand.  Could you point me to a URL where I might find out more?


9  Java Game APIs & Engines / JOGL Development / Integration of JOGL (JSR-231) into standard Java SE? on: 2007-07-13 08:30:24
Hello,

I expect this information is to be found in some posting on this forum, but my search queries didn't yield it. 

As I understand it, JOGL (under the name JSR-231) is slated to be included into the standard Java SE distribution in the near future. Is that still the case?  Has a a more specific date or release-version been made public?

Thanks in advance for any information,

Charles Gunn
10  Java Game APIs & Engines / JOGL Development / Re: multisampling dem no effect. on: 2006-04-13 18:46:04
Many thanks for the speedy fix! 

JSR-231, by the way, seems overall much more stable and reliable than previous releases. Thanks for the good work.
 
11  Java Game APIs & Engines / JOGL Development / Re: multisampling dem no effect. on: 2006-03-26 13:11:22
I just wanted to register a similar behavior.  I have Mac G5 desktop and a G4 laptop running identical software versions of OS X, java and JOGL-JSR-231.  On the previous JOGL version 1.1, both machines were capable of anti-aliasing using the "multisample" directive to the capabilities object. Now, running the same code, anti-aliasing only works on the desktop.  For example, the jogl-demos Multisampling demo exhibits this behavior.  The desktop has an Nvidia Geforce 5200 graphics card, while the laptop has an ATI 9600. 
12  Java Game APIs & Engines / JOGL Development / Re: Stereo viewing using quad buffers in JOGL on: 2004-07-19 06:31:45
Thanks for the replies.  In the meantime I have found an alternative method for displaying the stereo images, using the "twin monitor" capability of the nVidia driver.  Here's how it works:

In the system XConfig file I set up the graphics device as follows:
Section "Device"
 BoardName    "Quadro FX 3000"
 BusID        "1:0:0"
 Driver       "nvidia"
 Identifier   "Device[0]"
 Screen       0
 Option       "DPMS" "off"
#The following five lines are important for setting up "twin" mode
 Option "TwinView"
 Option "SecondMonitorHorizSync"     "31-75"
 Option "SecondMonitorVertRefresh"   "60"
 Option "TwinViewOrientation" "LeftOf"
 Option "MetaModes" "1280x1024, 1280x1024"
 
 Option       "Rotate" "off"
 VendorName   "NVidia"
 # for passive stereo:
 Option "ConnectedMonitor" "CRT,CRT"
EndSection

Then, I create a GLCanvas and put it into a frame, which I then set to be a fullscreen window.  Because of the way the configuration is set up, this has the size 2560x1024.  In my rendering loop, I draw the right and left eye views into the the left and right halves, resp.,  of the drawing buffer (which has the size 2560x1024) (using glViewport(1280,0,1280, 1024) and glViewport(0,0,1280,1024), not glDrawBuffer(GL_LEFT_BACK) and glDrawBuffer(GL_RIGHT_BACK)).

Note: the same procedure works fine to generate "classical" crosseyed stereo pairs, where the left half of the window contains a view for the right eye and the right half contains the left eye view.  For this reason, the option "TwinViewOrientation" is set to "LeftOf", since the second monitor (corresponding to the viewport (1280,0,1280,1024) contains the left-eye view, not, as you might expect, the right.

This solution works fine, and has the advantage that full-screen anti-aliasing works with it, where with the driver that we have installed, quad buffers does NOT work with full-screen anti-aliasing. (I don't know whether the latest Linux drivers from nVidia released end of June, correct this bug).

I can post details if anyone is interested.
13  Java Game APIs & Engines / JOGL Development / Stereo viewing using quad buffers in JOGL on: 2004-07-12 10:09:47
I am encountering problems enabling stereo viewing in JOGL. We have nVidia NV35GL [Quadro FX 3000] cards, and are running Linux.  I try to enable stereo in JOGL using the following:
           GLCapabilities capabilities = new GLCapabilities();
           capabilities.setStereo(true);
           canvas = GLDrawableFactory.getFactory().createGLCanvas(capabilities);

On machines without quad buffer support, this code fails.  On machines with quad buffers, it succeeds.   However, in the latter case, the program then encounters an exception: "unable to make context current".  Omitting the call to setStereo() removes this exception.

I would be interested in hearing from anyone else in the community who has had experience with enabling stereo viewing in JOGL.  Any sample code that successfully achieves this would be very welcome.
14  Java Game APIs & Engines / JOGL Development / Re: ...jogl.GLException: Unable to lock surface on: 2004-06-22 09:26:12
├čI am also currently struggling with an exception of this type.  The JOGL User's Guide indicates that it has to do the with multi-threaded environment of Java interacting with the C-origins of OpenGL:
(the User's Guide is available at https://jogl.dev.java.net/nonav/source/browse/*checkout*/jogl/doc/userguide/index.html?rev=HEAD&content-type=text/html).  Here's a relevant quote:

"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 GLDrawable.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()."

So, the problem referred to in this thread might be avoided by following the advice given here.  That is, store off state in the keyboard and mouse listeners, but don't do anything that will directly cause display of a GLDrawable on the event-handling thread.

Unfortunately, there are still situations where it is hard to avoid having display called from the wrong thread (for example, an IDE that instantiates instances of Java objects: when that Java object contains a GLDrawable, the wrong thread may inadvertantly be called to display it -- at least that what seems to be causing the exceptions I'm encountering).  

Hope this helps.

Thanks to whoever wrote the User's Guide.  And, if you're reading this, what about updating it with any new and useful developments in the themes it deals with?
15  Java Game APIs & Engines / JOGL Development / Threading issues: 2 GLCanvases in one JFrame on: 2004-03-11 07:08:15
I have been very pleased with the results of working with JOGL, running under Mac OS 10.3.2, using Java 1.4.2.   I have read the User's Guide and am in a general way aware that there are threading issues with JOGL. I recently encountered such a problem, when I tried to pack two GLCanvases (each representing a different camera viewing the same scene graph) into one JFrame.  The program complained as follows:

           java.lang.IllegalMonitorStateException: current thread not owner
                 at net.java.games.jogl.impl.JAWT_DrawingSurface.Unlock0(Native Method)
                 at net.java.games.jogl.impl.JAWT_DrawingSurface.Unlock(JAWT_DrawingSurface.java:60)
                 at net.java.games.jogl.impl.macosx.MacOSXOnscreenGLContext.unlockSurface(MacOSXOnscreenGLContext.java:236)
   ... (more stack frames)

and also complained about deallocing memory that hadn't been allocated.

Can someone provide either or both of the following:
   1) A simplified explanation of exactly what the thread problem here is?
   2) A solution for the problem.

Thanks in advance.
Pages: [1]
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (23 views)
2014-08-19 09:29:53

Tekkerue (22 views)
2014-08-16 06:45:27

Tekkerue (21 views)
2014-08-16 06:22:17

Tekkerue (12 views)
2014-08-16 06:20:21

Tekkerue (19 views)
2014-08-16 06:12:11

Rayexar (57 views)
2014-08-11 02:49:23

BurntPizza (37 views)
2014-08-09 21:09:32

BurntPizza (29 views)
2014-08-08 02:01:56

Norakomi (36 views)
2014-08-06 19:49:38

BurntPizza (66 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org 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‑gaming.org
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!