David Rempel wrote:
What makes you think that waiting on vsync has anything to do with
voyagers single keystroke scrolling jerkyness?
In order to make smooth scrolling you NEED to blit/draw exatly ONCE each
time the gfx card updates the screen.
This need to happend(Or at least start) just after the gfx card draw the
last scanline. And the only way for a program to do that, is to wait for
the VBlank interrupt.
and then start the draw/blit operation.
This does ofcause require that the gfx operation is so fast that it can
complete before the gfx card have drawn the entire frame, but this
should not be a problem at all.
My old Trio64 gfx card(at least 5 years old) was able to scroll(using
the blitter) fullsize 1024*768 16 bit with 85 hz. And it did NEWER miss
a single frame. Looked like a dream :}
Have you actually done
anything to verify this or are you just guessing (I’m pretty sure I
know the answer to this one already).
Yeps i have. The only way I can imagine to get smooth scrolling is using
something like this
Waitfor Keydown; // Wait until the user request a scroll down.
while( Continue as long as we don’t recieve a key up, that is as long as
the user keep the key pressed down)
ScrollHeight=1; // Number of pixel to scroll each vblank.
// The argument to blit is
// Move anything ScrollHeight pixels up.
DrawTheNewBottom(ScrollPixelHeight); // Draw the new line at the
PgWaitFlush(); // I think that PgWaitVSync does flush.
PgWaitVSync(); // Wait until the VBlank interrupt come. and the start
(or IMHO a good) thing to do. The busy wait in the drivers (while
not ideal) keeps us from having to store all that extra information
(decreasing memory footprint), and still supply a wait on vsync for
those that must have it.
Nope because sometimes you miss the VBlank due to a interrupt causing
WaitVSync to wait 1 frame to much. The problem is that the bit(or word
can’t remember) you are waiting for only change very
in a very tight moment before it thange back to it’s original moment,
thus causing PgWaitVSync to miss it, it there come an interrupt. This
does in fact happen on my 400 Mhz celeron doing nothing else and running
on priority 10 as root.
You’ll also notice that it is only
available to applications (as per the docs) that are in direct mode,
Yes, that is an other BIG problem. But that seems to have changed.
Because in the 6.2 beta it appears also to work in “normal photon mode”
so only one application is talking to the graphics driver when this
is employed. (hence the reason why I’m pretty sure I know the
answer to the first paragraph in this post).
And now I just have to make an enourmes argument for
allowing/making/whatever a way to wait for the VSync in “normal photon
point considering having io-graphics send a pulse on every
vertical retrace (interrupt driven) to applications that were
interested in it but we never implemented it, it didn’t seem to
us that it was worth the effort at that point in time. It may
still appear in a later release, but not any time soon.
Now you almost make me cry.
Which ofcause cause me make an other question:
Does anyone know where to find documentation for the Voodoo3 chip, so I
can hack my own vblank interrupt demo together, showing anyone with a
Voodoo3 card why a VBL signal is vital to a modern os?
BTW: I always turn it off in games that allow me to do it, it helps get
a more constant average framerate, which is far more important to me than
That is right. As long as your gfx card is not fast enough to update the
screen each frame turning vblank of might be the best solution. But that
is only a problem with 3d Games. All 2D graphics should be fast enough
so that this is not a problem.