[SDL] Re: Anouncing LsdlDoom

Florian 'Proff' Schulze florian.proff.schulze at gmx.net
Fri Apr 28 16:27:48 PDT 2000

>I don't really believe in this. If you can make 51 fps on a monitor
>going at 80 Hz, that will be better than 40 fps. Of course, the game
>logic has to compensate the time properly!

For a 3D shooter you are probably right --- they show a remarkable
tolerance to low frame rates and even tearing. But for a 2D game I'm
not so sure. Consider:

                   |---------------------------------> time
monitor refresh    m    m    m    m    m    m    m    m
game frame update  1      2      3      4      5      6
player sees        111111111122222333333333344444555556
object position        /\      ^      /\      ^    ^

In this example, frames 1 and 3 are shown twice as long as frames 2, 4 and 5.
Imagine you have an object moving with constant speed on the screen. To
maintain the illusion of constant speed, the time points for each frame
should be the midpoint of the interval during which the frame is seen by
the player (marked by ^ and /\). Of course, these have to be known in
advance when rendering a frame (in order to draw the object at the right
place), but then you must know where you are in relation to the vertical

And even then, I'm not 100% sure that motion will be perceived as
*completely* smooth, since the users sees the object occupying some
positions for a longer time than others.

>I was told that XFree86 queues drawing requests at retrace to the
>accelerator, but for operations that are done in software, the
>synchronization too bad to help (the problem I described) and/or
>software PIO transfers are so slow that they take more time than the
>vertical refresh allows for.

This is great news. That would imply that we could replace

     XShmPutImage(Shared XImage to Window);


    XShmPutImage(Shared XImage to Pixmap);
    XCopyArea(Pixmap to Window);

and get triple-buffering at (almost) no extra charge!

More information about the SDL mailing list