dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/04/86)
Well, you have to define what you mean by 'not change either image'. Firstly, if you assume that color 0 is transparent, then you want to blit only the parts of the source bitmap that have color > 0 (that is, a one bit on any of the bit planes for that pixel). For those pixels which do have color > 0, you want to overwrite ALL 4 planes for that pixel. If done Generically, this would take more than one blitter pass since the blitter has only three sources and one destination. -OR all four planes in the source together and place in a temporary bitmap resulting in a template. (This will take two blitter passes) -Do another FOUR blitter passes. Each pass uses plane X of the source, the template, and plane X of the destination. For Each pass, write the source (0 or 1) to the destination IFF the template is a 1. ---------------- If you are using source shapes which don't change, then the first part (generating the template) can be replaced by static data. If you don't want to set up the blit manually, a new 1.2 graphics call will blit from a source bitmap to a destination rastport through a template: BltMaskBitMapRastPort(srcbm, srcx, srcy, destrp, destx, desty, sizex, sizey, minterm, blitmask) (bltmask is a pointer to a SINGLE bit-plane mask, which must be the same size and dimensions as the planes of the source bitmap). -Matt
ee162faq@sdcc7.ucsd.EDU (JOHN SCHULTZ) (12/04/86)
'not changing either image' defined as not changing the colors of the top image from the original definition, transparent areas of top image not affecting background image. Anyway, doing multiple blits will definitely slow things down. I want to have the fastest frame-frame generation as possible. Therefore I am using a double-buffered display and SetRasting the whole screen to 0 each frame. The simulation has multiple particle explosions (AreaXXXX commands), particle beams (Move/Draw/SetDrPt), various onscreen information (Text,RectFill), and of course shapes defining the simulation (BltBitMap). The only time the colors change is when a jet is drawn on top of a carrier. The change is noticeable, but I do not think it would be worth the extra blits to make this one instance look correct. I have written all of my own routines/data structures for displaying and manipulating shapes and currently do not know if the "backup-copy-replace backup" method would run faster than simply blitting the entire screen. I feel that the neccessary code overhead and 68000 execution time could not surpass the single blitter operation (SetRast). Please correct me if I am wrong. I had one scheme set up with two viewports: the upper was lores x 2 bitplanes, (8 pixels high), and the lower lores x 4 bitplanes and double buffered. I had hoped that this method would run faster (use the top viewport for information, no need to remake each frame) and the bottom for animation. This scheme was quite a bit slower than a single db viewport. Why? (more work for the copper?) As for *any* new 1.2 routines, I'll have to wait until January when TDI releases their 1.2 update. And no, I would not want to rewrite the entire program in Aztec. Currently with 2 drives and 1024k I am just barely able to compile and link all of the modules neccessary to define this simulation in ram. I should have a release version of this simulation before Christmas, which takes advantage of all the above routines, all 4 audio channels, the narrator device, uses both game ports, one or two players. Ah yes, one last, pressing, legal question: What are the laws pertaining to using music / cuts from copyrighted sources (compact disk, etc) in video games (digitized from the source)? If illegal, I could always say the sound you just heard was generated using random number samples and I kept running the program until I heard a cut I liked... Thank you for your support. John
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/04/86)
Double buffering is nice, but either uses up half your planes or uses double the memory, depending on which method of double buffering you do. Let me explain the two methods: Method 1: Use half the planes for buffer 1, the other half for buffer 2. (Assume 4 planes total in this example) Double buffering is accomplished by setting the color palette such that the pixels in the 2 inactive planes do not effect the color displayed by the 2 active planes. To switch which 2 planes are active (make the 2 active planes inactive and the 2 inactive planes active), simply re-arrange the color palette. Advantages: Less memory Disadvantages: You are limited to half the number of planes on your screen for the actual game or simulation or whatever. Method 2: Have two entirely separate display bitmaps. (Assume four bit planes per bitmap on this example). Double buffering is accomplished by simply changing the planes pointers in the display to the second bitmap. Advantages: You have full use of all 4 bit planes Disadvantages: It takes double the memory. METHOD 1 METHOD 2 SCREEN MEMORY PLANES MEMORY PLANES 320x200x4 32K 2 64K 4 640x200x2 32K 1 64K 2 640x200x4 64K 2 128K 4 640x400x4 128K 2 256K 4 (Where PLANES is planes available for the application) (note: Method 2 on interlace screens may be difficult) As you can see, a 320x200x4 plane double buffered display using method 2 uses only 64K, which seems reasonable. Additionaly, you get 4 usable bit planes to play around with. So, for instance, if you are blitting a Jet on top of Carrier, you can simply put the Carrier in plane 0 and the jet in plane 1 (assuming mono colored objects). Only one blit need be done, and since the objects are on different planes, they don't destructively modify each other. You can setup the color registers to effectively prioritize the bitplanes. Priority Example: 2 bit planes Object A in plane 0 Object B in plane 1 You want object B to have priority over object A plane0 plane1 COLOR Color Reg 0 0 0 BACKGROUND Color Reg 1 1 0 OBJECT A's color Color Reg 2 0 1 OBJECT B's color Color Reg 3 1 1 OBJECT B's color (B has priority) 4 bit planes, 4 objects Object A in plane 0 Object B in plane 1 Object C in plane 2 Object D in plane 3 D over C over B over A bits set in planes plane0 plane1 plane2 plane3 COLOR Color Reg 0 0 0 0 0 BACKGROUND Color Reg 1 1 0 0 0 OBJECT A Color Reg 2 0 1 0 0 OBJECT B Color Reg 3 1 1 0 0 OBJECT B Color Reg 4 0 0 1 0 OBJECT C Color Reg 5 1 0 1 0 OBJECT C Color Reg 6 0 1 1 0 OBJECT C Color Reg 7 1 1 1 0 OBJECT C Color Reg 8 0 0 0 1 OBJECT D Color Reg 9 1 0 0 1 OBJECT D Color Reg 10 0 1 0 1 OBJECT D Color Reg 11 1 1 0 1 OBJECT D Color Reg 12 0 0 1 1 OBJECT D Color Reg 13 1 0 1 1 OBJECT D Color Reg 14 0 1 1 1 OBJECT D Color Reg 15 1 1 1 1 OBJECT D example comments: Color 15 = all four objects overlapping at this pixel Color 9 = Objects A and D overlapping at this pixel etc... Usually, you can arrange it so no complex blitting is required, causing your game/simulation to screeeeeeammm. Generally, the more colors per object, the more blitting required. Additionaly, since these are custom screens with little chance of intuition screwing things up, so you don't need a ClipRect in your RastPort structures (remember however that this means you absolutely cannot specify anything out of bounds). It makes graphics calls go much faster. Finally, you can control the blitter manually... Via OwnBlitter(), and optimize. The neat thing is you can do all of this without compromising the Amiga's multi-tasking. -Matt
ee162faq@sdcc7.ucsd.EDU (JOHN SCHULTZ) (12/06/86)
Currently I am just doing one blit per image (shape) update. So, you are saying that it would be faster to set the MASK variable to allow only certain planes to be affected (copied to), say 2 bitplane blits as opposed to 4? (obviously twice as fast). Yet you must also set up the colors in the shapes so the blit will look correct (?). Currently, the simulation runs so fast that I had to slow down the relative velocities of the jets (but slows down quite a bit in higher levels when many items are being processed). Using the techniques mentioned, would the user be able to notice any increase in performance? Yeah, I'm not using ClipRect. Neat things happen when the blitter is lead astray... (like permanently losing the display [nothing, black] until rebooting (had a 1 pixel bug in my clip routine, and that's all it takes). All of my shapes were drawn using "dpaint lo 4" and loaded into their respective bitmaps. The colormap for the Viewport is obtained from the last shape read in, and converted from RGB into colortable entries. So, what would be neccessary to try "Method 2" given the above scenario? Draw, for example, the US Jet in only colors 1-7, and the Libyan Jet in 8-15? Or does it require tedious (simple?) bit-bit calculations and spurious color usage? I've tried using Forbid to speed up processing but the narrator runs as a seperate task... (could Permit before a call...) I've noticed a few benchmarks posted; does Forbid speed up a given task significantly? Finally, define "customize"... I haven't studied OwnBlitter, can I just call OwnBlitter when the simulation starts, then DisownBlitter when done? Just looked it up. More to it than that. Is the trouble (code time) worth the extra effort? If you think the RKM is short on examples, (that actually work) you won't believe the spartan examples supplied with m2 documentation (none are supplied showing lower level function, like blitter manipulation, etc). Guess I came out ahead, though, because now transfering from C to m2 is fairly simple. Thanks again for your support. John 7OHN
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/07/86)
Are you sure your using just one blit? Note that one graphics call does not constitute one blit... It all depends on the number of planes in your source image. If your source image has 4 planes, then that one graphics call is going to do at least 4 blits. Additionaly, each blit pass may have more than one source ... in fact, up to three. For instance, if you are blitting a 4 plane source image to a destination through a mask, each of the 4 blitter passes will have 2 sources and one destination (you can only have one destination). It all boils down to how many colors you want in your source image. If it's only one color, you can define it in only one plane. If its 2 to 4 colors, it takes two planes. This has nothing to do with the number of planes on the screen (assuming there are enough). As an ending note: Sometimes you can forget the mask by putting the background in one plane and the animation on another. -Matt
ee162faq@sdcc7.ucsd.EDU (Back Here) (12/09/86)
As stated earlier, I am using BltBitMap, which returns the
number of planes involved in a blit. Since I am using a 4
plane source/dest, apparently I am actually doing 4 blits.
So, back to my original question, using BltBitMap with 4
planes source/dest, what procedure is neccessary to get the
desired affect (not altering the higher priority image).
For example, what colors sets would have to be used where,
etc. (you stated a general description earlier).
thanks again for your support.
John
7OHNdillon@CORY.BERKELEY.EDU (Matt Dillon) (12/09/86)
> As stated earlier, I am using BltBitMap, which returns the > number of planes involved in a blit. Since I am using a 4 > plane source/dest, apparently I am actually doing 4 blits. > > So, back to my original question, using BltBitMap with 4 > planes source/dest, what procedure is neccessary to get the > desired affect (not altering the higher priority image). > For example, what colors sets would have to be used where, > etc. (you stated a general description earlier). > > thanks again for your support. > > > John > 7OHN You have got to define what "Higher Priority" means. I think this is why we have had so much trouble trying to answer your question. I think we've got the graphics situation straight... your blitting a 4plane image onto a 4plane screen. So, on a pixel by pixel basis, what constitutes 'higher' priority?? -Matt
ee162faq@sdcc7.UUCP (12/09/86)
Re: Higher priority. Def: The later an image is drawn, the higher the priorty. For example, the first call to BltBitMap draws the Carrier onto the transparent background. (image looks as defined in dpaint). Next, a Jet is drawn on top of the Carrier. So the Jet appears to be on the deck of the Carrier (has the higher priority, because we *see* it *on_top_of* all other images. Simply, the the last image drawn has the highest priority.) Now, wherever the Jet image is defined as other then transparent, its colors are changed when drawn on top of the Carrier. Actually, as I think about it, no priority is taking place other than conceptually. From the facts you have stated in the past, it would appear that altering when an image is drawn will just change the way the pixel color defintions are modified. So, from what you have said, the only way to get *real* priority is to blit into seperate planes.(?) it's getting late, ah, 5:08 am. need to put in some dream time... thanks once again for all the support. John 7OHN