All pastes #344260 Raw Edit

Someone

public text v1 · immutable
·published 2007-02-07 17:21 UTC
rendered paste body
<Madsy> If you don't like pixelbuffers, framebuffer objects might be a better suggestion.
<tamlin> Eulex: WGL, meaning Windows GL (also known as wiggle extensions) are Windows-only.
<Eulex> tamlin, I know
<tamlin> If you target FBO-capable hardware, I'd say; by all means, prefer FBO!
<Eulex> hmm, didn't know about that one. might be just what we need.
<tamlin> If you target FBO-capable hardware, but the driver developers didn't bother, *then* you have a case for older extensions such as e.g. PBO.
<Eulex> unfortunately, at least my driver/card doesn't seem to support it.
<tamlin> Eulex: Card + OS?
<Eulex> ati x300 + linux + free ati driver
<oc2k1> PBOs aren't PixelBuffer
<tamlin> X300 is later than 9800, isn't it?
<Eulex> tamlin, it's basically a pimped 9550
<Madsy> oc2k1: Errr.. ?
<Eulex> with some features added, like pixel shaders 2.0
<Madsy> Pixel buffer objects are not pixel bufers?
<Madsy> +f
<oc2k1> yes
<Madsy> That was too deep for me ;-)
<tamlin> Eulex: OK. Anyway, it most certainly is capable of *basic* FBO (so is even an old TNT2!). It's just that noone has bothered to implement it (and ATI... forget about them ever doing it).
<Eulex> tamlin, I'm not using ati
<Eulex> 's driver, this is the open source one
<Madsy> Why are everyone still saying ATI? ;)
<Madsy> It's AMD now.
<oc2k1> Pixelbuffer are old. PixelbufferObjects are new and can be used for asyncronus texture up/download or render 2 vertexbuffer
<Eulex> this card was made when ati was ati
<tamlin> Eulex: "I'm not using ati" vs "ati x300" makes no sense to me.
<tamlin> Eulex: Forget that last comment.
<Eulex> tamlin, I pressed enter by mistake when reaching for '
<tamlin> oc2k1: PBO is old in context of FBO. Still, they are both "new" in the larger scale.
<Eulex> in any case, I found out that there's GLX_SGIX_pbuffer. I don't really want to mess with different code for different platforms, but this might be necessary. basically, I want to copy some rendered stuff into a texture.
<oc2k1> GLX_SGIX_pbuffer != PBO
<Eulex> well. tell the opengl noob, what is a pbo and what extension provides it? :)
<tamlin> Eulex: You _could_ just copy a part of the framebuffer to a texture. Sure, redundant and perhaps slow, but still it'll work on everything.
<oc2k1> http://www.opengl.org/registry/specs/EXT/pixel_buffer_object.txt
<Eulex> tamlin, I've tried both with glReadPixels and glCopyTexSubImage, both do not work/produce garbage when a window is covering the window I render in
<tamlin> Eulex: What are you trying to do? It sounds a little like a flightsim wanting to render FLIR or DTV on an MFD.
<Eulex> tamlin, well, yes, kinda. a map view for an rts.
<tamlin> Eulex: Oh... When windows cover you're in undefined land.
<Eulex> tamlin, hehe, yeah, noticed :)
<Eulex> oc2k1, oh, that one looks nice. unfortunately, it seems that my driver doesn't support that one either.
<tamlin> Eulex: What if you only render the map view IFF you have an area of the main window "clear" the same size as the map window, and then you render into just that region (of the back-buffer), and copy it to the map view?
<Eulex> tamlin, how do I know what parts of the window are not covered?
<tamlin> glClear(0,0,0) followed by drawing a quad (1,1,1)? (sick, but without RTT I don't know about anything better)
<Eulex> hmm
<tamlin> I do NOT recomment it though! But it _cuold_ work.
<Eulex> yes, it'd be very hacky
<tamlin> Very...
<Eulex> in any case, seems I'll have to go on with plan b, creating the texture myself
<tamlin> But without any other render target, and you are running in windowed mode, I honestly don't see any other option.
<Eulex> yeah
<tamlin> If it's just a small map texture for an RTS-ish game, I think doing the (small) map on the CPU is definitely an option.