Hi!

I'm working on a spacecraft game. It is not fully made in assembly language, but the code so far IS. I mean, I've written the whole blitter in Flat Assembler and the ISRs for the Keyboard and the Timer. They work OK. The problem I'm having now is how to synchronize with the vertical retrace. I know how to do this if it's the only thing to be done, but I don't get it to work well when I have to move the ships at the same time.
What happened is this: I make a program in QuickBasic to try the Assembly routines. I change things until it works OK on my Pentium 200MHz. But, as I want this game to work even on a 486DX2, I try the code in my other two little PCs: a 486DX4 100MHz and a 486DX2 66MHz and I find out that it does not synchronize there. It's like the timings are different.

The final question: Can anybody send me an example (in any language) about which steps I should take to make a main loop at about 200Hz synchronize with the VGA at 60Hz?
Maybe you didn't even understand what I'm asking... I haven't been very clear Well, if you think you can help me, but are not sure, tell me and maybe we can chat, I explain you and show you the code. (Whoever you are )

AFAIK, you can program the video card to make interrupt on the vertical sync pulse. IMHO, this is the only proper way to make real synchronization.

Regards

why do you need 200Hz, i coded few games already and 40 was always enough for me.

If you do hardcoded "timeloops", the game will run very bad on other computers (too slow, too fast).

If you limit your gamespeed solely by synchronizing to the refresh rate, you will have problems if the user overrides the refresh rate - use a time-based approach instead (yes, it's more work).

Making the graphics card generate an IRQ is cute, but not all boards support this, and you cannot use the feature if you want your game to be compatible with windows - better to use the old method:

Thanks. Anyway, I already know how to detect the vertical retrace and what I am trying to do is precisely using timer instead of VR synchronization. I am doing something like this:

wait for one vertical retrace
set timer to zero
start:
set minitimer to zero
check if timer is near one sixtieth of a second
if it is:
wait for VR
set timer to zero
refresh
endif
check input
exchange packets
wait until minitimer exceeds "cycleduration" (e.g.: 1/200 seconds)
loop to start

For some reason, when I adjust the values for my Pentium, this does not work well at all on my 486s.

Ah... sorry... one more thing.
I use 200Hz, because sometimes I want the objects on the screen to move at different speeds in fraction. That makes me have to invent virtual pixels, for example, the speed of one object can be 20 pixels per second and another one might have one of 20.3 pixels per second. But one second is a very long time. And because I will not refresh in every cycle, 200Hz is not too heavy. But yes, you're right, it makes things much harder to perform.

You will need a military machine to achieve that 200 fps on your game.
and your display frequency shouldn't be higher than 100 Hz, for example its the max in 800x600 of my 15" monitor.

But in assembly you may wanna try to make an optimized code.
I whould suggest you to think a little more on that 20.8 pixel things, cause' if you wait for a vertical sync in a loop, you will not do anything but waiting.

MATRIX

Cas, you can look at a dos game i make when i first started in asm, full tasm code and only 4k.
you can get it here: http://www.falconrybells.co.uk/

called "pong.zip" it's pong game set in space!.

\\\\||////
(@@)
ASHLEY4.

Just curious... isn't 1/40 seconds more than enough?
The eye see things as continuous with more than 16 frames/sec.
Few people catch diferences between 16 and 30 frames.

Anyway the focus should be on correct behaviour instead of attempeted frames that may, or not, be available which seems to be the case.



Just Guessing : Incorrect draws and/or speed going up and down.
In other words: de-synchronization on more heavy calculations and/or slower CPUs...

If so: You are spending too much time with useless draws in expense of movement calculation... And have no actual control on the syncronization of movements... But you don't have to... Neither one...




Just invert your aproach:

repeat
{
Check_Controls

// Prepare for critical sequence
New_moment <- Get time
delta_time <- New_moment - last_moment
Last_Moment <- new_moment
Check Behaviour rules (Controls)

// More Critical part
Movement calculations (delta_time) // Delta correction

// Less critical part as will not influence the real critical one
Process_image (Movements ; Behaviour)
wait_for_sync
Draw_image
}
until EndOf



This should make frames auto-adapted (actualy CPUxCode dependent) and should work with slow CPUs and/or heavy code... On too slow CPUs or too heavy code frames frames will go down 'per si' ... on faster CPUs they will go up to the video sync limit.

The hard part will be to calculate movements and events adapted to the time slice in between... Just determine what happens between slices of time and it will be shown correctly...

The behaviour will follow the CPU instead of you following both

Cheers
DuLac.

Most people's monitor are more closely mached then there pc speed. 60hz-100hz
By making your main game loop, so it wait's very little time for vetical retrace on a 486, you would get the right speed on most pc's, you would after have some very bad programming for your dos game to be slow, even on a 486, in my main loop i had to put a big delay in, as even on a 486 it ran too fast.

\\\\||////
(@@)
ASHLEY4.

Maybe something like this might work?
Make a macro that checks if Vretrace is right for a screen update,
and sprinkle it about in your game loop code. (use ports to check)
If Vretrace, if data ready, if time right, update screen, ELSE continue.
Continue in the work loop which has functions called in priority, top to bottom.
So bottom game functions get called durring slow times only.
Like a priority system.
Then an array of bytes indicating the status of each function called since last screen update allows already processed functions to be skipped. There would be no wait for Vretrace at times that a good frame rate is required. INC function status bytes on each screen update, & zero out a functions status when called (maybe) then, make sure a function is called if it flips the status byte & sets the zero flag?
That way it's not ignored forever.
At 60 frames per second (60hz), bit 7 of a byte is set every 2 seconds?

JOHNFOUND "AFAIK, you can program the video card to make interrupt on the vertical sync pulse. IMHO, this is the only proper way to make real synchronization. "

I am very interested in this method.
Do you have any asm code, links, or further info for me/us?

About that. In my computer, my motherboard allows me to assign IRQ 10 to the video board. In case the interrupt sync can be done... is it ALWAYS going to be at IRQ 10? If not.... how can I find out if this is available on a PC and at which IRQ?
By the way... THANK YOU FOR ALL THE HELP YOU'RE GIVING ME. This is still very useful after all this time since that project.

IMHO you shouldn't use video IRQ, because it will not work on many videocards. I cann't recommend optimal solution, but I think detecting length of video refresh (in timer ticks) can help you to roughly determine where beam currently is, and how much time you have until next vsync, this can be helpful.. Also.. you can set new timer interrupt to happen just before vsync and wait only remaining millisecond or less(and reset timer counters after detecting actual vsync pulse) Nice idea, huh? this method can also be combined with triple-buffer. (you draw in buffer A, buffer B is ready to display and copied into framebuffer C (or pageflipped) by interrupt handler ) For movement you can update coords after/before rendering each actual frame, but divide all speeds, given initially in "pixels per second" by known refresh rate, using fixed-point math or FPU.

Listen, it`s all very simple. Get your game commands in( up down shoot ect.). and calculate where you want to put your pixels. make the changes in memory fist before even touching the screen. Then, have your screen memory as a pointer (in c++, or an array in assembly language ect) then refresh the screen and draw the whole thing at once by having the screen pointer locate your memory image.