🚀 go-pugleaf

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.