2D games and glCopyTexSubImage2D()

Sage
Posts: 1,482
Joined: 2002.09
Post: #1
I've been playing around with some nifty 2D effects lately making heavy use of glCopyTexSubImage2D() to use textures as buffers. On my G5, this runs great to no surprise. Swapping buffers is still by far the most expensive operation with a large window. (the texture size is constant)

However, how will this run on older cards/machines? As this also uses rectangle textures, a radeon will be the lowest targeted card. Also, how will the size of the texture affect speed? About as much as a resolution change or more?
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #2
You can render-to-texture via pbuffers or offscreen windows to avoid the copies. Of course, then you pay context switches.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #3
So what exactly are pbuffers? I was under the impression that they were used to render an image into system memory instead of a window. Also, this has to be cross-platform. I'm working on this with some of my linux using friends. (and if one of them has his way, windows too)
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
pbuffers are for accelerated render-to-texture, not render-to-memory. They're not cross-platform, but the different APIs are similar. SDL might have a cross-platform API on top?

EXT_framebuffer_object will provide cross-platform pbuffers, but it's not yet implemented in any drivers on any platforms AFAIK.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #5
That's right. It is a method to render to a chunk of memory, and then treat that same chunk as a texture, without copying.

Let's see if I can briefly describe the various ways to do render-to-texture, with the advantages (+) and disadvantages (-) of each:

* glCopyTexSubImage2D
+ easy to implement: just render normally, copy to texture, use the texture.
- destroys previous framebuffer content.
- requires copy.

* offscreen window
+ eliminates copy.
- requires an additional context.
- requires 10.2 (or gross hack in 10.1.)
- on certain (nvidia) hardware, only works with rectangle texture target.

* pbuffer
+ eliminates copy.
+ works with any texture target.
- requires additional context in fullscreen (may use single context in window.)
- requires 10.3.
- does not (currently) work with multisampling.
- buggy on certain (ati) hardware.

* framebuffer objects
+ eliminates copy.
+ eliminates need for additional context.
+ works with any texture target.
+ allows attaching to various parts of a framebuffer (front/back/depth/stencil...)
+ beats up pbuffers and takes their lunch money.
- only exists on paper for now.


Cross-platform-wise, only glCopyTexSubImage2D (and framebuffer objects, in some distant galaxy...) is completely portable, because the other methods require interaction with the window server. So that means OS-specific code to create the window/context. But pbuffers are the common way to do render-to-texture on Windows/linux, so it shouldn't be too hard to port.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #6
After testing it on our G4 at home, the animation still seems very smooth, so it might not even be a problem at all as long as we don't use too many render passes.

Having more than one context means you need some code to share textures between them right? Currently I'm prototyping this largely using OSC's RubyGameCommon, which uses glut, but eventually I'm going to rewrite most of my graphics classes into C, and break the dependence on GLUT. So this isn't going to be a problem yet.

Does managing contexts work differently depending on the OS/API?
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #7
Context sharing in CGL/AGL/NSGL is set up at context creation time. It is OS and API specific, and I don't think it is possible via GLUT.

However, you don't necessarily have to share contexts. It depends what you're doing.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #8
I was afraid of that. In that case, I'll probably hold off on all this for a while, and just continue using glCopyTexSubImage2D() until it proves to be a problem.

Thank you all, this was very informative as always.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  glCopyTexSubImage2D vs antialiasing on iPhone? Mark Levin 4 4,628 Jul 16, 2010 01:46 AM
Last Post: Bersaelor
  Trouble with glCopyTexSubImage2D when using multisampled rendering TomorrowPlusX 11 5,061 Nov 1, 2006 02:54 PM
Last Post: OneSadCookie
  Quick question, will glCopyTexSubImage2D with with RECT textures? TomorrowPlusX 28 8,836 Jun 8, 2006 07:04 PM
Last Post: akb825
  glCopyTexSubImage2D pkraft 3 3,796 Mar 8, 2005 01:59 PM
Last Post: pkraft