Hello Guest

"Fast" Pbuffers implemented

  • 23 Replies
  • 15720 Views
*

Offline spasi

  • *****
  • 2169
    • WebHotelier
"Fast" Pbuffers implemented
« Reply #15 on: July 26, 2004, 15:48:25 »
OK, pbuffers with unique context, without rtt, work great now. But it still hangs with rtt and now I get a "Could not make pbuffer context current" with context sharing (with & without rtt).

I'm starting the pbuffer test now...

*

Offline spasi

  • *****
  • 2169
    • WebHotelier
"Fast" Pbuffers implemented
« Reply #16 on: July 26, 2004, 19:04:06 »
The tests are ready. They are in org.lwjgl.test.opengl.pbuffers. Usage: PbufferTest <mode>, where mode can be one of 1-4, to try the different techniques.

From the four tests only the second doesn't run, it hangs just like in Marathon. The others are fine.

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
"Fast" Pbuffers implemented
« Reply #17 on: July 26, 2004, 19:24:10 »
That was an easy one, the test number 2 works now, except that the inner colored square is never shown like in the rest of the tests. Could you verify that this is intended?

 - elias

*

Offline spasi

  • *****
  • 2169
    • WebHotelier
"Fast" Pbuffers implemented
« Reply #18 on: July 26, 2004, 19:54:34 »
No, it's not. Post a new build and I'll check it out. I couldn't test that one at all.

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
"Fast" Pbuffers implemented
« Reply #19 on: July 26, 2004, 20:09:32 »
Here you go:

http://odense.kollegienet.dk/~naur/lwjgl-20040726-2.zip

 I had to disable the single buffering stuff for the shared context path, because I discovered that the pixel format has to match exactly, not just the buffer depths like in GLX.

 - elias

*

Offline spasi

  • *****
  • 2169
    • WebHotelier
"Fast" Pbuffers implemented
« Reply #20 on: July 26, 2004, 22:16:47 »
OK, fixed it. I was using the back buffer instead of the front.

So, to sum up, when sharing the display context the pbuffer is forced to have the exact same pixel format and be double-buffered, right? And when having a new context, you can choose whatever pixel format you want and it will be single buffered (GL_FRONT_LEFT only). Am I correct?

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
"Fast" Pbuffers implemented
« Reply #21 on: July 27, 2004, 14:15:11 »
Mostly correct. I updated the docs, and as they state, single buffered pbuffers are always preferred, but if that fails, you can get a double-buffered one. In practice, it means that in Linux where the GLX spec is less restrictive, you can get a single buffered pbuffer with a shared context (but still same buffer depths as the display), but in win32 you will always get a double-buffered one. For unique context pbuffers, you will most likely get a single-buffered pbuffer, but if that is not possible, a double-buffered format pbuffer could be created.

 - elias

*

Offline spasi

  • *****
  • 2169
    • WebHotelier
"Fast" Pbuffers implemented
« Reply #22 on: July 27, 2004, 15:15:47 »
Nice. What about the different function addresses? I guess that will never happen in a standard game, but will we do something about it? Just to cover an unusual usage of the library. Probably not, right?

*

Offline elias

  • *****
  • 899
    • http://oddlabs.com
"Fast" Pbuffers implemented
« Reply #23 on: July 27, 2004, 15:51:36 »
Already converted to the Assumption: "Contexts will never have different function pointer sets". So the pointers will only load if they're not loaded already.

 - elias