Java-Gaming.org Java4K winners: [ by our judges | by the community ]         
Featured games (67)
games approved by the League of Dukes
Games in Showcase (∞)
games submitted by our members



News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  Print  
  Controlled buffer swapping  (Read 1533 times)
0 Members and 1 Guest are viewing this topic.
Offline Gregg Patton

JGO n00b
*

Posts: 7


jogl rocks!


« on: 2003-08-24 07:03:06 »

Hello,

Ive been using the Jun for Java Opengl binding for my application.

I converted my it to use jogl in less than two hours (very cool).  So far everything seems to work except for one of my picking methods.  It renders to the back buffer and uses glReadPixels to determine the color of the pixel at the cursor.  It then maps back to the 3d object that was rendered in the color.  

To accomplish this I need to have the ability to abort the call that swaps the back buffer to the front buffer at the end of rendering.  I don't want to render the "pick mode" buffer to the screen, just get the pixel color.

I'm considering extending the necessary classes and creating a factory class, to add this functionality.  Is this the way I should do it, or is there a better way?

Thanks,
Gregg
Offline swh

JGO n00b
*

Posts: 3


Modelzilla rocks!  Java's cool too!


« Reply #1 on: 2003-08-25 20:52:53 »

Hi, I also have a beef with with the way the buffer swapping
is done in JOGL.  It does the swap for you, after it calles
GLEventListener.display()!  This has been problematic for
me to - it broke my XOR graphics update system on the
Sun computers (which JOGL doesnt seem to work well on right now anyway) because the hardware there does a pointer swap rather than a buffer copy for glSwap().  So my code wrote onto the front buffer for an XOR updates on the Suns.  Also I would like to be able to defeat a swap entirly if my code can determine there was really no reason to do an update.  Did you subclass your own GLCanvas?
Offline Gregg Patton

JGO n00b
*

Posts: 7


jogl rocks!


« Reply #2 on: 2003-08-26 09:24:28 »

I ended up creating 5 classes.   GLCanvas can't be subclassed because it's declared final.

The classes are CameraGLCanvas, CameraGLContextFactory, CameraGLContextHelper, CameraOnscreenGLContext, and CameraWindowsGLContextFactory.  All these classes correspond to the existing jogl classes for Windows.  

I haven't looked at the other implementations, but I think it might be a fairly simple matter to add a boolean to the existing classes to check before swapping buffers.  If it's true do the swap, false don't swap.  Maybe we can get it added in the future.

I can send you the code if you want it.  The changes are minor.  I don't see a way to attach files here but I don't mind emailing it to you.

Gregg
Games published by our own members! Go get 'em!
Offline gregorypierce

JGO Strike Force
***

Posts: 905


I come upon thee like the blue screen of death....


« Reply #3 on: 2003-08-26 10:54:03 »

I have to chime in here and agree. It causes me significant problems with some client code I've been working on where I need to have more fine grained control over when the buffer swaps and the solution in JOGL isn't quite ideal. As I started digging through the JOGL source I discovered that it doesn't HAVE to be this way, but is more a convenience thing the way it is implemented.

Not sure the current design is the best for applications that need more swaps than one per frame.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline swh

JGO n00b
*

Posts: 3


Modelzilla rocks!  Java's cool too!


« Reply #4 on: 2003-08-26 17:17:01 »

Hi Gregg, I'd love to see your improved code.  I'm at
shenness@scripps.edu

Sean
Offline Gregg Patton

JGO n00b
*

Posts: 7


jogl rocks!


« Reply #5 on: 2003-08-27 07:17:50 »

Hi Sean,

Here's a rundown of what I changed.

CamerGLCanvas - I had to change GLCanvas because it used a factory class to create its context.  Since it's final I can't override anything.  It uses CameraGLContextFactory and CameraGLContextHelper.

CameraGLContextFactory - I changed this one so it would return CameraWindowsGLContextFactory as the factory class.

CameraGLContextHelper - This one is because GLContextHelper has package scope.

CameraOnscreenGLContext - This is the one that actually controls the SwapBuffer call.  It extends WindowsOnscreenGLContext.  I used the NoAutoRedrawMode boolean as the logic switch.  This probably is an inappropriate use of this boolean but it works for now.

CameraWindowsGLContextFactory - This returns an instance of CameraOnscreenGLContext.

As a temporary solution, I directly instantiate CameraGLCanvas instead of using a factory.  i.e. glCanvas = new CameraGLCanvas(glCapabilities, null, null);

I think that's it.
Gregg

PS:  I emailed the code to you.
Offline Ken Russell

JGO Kernel
*****

Posts: 3446
Medals: 3


Java games rock!


« Reply #6 on: 2003-09-07 00:07:52 »

Please file an RFE describing what you were trying to do (with the code if at all possible) and why the current JOGL APIs weren't sufficient. Thanks.
Pages: [1]
  Print  
 
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines Valid XHTML 1.0! Valid CSS!
Page created in 0.108 seconds with 23 queries.