jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) (07/03/89)
I wrote a little hack (for viewing GIF files) that keeps a large image in memory, and bitblt's portions of it to the real screen memory. Which part of the image gets blt'ed depends on mouse coordinates, ie by waving the mouse around, you can move the screen around on the image. All this stuff works fine, but for one problem: there's a fair amount of hash displayed while the image is moving. Needless to say, it's somewhat difficult to see exactly what's hashed, as it flickers quite a bit; my uncalibrated eyeballs tell me it persists for no more than one scan of the screen, but that might not be right. The size of the transfer is screen-size; ie 320 * 200 * 4 bits, or 32000 bytes. I'm running on a Mega-4, with a blitter. I expected the blitter to be able to do things faster than it appears to be doing; even assuming that it's only doing 16 bits at a time, and that each 16-bit thing takes 250 nanosec (125 for read and 125 for write), that's still only .008 seconds, considerably less than one screen refresh time. I've tried sticking Vsync()'s in strategic places, but it seems to make no difference. What am I missing? Am I assuming that the blitter's faster than it is? Is my arithmetic off? Does Vsync not do what I thought it did? Is there something else going on that I don't know about? Any ideas/hints appreciated.
soohoo@cory.Berkeley.EDU (Ken "Bezier" Soohoo) (07/03/89)
In article <19890702230805.1.JRD@MOA.SCRC.Symbolics.COM> jrd@STONY-BROOK.SCRC.SYMBOLICS.COM (John R. Dunning) writes: >I wrote a little hack (for viewing GIF files) that keeps a large image >in memory, and bitblt's portions of it to the real screen memory. Which >part of the image gets blt'ed depends on mouse coordinates, ie by waving >the mouse around, you can move the screen around on the image. All this >stuff works fine, but for one problem: there's a fair amount of hash >displayed while the image is moving. > {Calculations deleted, he's using a blitter} Ok, here's the easiest way to get no-flicker image movement on an ST with or without a BLiTTER... Reserve two areas in memory the size of the screen. Show one area of memory while blitting into the other. Once the blit is done, change the physical base of the screen so that the _next_ time the screen redraws, it will draw itself from the new location. Now, be sure that when you change the screen's physical base, you change it in a non- critical area (specifically, don't be writing the register when the shifter is reading it -- so use Vsync(), or stuff into a page 4 location)... Now, one problem -- the blitter works alone, and so if you perform a blit using GEM, you'll return _real_ quick... Thus you've got to wait for the blitter to finish before you flip screens... Hope this helps... ;-) --Kenneth "kens" Soohoo (soohoo@cory.Berkeley.Edu) Atari Hacker (Atari's Hacker...) "It could be worse, you could get hit by a bus..." My opinions are my OWN, _not_ necessarily Atari's. But "hey", who knows?