creating a back buffer

Quote:

Original post by ekrax so is there a way that i can create a second screen buffer and draw whatever i want to it, but not view it on the screen? so basically just want a virtual screen in ortho view. im not sure how to create one if i can.

Yes you can, that's called a pbuffer. It's available through the ARB_pbuffer extension (often combined with other extensions for additional benefits). There are many pbuffer usage tutorials out there, just search nvidias and ATIs developer sites.

About the collision, the most efficient way to detect them on the GPU would be by (ab)using the hardware occlusion test (ARB_occlusion_query). But you should compare it to a purely mathematical solution performance wise, because doing that on the GPU for many and/or complex objects is not going to be free. And it will only work in 2D obviously, unless you use some neat tricks with the depth component (slicing, or similar).

i cant see how by doing it with opengl will make it more accurate (in fact the opposite)

anyways, aside from the Yann said about pbuffer, u can also draw to the main screen like so

set ortho
draw your collision stuff
clear the screen
set perspective projection
draw the scene
swap buffers

none of the collision stuff will be seen cause youve cleared it

ok i think i will try the second method becasue the first seems more complicated. but one last question (and i looked on google and coudnt find it) .. is there a function that returns the rgb of a specified pixel in the form GLfloat getPixel2D (int x, int y) or something that returns true for any color and false for black?

Check out the function glReadPixels

Quote:

Original post by TomasH Check out the function glReadPixels

... and after you checked it out, forget about it right away, and don't even think about using it for something like collision detection. Reading back pixels from the 3D card is among the slowest operations possible, and should be avoided at all costs in a realtime 3D engine.

Either use hardware occlusion tests, or do the entire collision detection on the CPU.

well this is for a 2d platform game not for 3d, will it still be expensive on the video card?

any read back from the gfx card is expensive, you are probably much better off doing it on the CPU

>>... and after you checked it out, forget about it right away, and don't even think about using it for something like collision detection. Reading back pixels from the 3D card is among the slowest operations possible, and should be avoided at all costs in a realtime 3D engine.

Either use hardware occlusion tests, or do the entire collision detection on the CPU.<<

i agree that this should be done on the cpu, but readpixels is not slow at all (even my gf2mx gets 10million pixels a second)

Well, you're limited by the readback speed of the AGP bus, and it'll give you a large hit on the CPU. But the readback speed isn't the important factor - the fact that glReadPixels() will stall and partially flush the GPU command FIFO is. So even if the glReadPixel() call is fast (and reading back a single pixel is fast), it will cost you a lot of time due to its negative effects on the FIFO. Although here again, it depends on how and how much the hardware is used. If the FIFO is near its limits (eg. your engine is shader/state switch bound, which is often the case with modern 3D engines), or if you're geometry or fillrate bound (ie. loss of GPU/CPU parallelism due to the FIFO bubble), then a single call to glReadPixel() and hell breaks loose - even if you're only reading a single pixel.

On a simple and very lightweight engine though, chances are you won't see a difference, because the FIFO is almost always empty, and CPU/GPU sync is not yet an issue.