Hey all.
I've been porting an old PC demo to Win32, hoping to port it to
consoles as soon as I finish. But I wasted so much time trying to
emulate vblank under
windowed Win32, that it seems as if it would never happen.
The demo heavily relies on vsyncs for the animation. Otherwise, the
music just
seems way off and not related to the demo at all.
The real problem here is that even if you do get real retrace sync (which
I think should be possible with DX, even in windowed mode), it’s not
going to work! Unlike NTSC(60Hz) and PAL(50Hz) video monitors, computer
monitors have no standard refresh rates these days. The “standard” 60 and
70 Hz VGA modes have been replaced with various resolutions with refresh
rates anywhere between 56 and 240 Hz, depending on monitor + video card
capabilities and user preference.
Either way, you’re not relying on the video refresh rate and the sound
card sample rate to have an exact relation, are you?
If you are, fix it - it wouldn’t be reliable even if you were using only
DOS, SB16 cards and Mode-X, due to the crystal oscillator tolerances.
(The timings are not derived from the CPU or chipset clock like in the
C64 and Amiga days.) You’ll have to compare the logical “nudge” one of
them in the right direction whenever they drift. (Popular solutions are
called “flywheel sync” in MIDI sequencers, or PLL in control engineer
terms.)
Does anyone have a solution for this? I dont think I’ll have problems
on consoles,
Right; consoles still use PAL and NTSC, at least when connected to a TV.
(Some seem to support VGA output as well, but the only one I’ve seen
specs for still used 60 Hz.)
it’s just that Win32 version is bugging me as hell!
You’ll probably have the same problem on Linux (X, fbdev, svgalib), MacOS
and other platforms as well.
Solution 1:
Use fullscreen modes only, and use whatever means available to
select a suitable refresh rate. (Not supported by SDL.) For
example, DX allows you to chose a preferred refresh rate when
creating a screen surface in fullscreen mode. Check it, though,
as you may not get what you ask for! (It's limited to the list
of modes listed by video card driver, the ones not supported
by the monitor removed.) Even if you don't get what you want,
at least you'll know what you have, and you can try to deal
with it.
Solution 2:
Just open a screen and then determine the refresh rate using
a minimal loop with SDL_FlipSurface() and some accurate hardware
timer, preferably something based on the RDTSC instruction. (On
Win32, you can use the performance counter API.)
One rather reliable method I've been using on Linux is looping
over some frames, picking the *minimum* time - you may be
delayed by some other tasks in the system, but nothing can
shorten video frame. (Yeah, rigt! :-) But we're expecting that
no one switches video mode while we're measuring.)
Solution 3: (Retrace sync not possible.)
Just limit the actual frame rate to whatever you want, and use
SDL_GetTicks() or something to throttle. Don't assume that
you'll achieve that frame rate though! As far as possible,
the animation/control system should be separated from the
actua rendering code in order to handle any frame rate
correctly.
//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.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Monday 23 July 2001 22:53, Gil Megidish wrote:
But we’re expecting that
I guess they just couldn’t be arsed to fix