I believe I read somewhere, someone (may have even been Cass Everit from nVidia over on the OpenGL.org boards??) suggesting that a way to reduce the hit on fillrate may be to use the glScissor test.

IIRC, you project the shadow volume (or maybe a bounding box of it for more speed) to find the extents to which the volume will fill the viewport, then set the scissor to restrict drawing to only this area. I think this is a big win the further away the volume is from the projection plane (in the case of a perspective projection).

quote:

---

Original post by Safe_haven
Actually, what I''m going to try to do today is put a check at the beginning of my render cycle to see if I''m ahead of/behind where I should be to maintain a rate of over 120 or so...then have it drop frames if I''m behind. That way I should keep my maximum FPS without crippling any better rates I might be able to squeeze out at a given point. How feasible does this sound?

---

Huh? The best FPS you can get with double buffering is 120 FPS. Then, assuming a stable frame drawing time, the next best is 120 / 2 = 60 FPS. The next next best is 120 / 3 = 40 FPS, and so on.

Dropping frames isn''t going to increase the number of frames that you draw per second, since you''re being limited by the vsync wait, and _not_ by your calculations. And besides, if you only render every other frame, you''re still going to end up drawing about 60 per second. If you''ll feel better by dropping frames and still counting them so your counter reports 120, fine. But you''ll just be coding an inaccurate counter.

The way to escape this bottleneck is to find ways to stop waiting for the vsync. One way is obviously to reduce the amount of time it takes to draw a frame to pop back over 120Hz again. Another way is to disable the vsync wait. Another is to triple (or quadruple or whatever) buffer, so your program is doing something useful while the swap routine waits for the vsync signal to show up.