I'm using an HDTV as a monitor, and I'm not sure of the best way to deal with the overscan (which, by the way, is not proportional in the vertical and horizontal directions). The overscan is roughly 32 and 24 pixels on the horizontal and vertical directions. The way I'm saving the card from drawing outside it is: glScissor(32, 24, screenWidth - 64, screenheight - 48); and for gluPerpective, the aspect is with the uncropped dimensions as before: static_cast<float>(screenWidth) / static_cast<float>(screenHeight) I'm not sure if this is correct, or I should use glViewport instead of glScissor (and how that would affect the gluPerspecive aspect calculation). What's the right way to do it? Second, if I use an FBO for HDR rendering, before cropping, I was just using glOrtho(0.0f, aspect, 0.0, 1.0f, 0.0f, 10.0f); then drawing a quad from (0,0) to (aspect,1) with texture coordinates (0,0) to (1,1) That would give me 1:1 texel to screen pixel correspondence. If the texture was the full dimensions of the screen resolution, this would work as is. But because I made the texture size (screenWidth - 64)x(screenheight - 48) to avoid wasting texels that would not be rendered, I'm wondering, how do I change the above to still get 1:1 texels to pixels? (I also assume with the smaller texture size I would also change the gluPerspective used to render to it to have aspect that is based on the reduced dimensions rather than the original) [Edited by - Prune on February 17, 2008 6:05:00 PM]

Yes, glScissor is what you should use. This throws away pixels outside the region.
You should call glViewport as well because this effects how objects are mapped to screen space.

Why don`t you make the texture the same size as your window space?

No, glScissor is not what you should use. Scissoring is a fragment operation. That means that all geometry in the 'dead area' is still transformed, vertex shaders executed, rasterized - and then thrown away.

You should use glViewport instead. Your projection matrix describes the visible part of the render frustum. That would be the part excluding the guard band area. You'll have to recompute the FOV accordingly, if having a 100% precise FOV really matters to you (in practice it probably won't). You can then use glViewport to scale and offset the visible area on the render window.

Don't forget to also adjust your high level frustum culling, if you use any (which you should).

So I should glViewport with the reduced dimensions (same as the texture size) and then gluPerspective with the aspect ratio that is calculated from these reduced dimensions. Then, for rendering to screen, I would use the same glViewport command, and leave the glOrtho as it is, but changing the 'aspect' number in the quad drawing from my first post to one from the reduced dimensions. Is that right?

I'm not sure what you mean by high level frustum culling. If you mean scene level management such as spatial partitioning, I'm not using any since I'm not making games and the majority of the geometry will be in camera view at almost any time.

What is the use of glScissor then? Can I use glViewport for picking? Currently I'm using glScissor to render flat color-coded selectable objects so I know what I'm clicking on. Since I'm only rendering a couple of pixels then, I'm wondering if I use glViewport, whether a triangle with all vertices outside the tiny viewport will still render, or not (I'm thinking it might be the latter as you said vertices outside the viewport are culled).

Hello?