Its a pacman game and has been programmed in Turbo C v3.0 (320x200x256). The code is well optimized and is running smoothly without any flicker. The flow of the game is as follows: 1. Does all the calculations. 2. Draw/Moving the sprites. 3. Wait For the Vertical refresh. 4. Erase sprites. 5. Loop continues. Here if u see the movement of sprite is synchronized with the refresh rate of the video mode, and the vertical retrace signals are a very steady timing source. The sprite cannot go faster, eventhough u have coded well, than the video mode's refresh rate allows! But what happens on computers with different speeds than the one i have tested with (Pentium III, 500 Mhz.) i know that it has something to do with 8253 timer chip programming. But then what will happen to Wait For Vertical function call? will it be required then? if i omit this function then it will flicker. I just wanted to know how to give a proper delay using 8253 timer, which would allow the game to run at same speed on different computers. I don't want to change the frame rate of the game. Any help! pramod

You shouldn't have to change anything if all machines are fast enough to run at the refresh rate. And keep in mind that mode 13h should run at a constant rate (75 Hz, if I remember correctly) on all machines.

Be careful of how you want for vsync though. If the machine is fast enough to render an entire frame within the vsync period then simply waiting for the vsync bit to be set won't be enough, instead you should always wait for the vsync period to be over first.

Another simple improvement is to detect if mutliple frames has elapsed with a timer (like the one you mentioned) and run the game logic more than once to compensate but still only render once and wait for vsync as usual.

Also, are you using double buffering at all? If not then you risk flickering regardless of how the timing is handled. It's actually quite simple to write, just reserve a separate 320x200 memory buffer on which you draw the game itself and then at the beginning of each vsync you copy the entire buffer to screen.

Here's some info on the PIT timer anyway, clicky.

The sprites move by 1 pixels either horizontally/vertically at a very good speed if i disable the Wait_For_Retrace() function but with a lot of flicker. i have even tried the double buffering technique but it simply killed the speed of the game. The whole animation turned to slow-motion! i have shown the Wait_For_Retrace function below. I don't know if i am doing it in the right way.

void Wait_For_Retrace(void)
{
while ( (inp(INPUT_STATUS) & VRETRACE)) {};
while (!(inp(INPUT_STATUS) & VRETRACE)) {};
}

Thanx

Pramod

Quote:Original post by tppramod
The sprites move by 1 pixels either horizontally/vertically at a very good speed if i disable the Wait_For_Retrace() function but with a lot of flicker. i have even tried the double buffering technique but it simply killed the speed of the game. The whole animation turned to slow-motion!

Ah, well.. DOS emulation in NT base windows versions tends to kill the performance of graphical applications.
If you switch to Mode-X or a 16-color mode then you could achieve the same effect with hardware page flipping, but it's unfortunately not available in mode 13h.

Quote:Original post by tppramod
i have shown the Wait_For_Retrace function below. I don't know if i am doing it in the right way.

while ( (inp(INPUT_STATUS) & VRETRACE)) {};while (!(inp(INPUT_STATUS) & VRETRACE)) {};

That looks fine to me. The problem is with code that only bothers with the latter of these loops since it assumes that the game has already left the vblank period.