Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!hp4nl!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.sys.atari.st
Subject: Re:  ANIMATION QUESTION
Keywords: Setscreen, physical/logical screen, animation, shifter, video counter
Message-ID: <819@philmds.UUCP>
Date: 24 Sep 88 09:15:21 GMT
References: <880922-104812-2583@Xerox>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 88

In article <880922-104812-2583@Xerox> "Robert_L._White.ESXC15"@XEROX.COM writes:
    [ ]...
>However I am now very confused about Leo De Wit's reply Re; the SetScreen
>command

Hope I can un-confuse you (defuse? refuse? 8-).
    [ ]...
>>                                     SETSCREEN does not wait for vbl
>>to set the screen(s); only if you also change the resolution it will wait
>>for vbl.
>
>If this where true, wouldnt I sometimes see the screen change in the middle of a
>screen draw, and get a noticable flicker on the screen?

Probably not. I'm not a ST hardware specialist, but changing the
physical screen address (by moving values into some I/O addresses) has
as effect that the start value of the video counter in the SHIFTER gets
changed, not the current value. Not until the next vbl the current
value of the video counter gets refilled with this start value. This
means that the effect of SETSCREEN (changing physical screen location
in this case) only takes place long after SETSCREEN has finished (that
is, if you find one-hundreds of seconds long 8-).  All this means
there's absolutely no need for SETSCREEN to wait. And so it doesn't.

There *IS* however a slight problem with this scheme. Consider the
following:
You use two screens, one to paint in (the 'logical' one), one to show
(the 'physical' one). Having created your image in the logical screen,
you swap the screens, using SETSCREEN. But, as stated above, the video
counter is still (until the next vbl) generating addresses for the old
physical screen; so reading is done from the new logical screen. If you
happen to update that part of the screen by using graphic functions
(they all use the logical screen) you may notice some flicker (I have
in some animation program of mine, using SETSCREEN). It all depends on
how fast, where and how you are updating things, and the difference
between the old and the new image.  If it is a real problem, you can do
two things:
    a) explicitly wait for a vbl; I wouldn't recommend it, since it may
slow things down too much for a real nice animation.
    b) use a circular buffer of screens, which you handle in the following
way: set the new logical screen to the next screen of the buffer, the
new physical screen to the old logical screen. The afore mentioned
problem can still appear if you're updating screens so fast that you
need all screens as a logical screen within two vbl's, in which case
you can consider adding another screen to the buffer or doing a) which
will take less time this time. However, I think a circular buffer of
three screens will suffice in most cases.

>I am using SetScreen and not waiting for the vertical blank, yet I do not see
>any screen flicker.  It sure seems that SetScreen does wait for the next VBL.
>
>Could ATARI shed some lite on this subject PLEASE?
>The Question is: Does SETSCREEN wait till the next VBL to change?

Maybe this small example program will convince you:

----------------- s t a r t s   h e r e ------------------
/* scrtest */
#include "osbind.h"

main(argc,argv)
int argc;
char **argv;
{
   int i;
   long scr;

   scr = Logbase();
   for (i = atoi(argv[1]); i > 0; --i) {
      Setscreen(scr,scr,-1);
   }
}
----------------- e n d s       h e r e ------------------

(b.t.w. you can also set the screen to a real different value, in case you
think this matters. It makes no difference).

Run it once with an argument of 0 (to measure the load time of the program).
Run it now with an argument of 6000; this executes in about 1 second longer
than the first time (medium resolution monitor).
Now if Setscreen waited for a vbl, this would mean there were 6000 vbl per
second, which is way off. An execution time of over a minute would have
been more appropriate.

B.T.W. this is not how I found this out; both looking into the ROM and the
old disk TOS revealed this. So it seems pretty well founded.

           Leo.