Re: [AD] Framerate under the 4.1.x WIP Windows builds is mysteriously slow.

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sat, 2005-03-05 at 14:37 +0100, Andrei Ellman wrote:

>  > No - it"s simply a variable increased in a timer. Not much point using
>  >  it for anything, you can as well create your own timer.
> 
> 
> I thought that on hardware that supported vertical-retrace interrupts, 
> retrace_count would automatically synch itself with the card's retraces. 
> If retrace_count is nothing more than an inaccurate timer that is not 
> updated as often as it should be, then there does not seem to be much 
> point in using it.

Well, from what I see in the code, it syncs with the monitor refresh if
possible. But still, it just runs in a timer. So it won't be as accurate
as calling vsync directly. If the OS supports it, it could schedule
directly back to your program after the monitor refresh is done - so
nothing can be more accurate.

> Incidentally, I used to crerate a timer of my own instead of use 
> retrace_count. I once installed a program of mine on a friend's machine 
> that uses Linux. It was the first time I had seen my program run on 
> Linux (previously, I've seen it run on Windows and DOS). It used Allegro 
> 4.0.3. The program ran normally, but there appeared to be a shear that 
> consisted of a vertical line moving upwards very slowly and then 
> starting from the bottom (it took about 5-10 seconds). If I disabled the 
> vsync() command, there would still be noticable shearing, but then, the 
> shearing would be jumping around all over the place. The conclusion that 
> I got from that was that my own timer was ever so slightly off (and that 
> vsync() was also inaccurate in this case), so I decided to use 
> retrace_count in the hope that it would synchronise to the monitor's 
> refresh-rate if possible (I never did get to test the retrace_count 
> version of that program on my friend's machine).

Just using vsync should sync to the refresh, of course. You update the
back buffer, call vsync, then blit/flip to the front buffer. So there
should be no shearing at all, in case the flip can be done fast enough,
and control is given back to your program fast enough after the vsync
happened in HW.

Without any vsync, there's random shearing of course. And with the
retrace timer, rather then specifically waiting with vsync at the point
in the program where you need to wait, you just poll that counter
variable, which polls the vsync state in another thread. So AFAICS, it
should be less accurate.

If you use the standard "page-flipping" or "triple-buffering" with
allegro as shown in the examples, you should get no shearing at all,
with DirectX. show_video_bitmap/request_video_bitmap internally use
vsync to achive this. So counting FPS with show_video_bitmap actually
should return exactly the monitor refresh. And request_video_bitmap
should be the most accurate, since, in the case of Allegro's DX driver,
Windows/DirectX will flip the buffers at just the right time,
asynchronously to the program.

All of the above is just the theory, I have no idea how well it actually
works with current Allegro, since I don't use Windows myself.

-- 
Elias Pschernig