Re: OpenGL question

[Steve Baker <sjbaker1@airmail.net>]

Gregor Mückl wrote:

> Windowing systems could still emulate frame buffers for each window (I'm 
> not sure but I think something like this is done in BeOS for 
> BDirectWindow's or whatever they are called). But it's a different case 
> when hardware 3D functions are used.
You *could* - but then all the percieved benefits of direct access to 
the frame buffer would disappear.

You might as well write to a buffer in main memory and send it to the
card using glDrawPixels - or download it into a texture and draw it on
a polygon.

> I wonder how paritally covered 3D views are handled by the hardware. Is 
> there some buffer which hold the appropriate pixel coordinates? Or would 
> something like a dedicated stencil buffer bit  make more sense here?
Different cards do it in different ways.  The good part about accessing
hardware through an API like OpenGL is that it leaves hardware designers
free to innovate 'behind the scenes'.

> > No...nor should there be.  Raw screen access died a couple of
> > generations of hardware ago - and I didn't shed a tear to see it
> > go!
> I kind of miss that kind of do-it-yourself graphics programming that was 
> standard in the "good old" days of DOS (well, at least there was no 
> Windows to get in your way ;). I really miss the tweaks and 
> optimizations that were made to get reasonable frame rate even for 2D 
> games.
But you still get to exercise that creativity - just at a higher level.

> OTOH I'm not too disturbed by hardware-abstracting layers because you 
> don't have to worry about every new piece of graphics hardware that's 
> being released onto the market. But with them you can't get your hands 
> dirty with the "real stuff" ;).
Exactly.

...although with OpenGL extensions, things aren't 100% standard across
hardware.

> I can't avoid the impression that dynamic textures are slow, though. 
This is a bit of a misapprehension - albeit a commonly held one.

With 4x AGP, you can easily transfer a megabyte of texture in a couple 
of milliseconds on a modern graphics card.

Three caveats:

  1) Don't create or destroy textures on-the-fly - overwrite existing
     maps instead.

  2) If you want to download quickly don't enable texture compression
     on the internal format without also enabling it on the source
     format.

  3) glTexSubImage allows you to update only those parts of a texture
     that change.

  4) Match the external format to the internal format so the card
     doesn't have to convert the texels on the way through.

With the upcoming 8x AGP standard, the bandwidth of main memory becomes
the limiting factor. Since the AGP bus manages the transfer, it's 
actually faster than writing pixels with the CPU.

> You'd have to upload them from scratch every time you alter them. This
> does not seem to be overly efficient.

That's not true.  You have glTexSubLoad - it allows you to replace any
rectangular portion of the map.