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.