 Show Posts
|
|
Pages: [1]
|
|
1
|
Java Game APIs & Engines / JOGL Development / OpenGL ES 2.0 Support?
|
on: 2009-09-23 17: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 14: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.
|
|
|
|
|
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 21: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. |
|
|
|
|
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 18: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 18: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 10: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
|
|
|
|
|
11
|
Java Game APIs & Engines / JOGL Development / Re: multisampling dem no effect.
|
on: 2006-03-26 15: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 08: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 12: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 11: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 08: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.
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
