Angus Dorbie uid (angus++at++division.demon.co.uk)
Thu, 17 Nov 1994 11:29:25 +0000
Hi Simon,
I cannot guarantee that the information here is relevant since I only
have your email to go on but here goes anyway:
It sounds like your customer is using the RE method of clearing the
screen quickly by simply invalidating z buffer values. This means that you have
to fill the entire screen with database so at the horizon you are seeing the
contents of previous frames because no database is written there and don't get
the background colour written to the framebuffer. By moving the clipping plane
out you add more pixel fill requirement to the framebuffer and perhaps this
pushes you over a swapinterval. When you say it doubles the frame rate, does it
double the rendering time or just half the number of swapbuffer operations the
application can make? Timings of this nature have to be made without swapping
the framebuffer since this rounds the timing information to the monitor refresh
rate. Can the application make the required frame rate while looking at the sky
_before_ the clip plane has been moved? If not then you are probably pixel fill
limited. If you are pixel limited then reducing the size of the channel you are
using should bring rapid relief, alternatively try using intensity maps instead
of full colour wherever possible, and try using a 16 bit internal texture
format for colour images if the quality loss is acceptable. You might also want
to make sure that there isn't an expensive rendering mode being left in the
pipeline such as transparency which is costly even with opaque geometry.
Regards,
-- ________________________________________________ Angus Dorbie Division Ltd, Software Engineer 19 Apex Court, Tel: (01454)615554 Woodlands, Fax: (01454)615532 Bristol BS12 4JT, angus++at++division.demon.co.uk UK ________________________________________________
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:40 PDT