jtt@cunixd.cc.columbia.edu (James T. Tanis) (09/28/90)
I'm trying to speed up some animation I'm doing, and thought it would be a really neat idea to swap in from an offscreen buffer. Too bad the tech notes say that this does not speed things up. Ah, the joys of a graphics machine... :-) So, then I tried to set the bits in thePort->portBits directly, resulting in improved performance and a spectacular crash... Does anybody have a good solution to this sort of thing? -JT
deadman@garnet.berkeley.edu (Ben Haller) (09/29/90)
In message <1990Sep28.073335.30984@cunixf.cc.columbia.edu>, jtt@cunixd.cc.columbia.edu (James T. Tanis) asks: > I'm trying to speed up some animation I'm doing, and thought it would be a > really neat idea to swap in from an offscreen buffer. Too bad the tech > notes say that this does not speed things up. Ah, the joys of a graphics > machine... :-) Since when is the Mac a graphics machine? Just because it has graphics, doesn't make it a *graphics machine*... Myself, I see a graphics machine as a machine with a graphics coprocessor at the very least. > So, then I tried to set the bits in thePort->portBits directly, resulting > in improved performance and a spectacular crash... > Does anybody have a good solution to this sort of thing? Hmm. Well, Solarian II sets the video buffer directly, and after several new versions (1.01 for the IIci, 1.03 for 24-bit boards) I seem to have gotten it right. It's rather tricky. You should think seriously about it first, since it limits you do a single bit depth unless you special- case for different depths, and it won't be much faster (if at all) than CopyBits unless you write it all in assembler (all of the display routines, not all of your program...) But assuming you really want to do this, the steps to take are: 1. Search for a monitor in the bit depth you need 1b. If not found, exit gracefully 2. Figure out the coordinate system of that monitor, i.e. rowBytes, physical width and height, base address. 3. Figure out if you need to switch the processor into 32-bit mode to write to the monitor (you can do this using 32-bit QuickDraw calls. If 32-BCQD isn't present you know you can stay in 24-bit mode). 4. Calculate the address of the start of the block you want to write 5. Switch into 32-bit mode if necessary 6. Start writing, being careful not to draw off the screen boundaries 7. Switch back to 24-bit mode This really isn't that simple, but it's not impossible, as Solarian II shows. It just takes a lot of trial and error. Things to make it faster: 1. Write as much data as you can at one time 2. Have one routine that clips to screen boundaries that you only use for sprites that may need clipping, and another routine that does no checking at all for most of your sprites, which will be onscreen all the time. 3. Write as big a chunk as you can at once. In other words, write out long words, not bytes. This depends on what processors to want to run on, since earlier ones are dependant on word and longword writes falling on word boundaries 4. Fall on word boundaries anyway, it's much faster. 5. Obviously do a color translation beforehand if necessary, don't do it on the fly. There are lots more optimizations you can make, but they aren't all really necessary. Solarian II could probably be more optimized than it is... keep in mind the limits of the machine, though. A IIcx can't blit a full-screen image from an offscreen buffer to on-screen in less than 2-3 60ths of a second (in 8-bit mode), so moving-backdrop games in 8-bit color are simply not currently possible. And keep in mind that on machines with one of Apple's QuickDraw accelerators, the *most* optimized blit you can write may be considerably slower than CopyBits would be. Hmm. I hope that was all clear. If enough people are very interested I could probably spout more on this subject. :-> -Ben Haller (deadman@garnet.berkeley.edu)
mxmora@unix.SRI.COM (Matt Mora) (09/29/90)
In article <1990Sep28.171750.17381@agate.berkeley.edu> deadman@garnet.berkeley.edu (Ben Haller) writes: > Hmm. I hope that was all clear. If enough people are very interested I >could probably spout more on this subject. :-> > >-Ben Haller (deadman@garnet.berkeley.edu) I would love to hear more. I tried your game and was totally impressed. I don't play games on the mac because I play the ultimate game,programming the Mac. I going to send you the shareware fee even though I don't use your game just because I think you deserve it. And I would love to see you write more things for the Mac. One thing you should check for is MaxAppleZoom. But I guess you program has enough specail case code in it already :-). I sure would like to see some of your blitting code & would really like to get it into the UMPG. Thanks for writing such a beautiful game. -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@sri.com SRI International | my unix mxmora@unix.sri.com ___________________________________________________________
jtt@cunixd.cc.columbia.edu (James T. Tanis) (10/01/90)
In article <16663@unix.SRI.COM> mxmora@unix.UUCP (Matt Mora) writes: >In article <1990Sep28.171750.17381@agate.berkeley.edu> deadman@garnet.berkeley.edu (Ben Haller) writes: > >> Hmm. I hope that was all clear. If enough people are very interested I >>could probably spout more on this subject. :-> >> >>-Ben Haller (deadman@garnet.berkeley.edu) > > > > >I sure would like to see some of your blitting code Me too! -JT