Timing frames

Timing frames

Post by Paul Kmi » Thu, 16 Nov 1995 04:00:00



Can someone post some code which would speed up the PIC so that I can
time how long it takes for my program to "create" a frame.  Oh also how I
would read how much time has pasted between two events.

Thanks,
Paul

 
 
 

Timing frames

Post by Roger Heathco » Sat, 18 Nov 1995 04:00:00



> Can someone post some code which would speed up the PIC so that I can
> time how long it takes for my program to "create" a frame.  Oh also how I
> would read how much time has pasted between two events.

> Thanks,
> Paul

No need, surely you could draw a thousand frames and divide the time it took
by a thousand. This`d be more accurate anyway...

Rog.

 
 
 

Timing frames

Post by uglmil.. » Mon, 20 Nov 1995 04:00:00




>> Can someone post some code which would speed up the PIC so that I can
>> time how long it takes for my program to "create" a frame.  Oh also how I
>> would read how much time has pasted between two events.

>> Thanks,
>> Paul

> No need, surely you could draw a thousand frames and divide the time it took
> by a thousand. This`d be more accurate anyway...

> Rog.

Because he probably doesn't want the AVERAGE time... If you use the average
time, the gameplay speeds up and slows down along with the display. That
can really ruin a game, and has * implications for running it on much
faster or slower machines.
 
 
 

1. Displayed frame rate vs. buffer frame rate vs. displayed frame rate?

One thing that bothers me about the notion of frame rate in the various 3D
engines, (OpenGL and D3D included), is that the frame rates reported don't
appear to actually be the displayed frame rate.  In other words, it seems
that the reported frame rate is the rate that frames are complete in some
buffer away from the actual screen display, while the frame rate that
actually appears on the screen is quite different.

How is it possible or even worthwhile that the frame rate be 190 when the
screen itself is only updating at 75 frames per second?  I thought that the
flip() primitive was set up to wait for the vertical retrace, which would
make me think that the background buffer is waiting for the vertical
retrace before it's flipped (or blitted) to the diplay surface.  If that's
the case, then the backgroup buffer should be held pending a vertical
retrace, rather than having the application overwrite it so that it's not
ready to be flipped when a vertical retrace occurs.

So the reported frame rates that are higher than the screen refresh don't
make any sense to me.  Does everyone agree with me?  Can anyone explain
this?

Wilbur

2. USENET mail headers

3. Real Time, and good Frame Rate

4. Games PRogramming in pascal

5. "It works" time vs. "It's finished" time

6. Outlook Express to slow in XP for some users

7. Looking for animation frames

8. Problem With SS7 Using Frame-Relay!

9. VESA 2.0 linear frame

10. Capturing animation frames from a game ...

11. DirectDraw Frame rates

12. 100% Constant frame rate in win95

13. Multiple frame 16 bit graphics format???