Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (512)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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: NVIDIA 7300 LE and stencil tests on: 2007-06-14 16:59:08
How stupid of me, I was not calling caps.setStencilBits(bits) to the GLCapabilities object used for creating my GLCanvas  Lips Sealed . Strangely, in some gpus, even without calling this method, stencil buffer worked.

OK, just 4 hours lost, and many drivers tested  Tongue .
2  Java Game APIs & Engines / JOGL Development / NVIDIA 7300 LE and stencil tests on: 2007-06-14 07:59:40
Hi all!

I recently installed an NVIDIA 7300 LE for tests with jsr231, and I got a very strange behavior. Stencil testing didn't work at all. I tested the exact same code on a Mobility Radeon 9000 and everything was working properly, but on the 7300LE stencil testing was not functioning, just as if stencil test was disabled. I used the DebugGL functionality to check for errors but nothing came up. Everything was passing the stencil test, even if GL_NEVER was the parameter used in the glStencilFunc!

The code I'm using to test ran succesfully on many GPUs, but I can't seem to figure out whta is going on with this card. I installed all latest drivers from nvidia and guru3d, with no results. Has anyone came up to similar behavior with this or other GPUs?

Ν
3  Java Game APIs & Engines / JOGL Development / Re: Maximized window causing slowdowns on: 2006-12-27 08:46:01
My recommendation would be to buy a new graphics card.

Well, a letter asking for a GeForce 8800 GTS has already been sent to Santa   Wink

However I don't think that I'm falling back to the pbuffer -> BufferedImage -> screen rendering path in the GLJPanel, as you suggested Ken. That's because I tested the same thing using a GLJpanel but without the -Dsun.java2d.opengl=true parameter, as I said at my first post. Although there was no acceleration, the app was working normally, even when the window is maximized, where the framerate is slow but significatly higher that that of the case of the accelerated GLJpanel. Also, I tried using a GLCanvas and the same thing happened some of the times the app  window was maximized, there was a very very slow framerate. Without the  -Dsun.java2d.opengl=true parameter, GLcanvas was working properly, even when window was maximized.

Same tests were run on a Mobility Radeon 9000 (yes, I know this is a very outdated card too  Undecided), but at all cases (GLCanvas or GLJpanel) when the -Dsun.java2d.opengl=true parameter was used, the whole application crashed. I even tried the Gears test, to avoid using my own code in case i was doing something wrong, but it also crashed. When the -Dsun.java2d.opengl=true param was not used, everything was working normally (GLCanvas or GLJpanel, maximized app window etc).

So I believe that the problem is related to the -Dsun.java2d.opengl=true parameter, because in some way it affects not only GLJpanel, but GLCanvas too. I'm attaching the Gears test error log, in case it helps.
4  Java Game APIs & Engines / JOGL Development / Maximized window causing slowdowns on: 2006-12-26 08:03:17
Happy holidays to all!

I'm experimenting with Java6 and the accelerated version of the GLJpanel, and I came across a strange behavior. When I maximized my app window, some times (not always), my app framerate dropped to 0.1 fps. This happened with GLJpanel, CompositeGLJpanel (Chris Campbell's component) and GLCanvas, and I noticed it also with the CompositeGLCanvas demo posted here some days ago. The runtime args I'm using are :  -Dsun.java2d.opengl=true -Dsun.java2d.noddraw=true. The noddraw parameter doesn't seen to affect the whole thing, and if I omit the java2d.opengl parameter, everything is normal, no frame rate drops when app window is maximized, but no acceleration for GLJpanel of course. Also, at all cases, when returning to the window original size, everything is normal.

I profiled my app using yourkit, and when maximizing the app window, the profiler shows that 100% of the time is consumed to
sun.java2d.opengl.OGLRenderQueue$QueueFlusher.run() but only 40% of that time goes to the display() call. Also reported hotspots are mostly calls to com.sun.opengl.impl.GLImpl.glCallList(int), and also calls to com.sun.opengl.impl.GLImpl.glDrawElements(int, int, int, Buffer).

Any ideas? I'm using a Geforce4ti4200, with the latest drivers and with the latest jogl version/nightly build.

5  Java Game APIs & Engines / JOGL Development / Pbuffer destroy on: 2006-12-07 00:38:59
Hi all

How can one destroy a pbuffer? I'm using a pbuffer for offscreen rendering, and when resizing is needed, I must get rid of the old one and replace it with a new. However, the old one stays in the video memory, because the free memory decreases when I try to destroy the old one and create a new one. I tried to call

1  
2  
3  
                pbuffer.getContext().destroy();
                pbuffer.removeGLEventListener(eventHandlingGLListener);
                pbuffer.destroy();


but with no result. Any ideas or hints? I'm using a mobility radeon 9000 and I cehc my free GPU memory using the ATI Tray Tools utility.

6  Java Game APIs & Engines / JOGL Development / DebugGL and GLContext on: 2006-11-01 12:02:42
Hi all,

I'm building an app where a series of gl drawing commands can be called by two different viewers, so as to render something in both a GLCanvas and a GLPbuffer (which shares the same context with the GLCanvas). I was getting some errors, and I used the DebugGL object to find out wht was going wrong. With every render cycle, a new DebugGL object was created, and subsequent rendering commands were issued using the new DebugGL object. I found my errors, but I noticed that when using the DebugGL object I got a GLException " This GL object is being incorrectly used with a different GLContext than that which created it". I checked the DebugGL code, and this exception is thrown if the context of the DebugGL object is no current. How can this happen since the DebugGL object is created from scratch each time something is rendered? Why I'm not getting the same error when using GL instead of DebugGL?
7  Java Game APIs & Engines / JOGL Development / Different uses of display calls on: 2006-10-26 15:09:50
Hi all

Suppose I have a GLAutoDrawable (drawable) and a GLEventListener(gllistener) attached to it.

Does the result of a call to a display method of the drawable, is the same with the following code:

1  
2  
drawable.getContext().makeCurrent();
gllistener.display(drawable);


Is this thread safe; What about if the drawable shares context with other drawables?

Thanks in advance


8  Java Game APIs & Engines / JOGL Development / Re: JSR231 and Java2D gpu/memory interaction on: 2006-09-28 11:29:39
Yes, Windows it is. I haven't specified the noddraw parameter, so this might be the cause. I'll give it an extensive try. I also mentioned this problem to a person a lot more experienced in java2d  than me, and he suggested that numeric extremities in affine transformations used image rendering could cause such erroneous behavior. I'll look into that direction also, in case something goes wrong with my arguments in image rendering .

Thanks again, Ken!
9  Java Game APIs & Engines / JOGL Development / JSR231 and Java2D gpu/memory interaction on: 2006-09-28 07:26:38
Hi all

I 'm working on an application which uses java2d to produce some images (using afine transformations), to be used as textures for a 3d scene rendered using JSR231 (latest version). Everything goes well, but after some random time (1-10 minutes of rendering and creating textures), the CPU load for my application goes to 100%. I'm using  a thread that is responsible for creating textures from java2d created images, and a queue which contains all the "jobs" waiting to be transformed into images by the thread. After the CPU load goes to 100%, no jobs from queue are processed further.

I got the following thread dump when that happened:

"TilePainter3D 0" daemon prio=2 tid=0x0d9e7650 nid=0x870 runnable [0x1a3ef000..0x1a3efd68]
        at sun.java2d.loops.ScaledBlit.Scale(Native Method)
        at sun.java2d.pipe.DrawImage.scaleSurfaceData(Unknown Source)
        at sun.java2d.pipe.DrawImage.renderImageScale(Unknown Source)
        at sun.java2d.pipe.DrawImage.tryCopyOrScale(Unknown Source)
        at sun.java2d.pipe.DrawImage.transformImage(Unknown Source)
        at sun.java2d.pipe.DrawImage.transformImage(Unknown Source)
        at sun.java2d.pipe.DrawImage.transformImage(Unknown Source)
        at sun.java2d.pipe.ValidatePipe.transformImage(Unknown Source)
        at sun.java2d.SunGraphics2D.drawImage(Unknown Source)
        at sun.java2d.SunGraphics2D.drawRenderedImage(Unknown Source)
        at gr.talent.map.painters.layer.SimpleImagePainter.drawGeographicFeatures(SimpleImagePainter.java:110)
        at gr.talent.map.rendering.Renderer2D.paintGeographicFeatures(Renderer2D.java:832)
        at gr.talent.map.rendering.Renderer2D.renderImpl(Renderer2D.java:750)
        - locked <0x0341fd88> (a gr.talent.map.rendering.Renderer2D)
        at gr.talent.map.rendering.Renderer2D.renderImmediately(Renderer2D.java:347)
        at gr.talent.globe.DataHandler.updateImageData(DataHandler.java:130)
        - locked <0x041a8ad0> (a java.awt.image.BufferedImage)
        at gr.talent.globe.TileRenderingJob.execute(TileRenderingJob.java:49)
        at gr.talent.utils.JobScheduler$JobRunnable.run(JobScheduler.java:456)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

This (if I'm correct) shows that there is an infinite loop at sun.java2d.loops.ScaledBlit.Scale(), and that's why everything freezes. I'm wondering if the following is a java2d problem, or is related to the use of JSR231. At first, I thought that I might go low on gpu memory, and that causes problems on java2d processes. I checked my gpu memory (using the ATI tray tool, I'm using an ATI Mobility Radeon 9000), but it stays well above critical limits. Can Jogl/OpenGL affect the java2d processes? Has anyone come across such a problem?

Most important, how can I isolate this to see if it is a java 2d problem, or it is related to opengl processes?

Thanks in advance
N

10  Java Game APIs & Engines / JOGL Development / Re: glPolygonMode problem on: 2006-09-28 07:08:39
False alarm. I was creating the DegubGL object somewhere in the middle of my gl code, and because of an error before that point (I was calling GLBegin with GL_POINT instead of GL_POINTS), I was getting a INVALID_ENUM error no matter which one was the first gl call after the DebugGL object creation. Next time I'll try to remember that for debugging, DebugGL should be the first thing to be created on a display().

 
11  Java Game APIs & Engines / JOGL Development / glPolygonMode problem on: 2006-09-26 13:18:16
Hi all!

Has anyone encountered any problems when using glPolygonMode  one a DebugGL instance instead of the usual GL instance? I used a DebugGL object to scan for possible errors in my application, but I get a :

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: glGetError() returned the following error codes after a call to glPolygonMode(): GL_INVALID_ENUM
   at javax.media.opengl.DebugGL.checkGLGetError(DebugGL.java:11724)
   at javax.media.opengl.DebugGL.glPolygonMode(DebugGL.java:6360)

when using gl.glPolygonMode(GL.GL_FRONT_AND_BACK, GL.GL_FILL). Any other valid argument combination gives the same results. Since these arguments are valid, why do I get this INVALID_ENUM error;

Thanks in advance
N

12  Java Game APIs & Engines / JOGL Development / Re: OutOfMemory? on: 2006-04-19 13:17:08
There is nothing much there, just a simple call to repaint the GLCanvas I'm using
1  
2  
3  
   public void paint(Graphics g) {
      canvas.repaint();
   }


N
13  Java Game APIs & Engines / JOGL Development / OutOfMemory? on: 2006-04-19 12:39:59
Hi all

I'm profiling my application to check out memory usage, and memory consumption seems to stay well below the max heap size (80% of  the max heap size). However, occasionaly, I get this:

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: java.lang.OutOfMemoryError: Java heap space
        at javax.media.opengl.Threading.invokeOnOpenGLThread(Threading.java:268)
        at javax.media.opengl.GLCanvas.maybeDoSingleThreadedWorkaround(GLCanvas.java:245)
        at javax.media.opengl.GLCanvas.display(GLCanvas.java:130)
        at javax.media.opengl.GLCanvas.paint(GLCanvas.java:142)
        at gr.talent.viewer3d.Viewer3D$4.paint(Viewer3D.java:197)
        at javax.media.opengl.GLCanvas.update(GLCanvas.java:202)
        at sun.awt.RepaintArea.updateComponent(Unknown Source)
        at sun.awt.RepaintArea.paint(Unknown Source)
        at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)

When this happens, the whole application freezes. The strange thing about it is that even if I clear the memory  used (using the profiler), the application still stays frozen.

Has anyone came up to this problem? I use a nightly build of JSR231-beta03, built in early March.

N
14  Java Game APIs & Engines / JOGL Development / Re: PBuffer display() call slow? on: 2006-04-14 19:12:23
To Mithrandir:

I'm using single buffered pbuffers. I think that the setDoubleBuffered() method doesn't work for pbuffers in JOGL-JSR231. I also time many display() calls, not one. The times I have mentioned in previous posts are mean times for the pbuffer display() call.

To Niwak:

You're right, FBO are a better solution. However, my Mobility Radeon 9000 doesn't support  them, even with driver updates. I don't think that all cards that support pbuffers support FBO too. I've confirmed that by running the tests provided with the OpenGL Extensions Viewer utility. Using FBO is the best solution, however, I must make sure that my app runs to as many cards as possible.
15  Java Game APIs & Engines / JOGL Development / Re: PBuffer display() call slow? on: 2006-04-14 18:36:20
Well, I'm using an Acer Travelmate (Intel Centrino 1.6Ghz, 1.25GB mem), with an infamous ATI Mobility Radeon 9000 card. I suspect that, yes, my case must be the single threaded one, but I can't understand why the display() call on the pbuffer uses so much time, since it is done from inside a GLEvent Listener display() call. Also, context for the pbuffer and the GLCanvas is the same, so probably no context switching occurs.

If more system specific info is needed, I'll be happy to provide them.
16  Java Game APIs & Engines / JOGL Development / PBuffer display() call slow? on: 2006-04-14 16:31:42
Hi all

I'm using a pbuffer for performing some offscreen rendering, to use for copying data to a texture. At first I noticed that the whole piece of code was somewhat slow (2-3ms), and I thought that this was normal because of the use of glCopyTexImage2D/glCopyTexSubImage2D. However, what I timed up the glCopyTexImage2D call, I found out that it was fairly fast, about 0.2 ms. In fact, everything inside the display method of the pbuffer was timed to be less than 0.3 ms. But still, the call to pbuffer display took about 1-3 ms each time. In fact, a call to an empty display method for the pbuffer took 0.8-3 ms.

Has anyone came across this? Is this something normal? Should the call to display take up so much time?

TIA
N
17  Java Game APIs & Engines / JOGL Development / Re: TextureData and null Buffer parameter on: 2006-03-03 14:39:36
Yes, my intended use is the exact one described by campbell. I know that when passing null as an argument for glTexImage2D, produces undefined results (as Ken pointed out), but in this case I use only the part of the texture whose data have been set by glTexSubImage2D. That behavior is useful for non-power of two textures, as campbell also suggested.
18  Java Game APIs & Engines / JOGL Development / Re: TextureData and null Buffer parameter on: 2006-03-02 20:35:34
I'm almost certain that null can be passed as an argument to glTexImage2D so as to allocate space to the gpu for an empty texture, whose parts can later be updated by glTexSubImage2D. I have used this trick many times to avoid clearing/initalizing a texture by sending data to the gpu. Look also here:

http://groups.google.gr/group/comp.graphics.api.opengl/browse_thread/thread/821e537274c593d2/3d7d244f18ade423?lnk=st&q=empty+texture+opengl&rnum=2&hl=en#3d7d244f18ade423

I have also measured times (using null data with glTexImage to instantiate a texture, and passing a zero-filled Buffer to TextureData as you suggested). Time in the first case is about 0.01ms, where in the second case is 2ms or more.
19  Java Game APIs & Engines / JOGL Development / Re: TextureData and null Buffer parameter on: 2006-03-02 20:04:56
Hmmm.. I must be missing something here...Let's say that I want to create a 10x10 Texture, and I instantiate it when some data are available for it (e.g. the 5x5 pixel top-left area). Available data can be sent to the gpu with glTexSubImage (using Texture.updateData()), but how is the Texture object instantiated without previously sending the 10x10 pixels? By using the glTexImage2D call, a texture could be allocated in the gpu without actually sending any data, but I can't find a way to do the same using Texture class objects.

Have I misunderstood Texture object use? Embarrassed
20  Java Game APIs & Engines / JOGL Development / TextureData and null Buffer parameter on: 2006-03-02 17:48:18
Hi all!

I'm trying to use the new TextureData/Texture classes, instead of using the glTexImage calls and stuff. However, I stumbled upon a problem. I created a new TextureData object using a null Buffer parameter. Then I created a new Texture :

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
        TextureData textureData = new TextureData(GL.GL_RGB,
                                                  128,
                                                  128,
                                                  0,
                                                  GL.GL_BGRA,
                                                  GL.GL_UNSIGNED_BYTE,
                                                  false,
                                                  false,
                                                  false,
                                                  null, // BufferUtil.newByteBuffer(4*Terrain.IMAGE_TEXTURE_SIZE*Terrain.IMAGE_TEXTURE_SIZE),
                                                  null);
       
        texture = TextureIO.newTexture(textureData);


The equivelant using the old way is :

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
        int[] texs = new int[1];
        gl.glGenTextures(1, texs,0);
        textureID = texs[0];

        gl.glBindTexture(GL.GL_TEXTURE_2D, textureID);
        long l = System.nanoTime();
        gl.glTexImage2D(GL.GL_TEXTURE_2D,
                0,
                GL.GL_RGB,
                128,
                128,
                0,
                GL.GL_BGRA,
                GL.GL_UNSIGNED_BYTE,
                null);


By using the old way, texture space could be allocated directly to the GPU without transferring data to it. Texture data could be provided later by glCopTexImage calls. However, when I tried to do the same using the new code, the VM crashed. It crashes at the Texture creation, and not at the TextureData constructor call.

Is this a bug, or am I doing something wrong here? I think that a Texture should be created using TextureData with null texels (since texture dimensions and format have already been specified). I'm using the lastest nightly build.

TIA
N
21  Java Game APIs & Engines / JOGL Development / "Faster" texture internal format on: 2006-03-01 17:23:26
Hi all,

I'm trying to speed up my application which makes heavy use of texture loading, and I was experimenting with texture internal format. At first, for loading a 256x256 INT_ARGB BufferedImage to a texture using GL_RGBA internal format, GL_BRGA format and GL_UNSIGNED_INT_8_8_8_8_REV type, I got times around 10 ms (in a MobilityRadeon 9000). Since transparency wasn't the issue for me, I used 256x256 INT_RGB buffered images and textures using GL_RGB internal format, GL_BRGA format and GL_UNSIGNED_BYTE type. By using this configuration, texture loading time was reduced to 5ms. (In all cases, the time measured was the time of the single glTexImage2D call).

Since I'm not really an expert concerning the various OpenGL internal formats and data types, is there a better image type/internal format/format/data type configuration for faster texture loading times? What is the configuration you people use most for loading textures?

Also, all the above tests were conducted with the old texture handling way, without using the TextureIO related API intruduced in latest JSR231 versions. Is using this API going to improve texture loading times in any way?

TIA
N
22  Java Game APIs & Engines / JOGL Development / Re: Pbuffers and graphic cards. on: 2006-02-01 13:42:37
Also, I tried to play a little with glPixelZoom(1,-1) to see if pixels will get inverted, and try it on those cards which flipped the texture produced using the pbuffed. The result is that glPixelZoom had an effect only on those cases (mobility Radeon 9000)  where texture appeared normally, and it had absolutely no effect on the ones that flipped the texture. Pretty strange....
23  Java Game APIs & Engines / JOGL Development / Re: Pbuffers and graphic cards. on: 2006-02-01 12:15:48
I came across the same problem using pbuffers in JSR231, but using glCopyTexSubImage2D instead of bind/release texture to produce a texture. My Mobility Radeon 9000 shows everything OK, whereas a Mobility Radeon 9700 and an NVidia GeForce FX5200 shows textures produced using the pbuffer horizontally flipped. Anyone observed similar behaviour? Any workarounds?
24  Java Game APIs & Engines / JOGL Development / Re: Mac using Intel CPU on: 2006-01-31 08:19:07
Thanks for the suggestion. Unfortunately, feedback about this problem came from a mac user, using a version of the app deployed using the 1.08 jogl. I myself don't own a Mac or a i386 Mac, so I can't test it, using the latest version of Jogl.

I'll try to see what I can do with the universal binaries. Thanks again for pointing to the right direction!

25  Java Game APIs & Engines / JOGL Development / Mac using Intel CPU on: 2006-01-30 16:32:06
Hi all,

has anyone tried using JOGL/JSR231 on a Mac using Intel CPU? Tha native libraries for mac don't seem to work. I got the following while trying to run an app using jogl (1.08) on an Intel powered mac:

[JavaAppLauncher] application launched with ppc-thin application stub. Using native application stub instead.
java.lang.UnsatisfiedLinkError: /Volumes/Untitled 2/Cruiser.app/Contents/Resources/Java/libjogl.jnilib:
  at java.lang.ClassLoader$NativeLibrary.load(Native Method)
  at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1586)
  at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1511)
  at java.lang.Runtime.loadLibrary0(Runtime.java:788)
  at java.lang.System.loadLibrary(System.java:834)
  at net.java.games.jogl.impl.NativeLibLoader$1.run(NativeLibLoader.java:60)

Is there going to be a native library version for Intel Macs? (or does it exist already and I just didn't search forum correctly  Undecided ?)
26  Java Game APIs & Engines / JOGL Development / Re: Double buffered pbuffer on: 2006-01-04 08:26:35
Well, my card is an ATI Mobility Radeon 9000, and it seems, considering GKW's post, that it doesn't support double buffered pbuffers. I tried to use the newest available drivers, but no luck. It also doesn't support frame buffers. I want to be able to draw vector graphics on an already existing  texture image, and pbuffers seem to be the only solution, considering the fact that i want to be compatible to as many older graphics cards as possible. I could use multitexturing and continuously draw an image with the vector graphics and send it as a texture to blend with the original texture, but that is too slow (sending all the time unneeded pixels to the GPU). Any suggestions there?

Considering  the two quads problem I mentioned, and thought as a consequence of unsupported double buffered pbufers, I'll look it up as Ken suggests, since double buffering seems not to be the issue. I'll try glFinish to see if it improves things.
27  Java Game APIs & Engines / JOGL Development / Re: Double buffered pbuffer on: 2006-01-03 19:24:24
I'm noticing a behavior that I'm not sure its the right one. I render two quads, the one hiding the other (they are not coincident, so z fighting is not the problem). The quad in front uses a texture produced by the pbuffer. When I move the camera quickly towards/away from the quads, sometimes the quad in behind becomes visible for a split second before the quad in front is  rendered. I suspect that this might be because of the pbuffer produced texture,and a cause might be the single buffered pbuffer.

 
28  Java Game APIs & Engines / JOGL Development / Double buffered pbuffer on: 2006-01-03 18:57:47
Hi all,

has anyone been able to create a double buffered pbuffer? I searched the forum for a similar problem and  at this topic (http://www.java-gaming.org/forums/index.php?topic=5032.0) GTW has reported the same problem, but it remained unclear whether pbuffers can be double buffered when using jogl. I'm using JSR231, and if I try to enable double buffering at the pbuffer  GLcapabilities, my app crashes and I get the following report:

1  
2  
3  
4  
5  
6  
7  
8  
9  
Stack: [0x037d0000,0x03810000),  sp=0x0380f274,  free space=252k
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.sun.opengl.impl.windows.WGLExtImpl.dispatch_wglCreatePbufferARB1(JIIILjava/lang/Object;IJ)J+0
j  com.sun.opengl.impl.windows.WGLExtImpl.wglCreatePbufferARB(JIII[II)J+103
j  com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.createPbuffer(JLcom/sun/opengl/impl/windows/WGLExt;)V+1026
j  com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.<init>(Ljavax/media/opengl/GLCapabilities;IILcom/sun/opengl/impl/windows/WindowsGLDrawable;Lcom/sun/opengl/impl/windows/WGLExt;)V+167
j  com.sun.opengl.impl.windows.WindowsGLDrawableFactory$2.run()V+59
j  com.sun.opengl.impl.windows.WindowsGLDrawableFactory.maybeDoSingleThreadedWorkaround(Ljava/lang/Runnable;)V+20
j  com.sun.opengl.impl.windows.WindowsGLDrawableFactory.createGLPbuffer(Ljavax/media/opengl/GLCapabilities;Ljavax/media/opengl/GLCapabilitiesChooser;IILjavax/media/opengl/GLContext;)Ljavax/media/opengl/GLPbuffer;+47


Thanks in advance
N
29  Java Game APIs & Engines / JOGL Development / Re: JOGL 1.1.1 PBuffer ATI setOffscreenRenderToTexture on: 2005-12-22 23:05:19
I stumbled across the same problem under the same hardware conditions (ATI Mobility Radeon 9000), but using JSR231 instead of JOGL, as Ken suggested. The problem however remains the same. I used today's nightly build.

Exception in thread "AWT-EventQueue-0" javax.media.opengl.GLException: Render-to-texture-rectangle requires render-to-texture to be specified
   at com.sun.opengl.impl.windows.WindowsGLDrawable.glCapabilities2iattributes(WindowsGLDrawable.java:426)
   at com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.createPbuffer(WindowsPbufferGLDrawable.java:158)
   at com.sun.opengl.impl.windows.WindowsPbufferGLDrawable.<init>(WindowsPbufferGLDrawable.java:77)
   at com.sun.opengl.impl.windows.WindowsGLDrawableFactory$2.run(WindowsGLDrawableFactory.java:146)
   at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.maybeDoSingleThreadedWorkaround(WindowsGLDrawableFactory.java:213)
   at com.sun.opengl.impl.windows.WindowsGLDrawableFactory.createGLPbuffer(WindowsGLDrawableFactory.java:163)

 Is there going to be a fix for it?

Ken, do you think that glCopySubTexImage2D can replace efficiently the use of pbuffers for rendering to a texture? Does it cover all cases/needs?
30  Java Game APIs & Engines / Java 2D / Re: drawImage alters source image on: 2005-10-04 10:54:55
The problem was an error when using JOGL to get an image from a texture and draw it on another image. JOGL returned an (uncaught by me) glError, which resulted in a mess when trying to draw the image using java2D.

(One must check thoroughly all possibilities before posting...)
Pages: [1] 2
 

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

The first screenshot will be displayed as a thumbnail.

Longarmx (49 views)
2014-10-17 03:59:02

Norakomi (39 views)
2014-10-16 15:22:06

Norakomi (31 views)
2014-10-16 15:20:20

lcass (35 views)
2014-10-15 16:18:58

TehJavaDev (66 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!