🚀 go-pugleaf

In article <1992Sep25.070335.20349@news.ysu.edu> af458@yfn.ysu.edu (Jon K. Salmon) writes:
>From: af458@yfn.ysu.edu (Jon K. Salmon)
>Subject: Re: Flicker on vga animation
>Date: Fri, 25 Sep 1992 07:03:35 GMT
>
>mortenk@dhhalden.no (MORTEN KNUDSEN) writes:
>
>> The other day i made an animation (in assembler), a bouncing ball.
>> It works fine, exept that it flickers . I suspect that the
>> VGA's retrayce is the cause of this. I tried hooking the IRQ9 (EGA
>> vertical retrayce), but it doesn't interrupt.
>
>Does your animation method follow this basic algorithm?
>
>  do
>    draw the ball
>    erase the ball
>    adjust the position
>  loop
>
>If so, and given that the ball is bigger than one pixel in size and
>that two successive drawings of the ball overlap, the flicker is
>inherent in the algorithm and can be eliminated by a) page flipping,
>b) syncronization with the vertical retrace, or c) changing the
>algoritm.
>
>a) Whether or not you can flip pages is video-mode-dependent.  For
>example, as far as I know, mode 13h does not support page-flipping
>as it does not have multiple pages.
>
>b) While VGA does not seem to support the vertical blank interrupt,
>you CAN check certain registers as it DOES set a bit when it is
>in a vertical retrace.
>
>c) You could try an algorithm which, instead of erasing the entire
>ball, ERASES only those pixels which will be "off" when the ball
>is next drawn.  And, optionally, only DRAW those pixels which are
>not already set.  Follow me?
>
>-- Jon
>-- 

Yes, my animation method algorithm is exactly like you discrimed, and I am
using mode 13h. I tried checking the status register (I think it was reg. 
3DAh, bit 0) but I still got the flicker. The checking routine looks
something like this:

		MOV DX,3DAH
TRACING:	IN AL,DX
		TEST AL,1
		JNE TRACING
; DRAWING GOES HERE

What am I doing wrong?