Well number 1 is the simplest and most reliable way to do it. I think these are the only two options, but using a timer is bound to fall out of sync with the retrace eventually I would think, unless you keep correcting it.

When you say reporogramming the timer won't work under Window's, do you mean running the program (I assume we're talking DOS here) under Windows, or writing an actual Window's program that modifies the timer? My DOS game reprograms the timer, and it runs fine under Windows.

Rock

I have a solution:

If you use the screen and 2 buffers you can
send the triple buffer to the double buffer.
Place your mousecursor (and other objects?) on the double buffer and send it to the screen after vsync();
(call some sort of mousexy function before you'll place the cursor)

Hope that helped.

Rock: yes, we are talking about running dos programms . Windows allow timer reprogramming, but only on a little small amounts (coz win uses timer itself). But reprogramming it, for example, to 70Hz may cause a little problems.

The 1st way will slow down whole code, but i
remember another way: hooking on video adapter interrupt. I've tryed to implement this some time ago (for hicolor emulation in 13h mode), but my code doesn't worked.

bosjoh: copying from first buffer to second and then to memory is VERY slow.

thanx for your replyes

------------------
FlyFire/CodeX
http://codexorg.webjump.com

I'm not going to claim to understand the intricacies of how Win runs a DOS program, or Intel's v86 mode, but I thought that half the stuff was actually virtualized when running a DOS program under Windows, so that the timer isn't the same timer that Windows uses. Maybe I'm wrong.

Be that right or wrong, I can say that my DOS game sets the timer to 600Hz, and like I said it runs fine under Win95 and real DOS.

If the only problem with bosjoh's suggestion is speed, then why don't you draw the image(s) to a video back surface and use page-flipping, which takes about 0% overhead.

I've never heard of a vsync interrupt, except on other systems like the Amiga. If there were such a thing, wouldn't it be used by everyone instead of manually polling for the vsync? Where did you see this info?

Rock

I've used also another method:
First call a mousexy function, then fill the pointer undermouse with 16x16 pixel data.
Plot the mousecursor, then plot the undermouse sprite over the mousecursor in the next loop.

You must have heard about installing a mouse interrupt handler under int 33h. I really don't recommend this since when I used that I'd got thrown out's without a reason.

Only 1 time the compiler gave a stack overflow error.

Rock: timer is a chipset placed on your motherboard. It can't work different for Windows and for V86.

Drawing directly to back video surface is very slow, especially if you drawing transparent surfaces.

bosjoh: i've seen an article somewere, where were described how to write your own mouse handler (i.e. catch hardware interrupts from mouse by yourself). If i remember currectly, it was on http://www.wotsit.org/ under hardware section.

Ok guys, thanx for your responses, i think i've found solution (specific, and for my need only, based on bosjoh's idea). I'll draw mouse cursor when PageFlip() function will be called. This way i can handle back and double buffers flipping.

I think i've found solution for my need.

------------------
FlyFire/CodeX
http://codexorg.webjump.com

I want to write a mouse handler, and i need to make a function that will be synhronized with VSync to draw mouse cursor. It will be implemented like in this way:
void MouseHandler() {
...
RequestSpriteDraw(x,y,sprite)
}
Now i need to make that function. I think i can do this in two ways:
1) Just wait for vertical retrace, draw sprite and then exit.
2) Hang on INT8 (systme timer) and reprogram it for needed frequency (synhronize it with VSync) The only problem is that it won't work under Windows (W. doesn't like when somebody reprogram timer )

Is there any other ways or ideas?

Thanx

------------------
FlyFire/CodeX
http://codexorg.webjump.com

(I'm getting off topic here, but 1 more comment). I realize there is only 1 physical timer chip, but that doesn't mean that Window's is going to give you access to it. The OS CAN tell the cpu to block in/out instructions, so even though a DOS program tries to reprogram the timer, it doesn't actually make it to the physical timer chip. Same thing with interrupts. Window's may be feeding the DOS program some sort of software generated interrupts based on the real timer that it is using. I don't know if Window's actually does this or not, but I would be surprised if Win95 didn't, and EXTREMELY surprised if NT and OS2 didn't, which generally don't give any programs access to the hardware.

My DOS timer will run up to around 100KHz under true DOS 6.22, but only about 1Khz under Win95, and not reliably at all under NT. Obviously something is going on in those environments.

Rock