If this is your only problem, you’re doing something wrong. I’ve
suceeded in getting better-than-arcade class smooth scrolling with
OpenGL on a hacked Utah-GLX driver (had to add retrace sync… heh)
on Linux, and that setup doesn’t even do page-flipping! (It renders
into a back buffer, which is then blitted into the front buffer, all
in h/w on the video card.)
Yep, but OpenGL flips do not wait for the next vertical blank,
Actually, they do in a sense - but only “in the other end” of the 3D
accelerator command buffer.
that is
exactly what I want from DirectX using SDL too, but that is just not
possible.
Right. That’s why we need triple buffering. Using multiple video buffers
is the s/w rendering equivalent of using a bigger h/w accelerator command
buffer - it just requires h*lluva lot more memory! heh
The key is to stop whining about not being able to set the refresh
rate, and accept the actual refresh rate as you time base. (You may
need a PLL to extract the actual timing, because of the scheduling
timing jitter of most operating general purpose systems.)
eermm… I am not whining about that at all! I do NOT want to set the
refresh-rate of the monitor of the user…
I didn’t mean it like that, and I wasn’t refering to you, but rather
these “I want a fixed frame rate” posts that drop in every now and then.
Sorry if I offended you, or anyone else.
I want to be able to let my
game run at a constant rate INDEPENDANT of the refresh rate of the
monitor.
Then you’ve got the right end of the stick. 
The whole point of this is, that I have a logic-routine which
may only be updated 15 times per second, and an independant drawing
routine which may be updated as much as possible.
With interpolation? Soooo much smoother!
Now, if I have the
drawing-routine take too long since the flip() call has to wait for the
next vertical blank, my logic-routine will be delayed because of it. Do
you see my point now? I hope it makes it clear, because I get the
impression you are totally misunderstanding my questions regarding this
subject.
Yeah - and although I now have a better idea what the problem is all
about, I still don’t quite understand what exactly you mean by the logic
routine being “delayed”… Isn’t the normal
while(logic_time < next_frame_time)
run_logic_frame();
solution sufficient?
Note that that means that the logic “frame” function may run anything
from 0 and up times per video frame! Failing to implement that is
probably the most common reason why games fail to run at consistent speed
across systems.
Is the problem that you’re not getting sufficiently accurate timestamps
when checking the time after each flip?
The MOTD thread I linked to in an earlier post explains exactly what I
mean…
Yes, sorry for being lazy - it’s totally clear now.
However, if you want a rock solid solution, well, unsync’ed blit-flips
are problematic, because they cause tearing when used on a single buffer
screen. When used on a h/w pageflipping screen, timing jitter is
introduced, unless there is exactly one blit flip for every real flip.
This would be doable though, and might even solve some problems.
Now, quoting JCAB, here’s the core of the problem:
“Actually, the jittering here happened on a 30 Hz rock-solid framerate.
The problem was that the time spent waiting for the hardware FIFO to
empty would vary every frame, distorting the time measurements.”
That is, even if we are running at a rock solid full frame rate (which
most 2D games will do with glSDL, or other full h/w acceleration
solutions), the problem is that we can’t figure out exactly when each
frame we render will be displayed.
If we indeed do have a constant output frame rate, PLL style filtering of
the timing info derived after flips will work very well. If we end up in
horrendous situations like the 60/30 Hz alteration described earlier in
that thread, any filtering will only make things much worse!
Seems like a way of asking drivers exactly when each frame is flipped in
would help, but there’s actually no generic solution for the alternating
frame rate problem. It could probably be solved in some cases, but not
without close driver/application interaction.
I can’t see how it would be at all possible to do completely in
application space in a reliable way without a RTOS, although using a
separate flipping thread to get closer to the actual h/w flips could help
a lot.
So, are you expecting to get steady full frame rates on any reasonable
hardware…?
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 08 March 2002 15:11, Martijn Melenhorst wrote:
I just didn’t think that