Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  pbuffers  (Read 3756 times)
0 Members and 1 Guest are viewing this topic.
Offline darkvox

Senior Newbie




Java games rock!


« Posted 2004-09-05 07:28:52 »

is there any documentation of how to create a pbuffer with jogl?
i cant get it working... i have some exceptions in the kind glActiveTexture not supported or Not implemented yet. sounds like the creation of the pbuffer is not done the right way, but i have no clue of what is the way... there is too much things in the nvidia sample to understand how to do a new pbuffer. any sample with only pbuffer?
Offline darkvox

Senior Newbie




Java games rock!


« Reply #1 - Posted 2004-09-05 08:19:17 »

oh and the init in th pbufferlistener class is never called.
      GLCapabilities caps = new GLCapabilities();
       caps.setDoubleBuffered(false);
       pbuffer = dr.createOffscreenDrawable(caps, 1024, 1024);
       pbuffer.addGLEventListener(new GLpBuffer());

shouldnt it happen there?
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #2 - Posted 2004-09-07 19:55:26 »

You probably need to call display() on the parent heavyweight drawable until the GLPbuffer's isInitialized() method returns true.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #3 - Posted 2004-09-08 08:29:53 »

isInitialized() always returns false to me, regardless of how often I call display on the glcanvas. =/

(this is mentioned in my "pbuffers cause crash to desktop on ati" bug report)

Play Minecraft!
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #4 - Posted 2004-09-09 21:48:40 »

Is the parent GLCanvas visible? That is, is it in a window that has been shown? It needs to be. If you need to have a completely invisible parent GLCanvas, put it in an undecorated Frame that is sized to (0, 0). Or have you done this already? Is your code working on other vendors' cards?
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #5 - Posted 2004-09-09 22:31:11 »

Source code here: http://www.wurmonline.com/newclient/PBufferTest.java

The line is commented out about 33% down.

Always false. GeForce TI4800, latest jogl build.
I haven't tested on other cards.

Play Minecraft!
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #6 - Posted 2004-09-10 03:11:03 »

I get a CTD here on my Radeon 9700 PRO.  

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
Current Java thread:
        at net.java.games.jogl.impl.windows.WGL.wglCreateContext(Native Method)
        at net.java.games.jogl.impl.windows.WindowsPbufferGLContext.create(Windo
wsPbufferGLContext.java:388)
        at net.java.games.jogl.impl.windows.WindowsGLContext.makeCurrent(Windows
GLContext.java:133)
        - locked <0x1052a168> (a net.java.games.jogl.impl.windows.WindowsPbuffer
GLContext)
        at net.java.games.jogl.impl.windows.WindowsPbufferGLContext.makeCurrent(
WindowsPbufferGLContext.java:314)
        - locked <0x1052a168> (a net.java.games.jogl.impl.windows.WindowsPbuffer
GLContext)


I'll have a quick look at the code to see what you're doing wrong.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #7 - Posted 2004-09-10 03:26:41 »

Heh, that was quick.

Right, number of things that I've noticed:

1) You set frame visible after you've done everything else. In order for JOGL to remain sane, you must make the frame visible first, and then create the main canvas, add the main canvas to the frame then add the listener.

2) You're creating the pBuffer before the canvas has even had a chance to initialise. You need to wait for that init() callback on the canvas before creating the pBuffer.  JOGL has issues with trying to create stuff before that initial canvas init() call is finished.

3) You are only creating and calling a swing component in the middle of a GL drawing callback. Very, very bad thing to do. Inside the drawing loop for GL, you should do nothing else except issue gl commands. Making calls to external rendering threads is just asking for a crash.

4) I'm not entirely sure your little render thread is valid way of telling GL to actually draw.

5) You've told the pbuffer to not use double buffering.  This causes JOGL to have a fit. pBuffers are, by definition, not double buffered, and setting an explicit set of capabilities to turn it off always seems to get JOGL confused. I don't know why it does, as it should just completely ignore that part, however it does and I've been bitten by it a few times.


Now, if you modify the code to move frame.setVisible() to immediately after frame.setSize() everything works and now JOGL bitches about not being able to find the required capabilities, which is due to point 4.  Fixing up the timing issue of the canvas/pbuffer creation was going to take up a lot more time than I have to spend on it, so you'll need to look into that yourself.  However, you should submit the file as is as a bug to the issue tracker as it caused an immediate CTD on the ATI cards, which it really should not have.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #8 - Posted 2004-09-10 07:44:25 »

Quote
1) You set frame visible after you've done everything else. In order for JOGL to remain sane, you must make the frame visible first, and then create the main canvas, add the main canvas to the frame then add the listener.  

2) You're creating the pBuffer before the canvas has even had a chance to initialise. You need to wait for that init() callback on the canvas before creating the pBuffer.  JOGL has issues with trying to create stuff before that initial canvas init() call is finished.

Rightie-o, that would explain a lot. Thanks.

Quote
3) You are only creating and calling a swing component in the middle of a GL drawing callback. Very, very bad thing to do. Inside the drawing loop for GL, you should do nothing else except issue gl commands. Making calls to external rendering threads is just asking for a crash.

The only swing call I can see is the debug JOptionPane.showMessageDialog that pops up when (one of) the error(s) occur(s). Surely that can't trigger the crash that causes itself to appear.

Quote
4) I'm not entirely sure your little render thread is valid way of telling GL to actually draw.

Mind telling me what's wrong with it?

Quote
5) You've told the pbuffer to not use double buffering.  This causes JOGL to have a fit. pBuffers are, by definition, not double buffered, and setting an explicit set of capabilities to turn it off always seems to get JOGL confused. I don't know why it does, as it should just completely ignore that part, however it does and I've been bitten by it a few times.

I did not know that. =D

Play Minecraft!
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #9 - Posted 2004-09-10 13:23:39 »

Quote
The only swing call I can see is the debug JOptionPane.showMessageDialog that pops up when (one of) the error(s) occur(s). Surely that can't trigger the crash that causes itself to appear.


Yup, that's the one. At the very least you're going to end up with a deadlock in the middle of your code or some oddball apparently non-sensical, exception from the internals of JOGL.  Java3D and JMF also suffer from exactly the same problem. UI code and rendering interaction code have to remain completely separate. Swing does it's own stuff under the covers that seems to have problems playing nice with anyone else that uses heavyweight canvases and their own separate updating threads.

Quote

Mind telling me what's wrong with it?


while(true) loops without a surrounding thread are always dodgy coding practice. JOGL does not have to directly just display when you call it. It's a hint to tell JOGL to repaint.  That little section is very likely going to cause an extremely fast infinite loop that consumes 100% CPU. If you want to directly control the render framerate then using the Animator class or your own separate render thread is the way to go.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #10 - Posted 2004-09-11 11:48:28 »

Quote
Yup, that's the one. At the very least you're going to end up with a deadlock in the middle of your code or some oddball apparently non-sensical, exception from the internals of JOGL.  Java3D and JMF also suffer from exactly the same problem. UI code and rendering interaction code have to remain completely separate. Swing does it's own stuff under the covers that seems to have problems playing nice with anyone else that uses heavyweight canvases and their own separate updating threads.

As I said, that window only pops up when a pbuffer error occurs. That popup cannot cause itself to pop up.


Quote
while(true) loops without a surrounding thread are always dodgy coding practice. JOGL does not have to directly just display when you call it. It's a hint to tell JOGL to repaint.  That little section is very likely going to cause an extremely fast infinite loop that consumes 100% CPU. If you want to directly control the render framerate then using the Animator class or your own separate render thread is the way to go.


Wrong. Wink

From the Animator source code:

1  
2  
3  
4  
5  
              while (!shouldStop) {
                noException = false;
                drawable.display();
                noException = true;
              }



From the GLDrawable javadoc:

1  
2  
public void display()
Causes OpenGL rendering to be performed for this GLDrawable by calling GLEventListener.display(net.java.games.jogl.GLDrawable) for all registered GLEventListeners.

Play Minecraft!
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #11 - Posted 2004-09-11 13:54:01 »

It's not wrong. Have a look at what is around the animator class. There's a full Thread, as well as a call to setRenderingThread() and setNoAutoRedrawMode().  That is what allows you to be able to make that other call in an infinite loop.  First, understand the code you are quoting before trying to make a point  Shocked

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Markus_Persson

JGO Wizard


Medals: 15
Projects: 19


Mojang Specifications


« Reply #12 - Posted 2004-09-12 11:46:53 »

Quote
It's not wrong.

Yes, it is.

Quote
Have a look at what is around the animator class. There's a full Thread,

The thread that calls the main method is also a full Thread. Why would it be better to spawn a new thread and let the first thread die, other than purely for style points? (remember that this is a test case)

Quote
as well as a call to setRenderingThread()

From the javadoc for said method:
"Setting up the rendering thread is not required but enables the system to perform additional optimizations, in particular when the application requires control over the rendering loop."

And a bit further down:
"NOTE: Currently this routine is only advisory, which means that on some platforms the underlying optimizations are disabled and setting the rendering thread has no effect. Applications should not rely on setRenderingThread to prevent rendering from other threads."

Quote
and setNoAutoRedrawMode().

From the javadoc for said method:
"Its sole purpose is to avoid deadlocks that are unfortunately all too easy to run into when both animating a drawable from a given thread as well as having updates performed by the AWT event thread (repaints, etc.)."

Quote
That is what allows you to be able to make that other call in an infinite loop.

Wrong, setRenderingThread() is an optimisation, and setNoAutoRedrawMode() is a hack to prevent deadlocks.
These two methods are very useful, but they only work well when you're calling display() frequently, eg by using a while(true) loop. (note that they're in no way a requirement for doing so)

Quote
First, understand the code you are quoting before trying to make a point  Shocked

And I would advice you to read up on the javadocs. There really is a lot of useful information in there.

Play Minecraft!
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #13 - Posted 2004-09-12 14:21:01 »

Quote

From the javadoc for said method:
"Setting up the rendering thread is not required but enables the system to perform additional optimizations, in particular when the application requires control over the rendering loop."

And a bit further down:
"NOTE: Currently this routine is only advisory, which means that on some platforms the underlying optimizations are disabled and setting the rendering thread has no effect. Applications should not rely on setRenderingThread to prevent rendering from other threads."


Actually, I think that the javadoc is wrong in this case. It seems that setRenderingThread method is not only an optimization hint. At least, I've had problems rendering from the current thread, if I haven't called the method to explicitly set the rendering thread. I've experienced these problems on ATI cards (haven't got an NVidia card). This problem can be seen in the following demo:

http://www.g0dmode.com/javastuff/jogl-simpledemo.zip

...on line 28 there's a call to setRenderingThread. Without the call the demo will not work (tested on ATI 9600). Have I missed something or is the call really necessary?


Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #14 - Posted 2004-09-12 16:04:56 »

Markus,  not sure where to start, but it's fairly clear that you don't understand what either pieces of code are doing.  You read the individual method documentation, but you are ignoring the global picture they are painting.  Not only have I read the documentation many times, but I've also implemented a heap of applications using it.

JOGL operates in one of two modes when rendering. Both of them require calling the display() method in order to get a repaint action happening (GLEventListener.display() callback).

In the first case, which is that presented by the original poster's code, is an advisory request. There are many possible threads that can call display(). The canvas is not required to immediately initiate a repaint. In this mode, calling display() is a non-blocking method. It puts a request on the queue and returns immediately.  Internally JOGL will (potentially) then combine a collection of repaint requests from both user land and AWT's requirements and turn them into a single call to the listener's display callback.  If it is in the middle of a repaint for an earlier request, another will be queued up and immediately called once the current repaint is finished. This is what the original poster's code does. It goes into an infinite loop that doesn't have any blocking in it. Apart from the Thread.yield() call,  there is no other way of stopping that loop from executing as fast as possible. There is no other thread or Runnable in the code. Since there is no other thread, it is quite possible to completely starve JOGL from getting any CPU cycles to do redrawing (Which is what is exactly happening on my machine if I remove the pBuffer code and just use the main canvas).  Nothing appears on screen because the original code is not doing anything to give any other piece of the application cycles to do the drawing with. That's why it is dodgy.

In the second case, which is what the Animator class implements, is a strictly controlled repaint cycle that is locked to a single thread.  In this mode, calling display() is a blocking call. display() does not return until the listener's callback method has finished. Any other thread that wants to repaint the canvas is told to go away, particularly AWT's own repainting (the setNoAutoRedraw() part). Now, because there is a blocking part of the code, cycles are available to repaint with.  A separate thread makes sure that this can happen only at the times required etc.

Now, onto your specific points:

Quote

The thread that calls the main method is also a full Thread. Why would it be better to spawn a new thread and let the first thread die, other than purely for style points? (remember that this is a test case)


Because there is no way of getting CPU cycles to the JOGL to do the repainting with.  At an absolute minimum, there should be a Thread.sleep() in there for a few milliseconds to that other threads may take up the CPU (Thread.yield() is almost never good enough).

Quote

Wrong, setRenderingThread() is an optimisation,


An optimisation that, unless used, results in an application that can't even draw it's own piece of the window.  It's only an optimisation when it actually does something faster (or less memory) than before. In this case, unless it is used, the application is non-functional. That's not an optimisation in my book.

If it was such an optimisation, why does every single demostration you see of JOGL use the Animator class or a custom-coded equivalent? Surely it is not because that these method usages are required in order to have a functional demo? That's not an optimisation at all from any direction that you look at it from.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline darkvox

Senior Newbie




Java games rock!


« Reply #15 - Posted 2004-09-19 09:32:10 »

for the markus code example for pbuffer.

Exception in thread "main" net.java.games.jogl.GLException: Method "wglChoosePix
elFormatARB" not available...

ok... Why is it trying to call the ARB function? and even the samples in jogl-demo using pbuffer works on this graphic card. something weird here.
Offline weston

Junior Member





« Reply #16 - Posted 2004-09-22 03:39:37 »

I tried changing the order of my setup to go along with what Mithrandir said, set Frame to visible, create glcanvas, add canvas to frame, add gleventlistener to canvas. Before my order was like this: create glcanvas, add listener to canvas, add canvas to frame, make frame visible. It worked before but now my init(GLDrawable) method never gets called... what could I be doing wrong?

for(int i = 1; i > 0; i++)
{
System.out.println(i+" cups of java downed");
}
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #17 - Posted 2004-09-22 03:59:31 »

Well.. If you add the listener to the canvas as the last thing, it will not be notified about the initialization of the canvas. Try adding the listener before adding the canvas to the frame.

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline weston

Junior Member





« Reply #18 - Posted 2004-09-22 05:39:26 »

hmm, that would make sense, but its still not working:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
frame = new JFrame();

frame.setBackground(Color.BLACK);
frame.setIgnoreRepaint(true);
frame.setBounds(screenWidth/2-displayWidth/2, screenHeight/2-displayHeight/2, displayWidth, displayHeight);

frame.setVisible(true); //1: set frame visible
     
      GLCapabilities caps = new GLCapabilities();
      caps.setHardwareAccelerated(true);
      caps.setDoubleBuffered(true);
      canvas = GLDrawableFactory.getFactory().createGLCanvas(caps); //2: create canvas
     canvas.setSize(size);
      canvas.setBackground(Color.BLACK);
      canvas.setIgnoreRepaint(true);

      canvas.addGLEventListener(mainClass); //3: add listener

      frame.getContentPane().add(canvas); //4: add to frame
     frame.pack();


there something I'm missing still?

for(int i = 1; i > 0; i++)
{
System.out.println(i+" cups of java downed");
}
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #19 - Posted 2004-09-23 13:58:19 »

You won't get an init() until you start calling display() on the GLDrawable. Stick an Animator in there and you'll see it come up.  The order I gave you is the only one that seems to work with any reliability. You really do need to add the canvas to the frame first before doing anything else, including adding listeners otherwise at least half the time you won't get the callbacks.  You're not going to get init() calls until you actually try to display something, so make sure you have that in your code next.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #20 - Posted 2004-09-23 14:07:15 »

Quote
You won't get an init() until you start calling display() on the GLDrawable.


Umm... What's the difference between init method and the first call to display method then? I think someone should rethink some parts of the event architecture Smiley.

Edit: Also, I've seen far too many cases where someone adds the component x into y in the wrong order. These cases should be either documented or corrected to work in a more intuitive way.

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #21 - Posted 2004-09-23 14:11:49 »

There's a huge difference. You need to go read the OpenGL docs. Also understanding what GLUT does would be helpful too, because JOGL is modelled after the GLUT callback architecture.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #22 - Posted 2004-09-23 14:15:41 »

Quote
There's a huge difference. You need to go read the OpenGL docs. Also understanding what GLUT does would be helpful too, because JOGL is modelled after the GLUT callback architecture.


Really? I'm silly in that way... I understand OpenGL but I still have problems understanding JOGL sometimes. Also, where is it documented that JOGL works on top of GLUT? GLUT is not a requirement for a casual OpenGL program.

A Java library should work nevertheless.

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #23 - Posted 2004-09-23 14:47:37 »

It's not implemented on top of GLUT, it just uses the same design concepts.  The one difference is that GLUT does it's own event/callback loop, where JOGL needs to be externally clocked somehow - hence the presence of the display() method on GLDrawable.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline nnevatie

Junior Member




It is slightly better to be simple than correct.


« Reply #24 - Posted 2004-09-23 14:52:03 »

Yeah, sorry I misread the message. I can understand the requirement for the display method and the motivation behind it, but why is the init method defined to be "triggered" after the first display? Is this behavior due to a lazy initialization of the used OGL context? If so, could it be modified to occur already in the show (or setVisible) method of the component (glDrawable owner)?

Awards:
- Nobel Prize in Physics for inventing his Doomsday Machine
- Nobel Peace Prize for not using it

http://www.g0dmode.com -- a collection of things not real
Offline weston

Junior Member





« Reply #25 - Posted 2004-09-23 18:36:06 »

Right now I am initializing my textures, creating my display lists, and doing some other basic 'initialization' in my init method, basically my display method isn't going to work before initialization is done. Is it just me or does it seem wrong that I have to try and display what I'm initializing before I initialize it? do I really need to add something like

1  
2  
3  
4  
5  
6  
7  
8  
9  
if(!intialized)
{
  //do initialization.
 initialized = true;
}
else
{
 //display code.
}


instead of using the init method? If this is true, what exactly is the init method for? I'm sure there is a reason for this, but I've never heard mention of it in any of the tutorials I've read...

for(int i = 1; i > 0; i++)
{
System.out.println(i+" cups of java downed");
}
Offline weston

Junior Member





« Reply #26 - Posted 2004-09-23 19:22:26 »

I just checked out the jogle ported nehe tutorials and sure enough they are doing the same thing:

create canvas
add listener
add canvas to frame
set frame to visible

plus they are loading their textures and building their display lists from init.

It should be noted that I did not learn jogl from these tutorials so the mistake must be pretty widespread. Perhaps some effort should be made to let people know about the correct way to setup jogl if it is such a problem.

for(int i = 1; i > 0; i++)
{
System.out.println(i+" cups of java downed");
}
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #27 - Posted 2004-09-24 02:07:09 »

The problem with JOGL is that it "mostly works" where "mostly" is defined for nVidia video cards. ATI cards are very problematic. Some work, some don't. For example, JOGL running on my old laptop with a Mobility M3 runs the NeHe stuff fine. However, on my Radeon 9700 here in the office, it fails to start.  Same thing with a couple of the 3DLabs cards we have here too. Some work, some don't. It's not entirely predictable either. The order above is the only one that we can get to reliably work on all video hardware.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline turquoise3232

Junior Member




Java (games) rock!


« Reply #28 - Posted 2004-09-24 04:01:29 »

Hi,

A simple question : Is this problem of same code working or not on different video cards a driver problem or a JOGL problem... (It is known that ATI are not the leader in openGl but...)

Well, in both cases, i raises a crucial issue, for me, that will prevent JOGL from spreading.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #29 - Posted 2004-09-24 04:48:57 »

Since the display loop handling and all the listeners are implemented in Java, it's a pure JOGL problem. Basically some interesting interactions are happening between the internals of the AWT code and OpenGL that are causing these problems. You could somewhat blame it on the drivers (there's a host of other ATI-specific problems that JOGL has to deal with), but really it feels more of a JOGL implementation problem than drivers.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

Dwinin (19 views)
2014-09-12 09:08:26

Norakomi (54 views)
2014-09-10 13:57:51

TehJavaDev (63 views)
2014-09-10 06:39:09

Tekkerue (31 views)
2014-09-09 02:24:56

mitcheeb (53 views)
2014-09-08 06:06:29

BurntPizza (37 views)
2014-09-07 01:13:42

Longarmx (23 views)
2014-09-07 01:12:14

Longarmx (27 views)
2014-09-07 01:11:22

Longarmx (26 views)
2014-09-07 01:10:19

mitcheeb (34 views)
2014-09-04 23:08:59
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!