mlab2@kuhub.cc.ukans.edu (01/12/91)
> Currently, the drawing occurs too slowly for even ONE object to be flicker > free. I have looked at the PICT resources of several popular mac games, and > they all contain color PixMaps and b/w BitMap masks, which leads me to believe > that they also use CopyMask to do their drawing. Perhaps it's your drawing routine needs a few extra steps (I know, more steps means more time, but truly, it can cut down flicker). What I use was originally printed in MacTutor (sorry, old issue). For sake of speed and damned-be-memory, I do it like this: 1) Create 3 offscreen bitmaps (or pixmaps) when game begins - you maintain these throughout the play of the game and they (for convenience) are 512 x 342 (for my MacPlus screen). 2) One offscreen holds a 'virgin' copy of the background graphic (perhaps stars in your case although it can be as complex as you want it), one offscreen holds all 'objects' (rotated graphics of the ships and masks (for color the masks need to be in a seperate offscreen since they must be BITmaps not PIXmaps)) the third offscreen is a utility page used to 'assemble' the graphics before throwing to the screen. 3) Tediously, you should have calculated all bounding rects for locating your ship/mask graphics and have them available to your program. I use a large array, you could read in 'nrct' resources. Note: for speed, it has been pointed out that rectangles with widths falling on longword boudaries are best. Drawing goes like this: Keep a variable to hold the oldRect representing the ship on the screen. Move the ships rect according to your game 'physics'. UnionRect(oldRect, newRect, wholeRect) in order to find all the background both destroyed and newly tread upon by your ship. CopyBits this 'swatch' of background from your virgin offscreen to your 'assembly' offscreen. CopyMask your ship from it's source offscreen to rest upon the newly laid swatch. CopyBit your 'assembled' ship/background graphic to your ONscreen. Walla! In one user-visible call you erased the old and dropped the new ship in place. I've noticed that very tall objects can appear to flicker. As well, moving an object a large distance against a white background can cause the object to appear to 'split' across it's midsection. VBL synching could take care of that. (I tried a downhill sledding game but with the white snow large sledder kept coming apart at the waist). I know, it could be optimized more. john calhoun > The biggest opportunity I see to increase my speed is to arrange the > collections of object rotation depictions so that they are spaced at some > power of two. This might cut back on some multiplications which should add > some speed, but my question is > > A) Am I going about the drawing process in the proper (usual) fasion? > B) Does everyone else who does this use powers of two to space their > graphics when a lookup is necessary? (In other words, if you have > say, a spaceship with 20 different rotations, and you need to > select the proper one to display). > > Since I have the weekend free to work on > some code, prompt responses would be > warmly appreciated! > > > /-------------------------/----- You are a fluke of the universe. ---------/ > / Eric P. Moyer ;-o / You have no right to be here. / > / moyer@brahms.udel.edu / Whether you can hear it or not, / > /-------------------------/--- The universe is laughing behind your back. -/