[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OpenGL question

Stephen J Baker wrote:


On Tue, 11 Feb 2003 voidstar@tin.it wrote:


>does anybody knows if and how can I do a thing like
>this in OpenGL?
>
>  unsigned char* pA000 = vga_getgraphmem();
>  pA000[pos] = color;


You can't (nor are you ever likely to be able to).

There are multiple problems with such a thing:

  1) The graphics card is HEAVILY pipelined during OpenGL
     operations - when you draw a polygon, it may not appear
     on the screen until several milliseconds later.  If you
     could just do raw screen accesses, who knows what partial
     junk you'd read.

  2) There is no guarantee that there *are* any pixels laid
     out simply in memory.  The if you are doing FSAA with the
     nVidia GeForce cards (for example), they are rending to a
     multi-sample buffer with up to four RGB samples per pixel.
     The new GeForceFX (if it ever appears) aparrently adaptively
     stores either whole pixels or partial sub-pixels depending
     on whether the pixel lies on the edge of a polygon or not.

  3) What about windows that are partially overlaid by other
     windows?

Basically, this has not been possible since maybe the second generation
of 3D graphics cards - and it's NEVER likely to be possible again.

The simplistic idea that one memory-location == one pixel == one
spot on the display is no longer valid with windowing systems,
3D and antialiasing.
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.

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?


>With svgalib i can do this, but in OpenGL? Is there
>a way to access the screen like an array (not only 320x200,
>but also 640x480, etc.)


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.

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" ;).

I would lay very good odds that whatever it is that you are
trying to do with raw screen access could be done more efficiently
using the OpenGL API.
I can't avoid the impression that dynamic textures are slow, though. You'd have to upload them from scratch every time you alter them. This does not seem to be overly efficient.