## Timing frames

### Timing frames

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

> 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

>> 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.

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