It seems like i am limited in regulating my fps by the timer
resolution in SDL. I can only manage to regulate 1sec/10ms allowed
per frame = 100 fps or 1sec/20ms = 50fps. How would I set a cap at
something like 60 or 70 fps if I can only track a frame in 10ms
increments.
Unless you’re on some broken version of Windows (some release of NT or
Win2k, I think), you should be able to get ms accuracy with
SDL_GetTicks(). However, it is true that you generally cannot
schedule with better accuracy than 10 ms. This applies to pretty much
all platforms. QNX, later Linux 2.5 kernels and some other OSes can
do betters, but that’s pretty much irrelevant unless you’re going to
build your own gaming machines or something.
So, the simple answer is “You don’t.” A more useful answer would be
that you can throttle the frame rate to an average of those 60 or
70 fps you want. Calculate the desired delay, wait and then check
SDL_GetTicks() to find out where you are after that. Feed the error
forward into the next delay time calculation.
Also, on rare occasions a rectangle is not completely drawn or is
drawn in the wrong spot or looks garbled(random pixels). Is there
a way to detect if this happened and then refresh the area or to
prevent it? I am using a dirty rectangle system with UpdateRects
and just ported my game to SDL. There were no draw errors in my
other implementation.
Why does it happen in the first place? This definitely sounds like a
bug somewhere. I’ve never seen it with any SDL code, so I suspect it
has something to do with your drivers and/or the SDL backend you’re
using.
With Allegro to vsync I could just call a
function vsync(), how would I do this with SDL?
Direct retrace sync is rather pointless unless you have an RTOS (or no
real OS at all, like in the old days). This is part because of poor
scheduling timing, part because h/w accelerated displays render
asynchronously. (Try retrace syncing on the application side while
rendering with OpenGL and you’ll see what I mean. 
The SDL logic is based on the idea that it’s the video driver or
hardware that does the sync.
You just send a page off with SDL_Flip() and let the backend or driver
do it’s thing. If retrace sync is at all possible (it isn’t on some
targets), the application will sync indirectly, either by blocking in
SDL_Flip(), or by blocking the next time you try to lock the display
surface.
Note that this is only possible with double buffered h/w surface
displays! Single buffered displays (or displays with “fake” s/w back
buffers) don’t pageflip (obviously), and therefore cannot retrace
sync by definition. (Of course, it would be theoretically possible to
do so, but you’ll need an RTOS, or you’ll only make things worse.
Constant tearing in a fixed place isn’t nice at all.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 16 May 2003 14.28, jrschnayer at ucdavis.edu wrote: