What I have now is a mmtimer function that updates all the sprite positions every 10 milliseconds, with each sprite having a frame length variable that controls the frame change, i.e..

TimerUpdate() //updated every 10 milsec
{
//update each sprite pos if frame len //counter is overdue

for(i=0;i {
Sprite.counter+=10;
if(Sprite.counter>Sprite.FrameLen)
{
Sprite.counter = 0; //reset counter
UpdateSpriteFrame();//next frame..
}
}

}

Each frame is updated as fast as the vsync is running (60fps), so if the FPS is at 75FPS, the blit positions will be where I want them, but im worried because animation may not be smooth when the FPS change due to more blitting etc..

Would I get a better result if I calculated from the Frame speed instead? (using the code from yesterdays post)

I was wandering if this is the same with the other technique, i.e calculating blit positions with the FPS instead of pixels?

The mmtimer (not the standard timer) I am using is very accurate as I have tested it in a multimedia app I made. Isnt QueryPerformanceTimer using the same timer as a multimedia timer?

I was wandering if there is any C/C++ source code available for a windows platform/shoot'em up game so I can get an idea of how it should be done (prefferably a commercial or good shareware game). Any ideas?

Is there a way to set the DDraw Fullscreen video frequency to say 60Hz on every system so my blits are in sync?

How does everyone control the timing?

Also, if I use the vsync to control the screen animation speed, my game will slow down on slower machines! How do I overcome this problem?

(I remember in DOS 320x200 the vsync was always constant on all systems, so controlling animation was easy)

hhheeelllpppp )-;

Machine.. P2/35064MB, i740 8MB, @ 640x480x16bit