"Robert_L._White.ESXC15"@XEROX.COM (08/31/88)
I have been playing around with graphics lately and have some questions about animation. Someone tell me if I am figuring this out right. Since the screen is redrawn every 60th of a second, and I was to move a Line A sprite 1 pixel at a time, this would give me a movement of 60 pixels per second, right? Thus it would take about 5.3 seconds to move accross a low resolution screen, Right??? My question here is, How do I make the sprite move faster than 60 pixels per second? Is it possible? I have tried moving the sprite 2 pixels at a time, But then the sprite seems to be a little jirky or blurry. I have looked at some games, and some of them seem to be able to move images faster than this without the blurr. How do they do it? What are some of the tricks? The way I am doing my animation is this. I am using 3 screens. One holds the background picture, one is the drawing screen (LOG BASE), and one is the screen being viewed (PHYS BASE). For 1 animation sequence I copy the background screen to the LOG BASE screen, then draw my sprite to the LOG BASE screen, Then do a SETSCREEN to swap the PHYS BASE screen with the LOG BASE screen. Thus the old PHYS BASE screen becomes the new LOG BASE screen and the old LOG BASE screen becomes the new PHYS BASE screen. This is then repeated every vertical blank, and every thing works great, with no flicker (at 1 pixel per Vertical blank). I am writing my code in 'C' and assembly. The background screen copy routine is in assembly (for speed), and the rest is in 'C'. I am pretty sure I am doing all my animation before the Vertical blank, and am executing the SETSCREEN command every vertical blank, (60 setscreens per second). I have verified this because I seem to be able to move 60 pixels per second. If anyone can give me some tips on how to move a sprite faster, it would be appreciated. Thanks, Robert L. White, Xerox Corp.
leo@philmds.UUCP (Leo de Wit) (09/04/88)
In article <880831-204234-3799@Xerox> "Robert_L._White.ESXC15"@XEROX.COM writes: [some lines deleted]... |The way I am doing my animation is this. I am using 3 screens. One holds the |background picture, one is the drawing screen (LOG BASE), and one is the |screen being viewed (PHYS BASE). |For 1 animation sequence I copy the background screen to the LOG BASE |screen, then draw my sprite to the LOG BASE screen, Then do a |SETSCREEN to swap the PHYS BASE screen with the LOG BASE screen. |Thus the old PHYS BASE screen becomes the new LOG BASE screen and the old LOG |BASE screen becomes the new PHYS BASE screen. |This is then repeated every vertical blank, and every thing works great, |with no flicker (at 1 pixel per Vertical blank). How do you know it is repeated every vbl? Do you use a vbl routine to achieve this? I've got a copy of the book '3D Grafik Programmierung' from Data Becker. It suggests that SETSCREEN swaps at vbl time. ***THIS IS NOT TRUE!!!*** (maybe you got the same impression). SETSCREEN does not wait for vbl to set the screen(s); only if you also change the resolution it will wait for vbl. There's another 'know-it' about vbl: You *CAN* set the screen at vbl time; this however sets logical and physical screen to the same value (not suitable for your application). The way to do this is: enter the new screen base into the system variable screenpt ($45e). At vbl time the screens will be set then (I think you have to refill it with 0 to avoid having it set all the time). |I am writing my code in 'C' and assembly. The background screen copy |routine is in assembly (for speed), and the rest is in 'C'. I am pretty sure I |am doing all my animation before the Vertical blank, and am executing the |SETSCREEN command every vertical blank, (60 setscreens per second). |I have verified this because I seem to be able to move 60 pixels per second. |If anyone can give me some tips on how to move a sprite faster, it would |be appreciated. |Thanks, |Robert L. White, Xerox Corp. The jerkyness could possibly be caused by the copying of a background screen. This seems quite a time-comsuming operation. I don't see the use of it. I thought for a sprite you'd only have to save the screen contents it is going to occupy, so that when it moves you can restore this little piece, then redraw the sprite. But I'm not an expert on sprites... Leo.
soohoo@cory.Berkeley.EDU (Ken Soohoo) (09/06/88)
In article <880831-204234-3799@Xerox> "Robert_L._White.ESXC15"@XEROX.COM writes: [intro deleted] >My question here is, How do I make the sprite move faster than 60 pixels >per second? Is it possible? I have tried moving the sprite 2 pixels at a time, > >The way I am doing my animation is this. I am using 3 screens. One holds the >background picture, one is the drawing screen (LOG BASE), and one is the >screen being viewed (PHYS BASE). >For 1 animation sequence I copy the background screen to the LOG BASE >screen, then draw my sprite to the LOG BASE screen, Then do a [more deleted] >Thanks, >Robert L. White, Xerox Corp. You don't need to re-copy the background screen into the logical screen each time you draw a new frame, this takes a HUGE amount of time. All you 've got to do is copy the section of the screen that the sprite occupied in the previous version of the logical screen. How about an example: Show page 2 (Physbase = page 2, Logbase = page 1) Frame 1: x1 = 50, y1 = 50; x2 = 50, y2 = 50 x = 50, y = 50 Copy the area from your background at x1, y1 to page 1 Move sprite to 55, 55 (x=55, y=55) Draw sprite at x, y in page 1 Set x1 = x, y1 = y Now show page 1 (Physbase = page 1, Logbase = page 2) Frame 2: x1 = 55, y1 = 55; x2 = 50, y2 = 50 x = 55, y = 55 Copy the area from your background at x2, y2 to page 2 Move the sprite to 60, 60 (x=60, y=60) Draw sprite at x, y at page 2 Set x2 = x, y2 = y GOTO Frame 1 I've found this to be a fairly quick solution to sprites in software, but feel free to mail me with more questions (specifics). Kenneth Soohoo soohoo@cory.Berkeley.Edu --Ken Soohoo Atari 400/800/600xl/800xl/1200/130xe/65xe freelance gamer Atari 1040ST hacker Sometime Berkeley Student
"Robert_L._White.ESXC15"@XEROX.COM (09/23/88)
Thanks to all who answered my Animation Questions. Much thanks to David M. Baggett who explained that the blurr I was getting was in actuality strobing. However I am now very confused about Leo De Wit's reply Re; the SetScreen command >I've got a copy of the book '3D Grafik Programmierung' from Data Becker. >It suggests that SETSCREEN swaps at vbl time. ***THIS IS NOT TRUE!!!*** >(maybe you got the same impression). 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? 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? Also, David M. Baggett said there was a Animation Demo in the ARCHIVES. I would love to get this david! I do not have access to these archives, the only thing I seem to have access to is a LIST SERVER in CANADA. I am on a XEROX ETHERNET account and am not very firmiliar with GATE WAYS. Is there some way I can get at the archives? BTW I do not have any way of using a FTP program eather. Perhaps some kind soul could mail it to me! Thanks to all Robert L. White.
leo@philmds.UUCP (Leo de Wit) (09/24/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.