Jump to content
  • Advertisement
Sign in to follow this  
Prune

Dealing with HDTV overscan--please help

This topic is 3891 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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]

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!