dtt@unirot.UUCP (David Temkin) (06/27/86)
I've just started writing an arcade-style game in Lightspeed C and there are a few problems which I'd like to clear up before moving on. 1) How do you make sure the memory for the alternate screen buffer isn't used for something other than a display? 2) How do you tell Quickdraw to start drawing on the alternate screen buffer? How do you switch back to the main buffer? 3) How do you make the video display hardware display the alternate screen buffer? How can you make it do this during a vertical blank? 4) Is there a global variable I can access that holds the address of the alternate screen buffer so that the program will run on the Mac 128, 512, and Mac Plus? I realize that screen flipping is not a 100% Apple-approved animation technique (and it won't run on the Lisa), but it does provide the highest quality animation possible. On a separate matter, has anybody found Quickdraw to be too slow for putting down simple rectangular bit images in animation? In particular, has anyone tried preshifted shapes (this is the old Apple II technique where each shape is stored seven times - eight for the Mac - so that no "bit shifting" is done when the image is put on the screen - instead, each shape is always available in all possible bit alignments)? Is the speed gain worth writing the assembly code it needs? Any help would be greatly appreciated. David Temkin ( ...topaz!unipress!dt)
ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459) (06/30/86)
> I've just started writing an arcade-style game in Lightspeed C and > there are a few problems which I'd like to clear up before moving on. > > 1) How do you make sure the memory for the alternate screen buffer isn't > used for something other than a display? BufPtr points to the top of available memory. You have to re-launch yourself to get the alternate screen setup. So: at first launch, check that BufPtr points *above* the alternate screen. At re-launch, check that it points *below* the alternate screen. This should guarantee that the screen was available and is now yours. > 3) How do you make the video display hardware display the alternate > screen buffer? How can you make it do this during a vertical blank? Twiddle some hardware bits to switch screens; see the Hardware chapter of the Addison-Wesley Inside Mac. To hit the vertical blanking interval, just wait for the Ticks counter to change. > 4) Is there a global variable I can access that holds the address of > the alternate screen buffer so that the program will run on the Mac > 128, 512, and Mac Plus? I'm not positive, but I think that the screen pointer global will point to the alternate screen if you launch yourself with the alternate screen configuration. For the existing Macs, it's sufficient to use fixed screen addresses assuming 4Meg of memory. Wrap-around takes care of smaller memory sizes. This technique will drop dead as soon as Apple comes out with a Mac with a different-sized screen. > I realize that screen flipping is not a 100% Apple-approved animation > technique (and it won't run on the Lisa), but it does provide the > highest quality animation possible. Apple suggests: draw into an off-screen bitmap, wait for the clock to tick, then _BlockMove the changes onto the screen. If your changes are organized from top to bottom, you don't have to finish during the vertical retrace, you just have to keep ahead of the current scan line.
mlr0@bunny.UUCP (Martin Resnick) (07/02/86)
> I've just started writing an arcade-style game in Lightspeed C and > there are a few problems which I'd like to clear up before moving on. > > 1) How do you make sure the memory for the alternate screen buffer isn't > used for something other than a display? > 2) How do you tell Quickdraw to start drawing on the alternate screen > buffer? How do you switch back to the main buffer? > 3) How do you make the video display hardware display the alternate > screen buffer? How can you make it do this during a vertical blank? > 4) Is there a global variable I can access that holds the address of > the alternate screen buffer so that the program will run on the Mac > 128, 512, and Mac Plus? > > I realize that screen flipping is not a 100% Apple-approved animation > technique (and it won't run on the Lisa), but it does provide the > highest quality animation possible. > > On a separate matter, has anybody found Quickdraw to be too slow for > putting down simple rectangular bit images in animation? In particular, > has anyone tried preshifted shapes (this is the old Apple II technique > where each shape is stored seven times - eight for the Mac - so > that no "bit shifting" is done when the image is put on the screen - > instead, each shape is always available in all possible bit > alignments)? Is the speed gain worth writing the assembly code it > needs? > From a friend of a friend: David -- I spent some time recently working on an animation program which dealt with a lot of the issues you asked about. (It's "Vanlandingham", the Mac parody of Amiga's "boing" -- available on some nets and through the Boston Computer Society). A lot of the answers to your questions are covered in an article in the June '86 MacTutor on "Screen-switching animation". Some more details, not quite in order of your questions: (1) In theory, the Launch trap allows your invoker (eg, the Finder) to ask for you to get the second screen. So, you can wake up, see if you have the screen allocated, and re-Launch yourself if you don't. Unfortunately, things like RAM disks, debuggers, and the damned Mac Plus RAM cache seem to reside in this area, but don't prevent the Launch code from promising you the second screen. Apparently the global variable BufPtr can give you a clue about whether this area is actually in use. I'm not sure how to do this, so Vanlandingham crashes in some cases. Sorry. (4) In all existing Macs, the alternate buffer is 32K bytes below the main screen. Of course, if a Mac with a larger screen comes out, they'll have to be farther apart. (2) It's possible to switch screens by using two grafPorts, but I use just one and switch the bitmaps with SetPortBits. The standard screen is described by the bitmap screenBits, so you can say something like (pardon my Pascal): var altBits: bitmap; ... altBits := screenBits; /* alternate screen's bitmap is almost same... */ altBits.baseaddr := screenbits.baseaddr - 32768; /* ...but lower */ ... SetPortBits (altBits); /* do all drawing in the alternate screen */ ... SetPortBits (screenBits); /* do all drawing on the main screen */ I suspect SetPortBits is faster than SetPort, but I don't know. (3) You control the screen hardware through the VIA; the article covers this. Yes, Quickdraw is very slow. Vanlandingham has 16 or 32 (I can never remember) preshifted shapes. Even if you keep using Quickdraw, keeping the stuff aligned will save some time. Remember that when you clean up a screen (copy from a pure background to erase an old image), you can round the copy out to the next word (or longword) boundary on either side, and your erase code can run much faster -- although it's copying a little more data, it doesn't have to worry about left and right boundaries. Yes, assembly language is worth it. Vanlandingham does a good imitation of the Amiga's bouncing ball, including drawing the ball to scale on the screen. Using Quickdraw, the ball would have been about the size of a quarter, or else the animation would have had to be much slower than 60Hz. I found it easy to prototype with Quickdraw, but needed assembler in the end. Have fun! The best way to reach me is via US Snail at: Mike Morton / Lotus / 161 First Street / Cambridge, MA 02142 -- Mike Morton