phi@goanna.cs.rmit.oz.au (Philip Hingston) (05/26/90)
I need a blit where the source overrides the destination except where the source has colour 0, when the destination show through. Is there a blit for this or must I make my own? Thanks. phi -- Philip Hingston, Computer Science,ACSnet: phi@goanna.cs.rmit.oz R.M.I.T. ARPA: phi%goanna.cs.rmit.oz.au@uunet.uu.net GPO BOX 2476 V, CSNET: phi%goanna.cs.rmit.oz.au@australia Melbourne, 3001, AUSTRALIA UUCP: ...!uunet!goanna.cs.rmit.oz.au!phi
pfalstad@phoenix.Princeton.EDU (Paul John Falstad) (05/29/90)
In article <3074@goanna.cs.rmit.oz.au> you write: >I need a blit where the source overrides the destination except where the >source has colour 0, when the destination show through. Is there a blit for >this or must I make my own? Thanks. phi In order to do this, you have to make a mask for the source. Allocate one bitplane the size of the source, clear it, and blit all the bitplanes of the source onto it separately using a D=A+B minterm (0xFC), where A = the source bitplane, B = D = the mask. This is assuming your source is more than one bitplane, of course. Then, you can do what you want with a cookie cut, D = AB + nAC (0xCA), where A is the mask, B is the source, and C = D = the destination. Or you could just use a bob. :-) Though I've had problems with those. They also require you to make a mask. Accessing the blitter directly is more fun anyway. -- Paul Falstad PLINK:Hypnos GEnie:P.FALSTAD net:pfalstad@phoenix.princeton.edu Disclaimer: My opinions, which belong to me and which I own, are mine. -Anne Elk (not AN elk!) The sun never set on the British empire because the British empire was in the East and the sun sets in the West.
jms@tardis.Tymnet.COM (Joe Smith) (05/29/90)
In article <3074@goanna.cs.rmit.oz.au> phi@goanna.cs.rmit.oz.au (Philip Hingston) writes: >I need a blit where the source overrides the destination except where the >source has colour 0, when the destination show through. Is there a blit for >this or must I make my own? Thanks. phi Tom Rokicki will probably provide more info on this subject. Since the blitter operates as "dest=function_of(dest,source,mask)", you will have to first calculate the mask which indicates where the color_0 pixels are located in the source. For instance: mask = all zeros for 2 bit-planes at a time do mask = mask OR plane1 OR plane2 endfor (mask now has 0 where ever the source is color_0) dest = (dest AND NOT mask) or (source AND mask) -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C41 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P," San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
dale@cbmvax.commodore.com (Dale Luck - Amiga) (05/30/90)
>In article phi@goanna.cs.rmit.oz.au (Philip Hingston) writes: >>I need a blit where the source overrides the destination except where the >>source has colour 0, when the destination show through. Is there a blit for >>this or must I make my own? Thanks. phi After constructing the 1 bitplane mask in a separate bitmap via blitter logical functions joining the planes together you can use BltPattern to do the rest. This is how the FloodFill routines in the amiga work. Dale
jcs@crash.cts.com (John Schultz) (05/30/90)
In article <16816@phoenix.Princeton.EDU> pfalstad@phoenix.Princeton.EDU (Paul John Falstad) writes: [stuff deleted] > >Or you could just use a bob. :-) Though I've had problems with those. >They also require you to make a mask. Accessing the blitter directly is >more fun anyway. Plus, it's much faster. With 25 mhz 030s (GVP, A3000s), you can beat the blitter using the processor for lines and polygon fills (30% and 100% faster, respectively). A3000s are even faster if you use 32 bit writes to chip ram. I achieved a 25% improvement on the A3000 over the A2000 w/030. I haven't tried comparing 32 bit block copies against the blitter, perhaps someone out there has... John
p554mve@mpirbn.UUCP (Michael van Elst) (06/02/90)
In article <2888@crash.cts.com> jcs@crash.cts.com (John Schultz) writes: > Plus, it's much faster. With 25 mhz 030s (GVP, A3000s), you can beat >the blitter using the processor for lines and polygon fills (30% and 100% >faster, respectively). A3000s are even faster if you use 32 bit writes >to chip ram. I achieved a 25% improvement on the A3000 over the A2000 w/030. >I haven't tried comparing 32 bit block copies against the blitter, perhaps >someone out there has... Howl, howl. This is a tight point of view ignoring that blitter operation is _parallel_ to cpu operation. The blitter can fill screens fast enough. You can't go faster than the display refresh rate. There's absolutely NO need to do operations with the CPU that can be done with the blitter. -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
jcs@crash.cts.com (John Schultz) (06/03/90)
In article <1032@mpirbn.UUCP> p554mve@mpirbn.UUCP (Michael van Elst) writes: [stuff deleted] >Howl, howl. This is a tight point of view ignoring that blitter operation >is _parallel_ to cpu operation. > >The blitter can fill screens fast enough. You can't go faster than the >display refresh rate. There's absolutely NO need to do operations with >the CPU that can be done with the blitter. I've done extensive benchmarks/speed tests, and the parallelism of the blitter does not make up for its slow speed relative to a fast 32 bit processor (020/030). Realize that in the case of filling a polygon or copying bitplane data, the blitter is only running parallel on the *last* blit. Thus for a four bitplane blit, for the first three blits I must WaitBlit() before the next blit. The blitter cannot *render* screens fast enough. Nor can the processor. For a complex scene, 30hz (stereo 3D) would be ideal, but we just don't have the horsepower available and thus the refresh rate issue becomes moot. But, when using the 32 bit processor we can render up to *three* times as many polygons as the blitter. While it's true that you can never exceed the scan rate and the +/- 16.6ms lag time, there are techniques to eliminate waiting for the display, ever. Finally, on the 3000, chip ram is now 32 bits wide, and we can now take advantage of 32 bit writes in half the time. The blitter is still working with 16 bit writes. I wrote a simple benchmark that just did a bunch of move.l's to chip ram. I compared a 28mhz GVP to a 25mhz 3000. The 3000 was twice as fast. My scan conversion code runs over 30% faster on the 3000 than the GVP, over three times faster than the blitter. Until we see a 34020 or equivalent for the Amiga, we can dust the blitter with the 32 bit processor for polygon fills. John
rick@ameristar (Rick Spanbauer) (06/03/90)
In article <2984@crash.cts.com> jcs@crash.cts.com (John Schultz) writes: >faster than the blitter. Until we see a 34020 or equivalent for the Amiga, >we can dust the blitter with the 32 bit processor for polygon fills. The 34020 or even the 860 alone is not enough to do realtime 3D graphics without additional support hardware. The 860 bus for example only does about 160 mByte/sec - consider that to update a 1024x768x24 bit screen at even 30 hz takes about 71 mBytes/sec. That is 71 mByte/sec just into the frame buffer, neglecting completely instruction path traffic, processing time, etc. I've been told that the 34020 can fill at only about 250 mBit/sec, so the time required to fill a 1024x768x24 display is 1024*768*24/250x10^6 = ~75 mS (or about 13 fps max), again neglecting insn fetch, processing time, etc. > John Rick Spanbauer Ameristar
jcs@crash.cts.com (John Schultz) (06/04/90)
In article <1990Jun3.164446.12193@ameristar> rick@ameristar (Rick Spanbauer) writes: >In article <2984@crash.cts.com> jcs@crash.cts.com (John Schultz) writes: >>faster than the blitter. Until we see a 34020 or equivalent for the Amiga, >>we can dust the blitter with the 32 bit processor for polygon fills. > > The 34020 or even the 860 alone is not enough to do > realtime 3D graphics without additional support hardware. The 860 > bus for example only does about 160 mByte/sec - consider that > to update a 1024x768x24 bit screen at even 30 hz takes about > 71 mBytes/sec. That is 71 mByte/sec just into the frame buffer, > neglecting completely instruction path traffic, processing time, > etc. I've been told that the 34020 can fill at only about > 250 mBit/sec, so the time required to fill a 1024x768x24 display > is 1024*768*24/250x10^6 = ~75 mS (or about 13 fps max), again > neglecting insn fetch, processing time, etc. > Yeah, yeah, and a Silicon Graphics 4D/GT 280 PowerVision isn't fast enough for some applications either :-). But, for certain applications, we don't need 24 bit planes, or even 1024x768 resolution. Say for a flight simulator we cut it down to 8 bitplanes, that's three times faster or approximately 39 frames/sec. A colleague at NASA Langley is running 20 frames/sec in Stereo 3D using 4D/GTs (Not the new PowerVision). But I'm sure they could increase the rez or increase the detail to make the frame rate "too slow". Basicaly, given your hardware/software constraints, do what you need in order to achieve the desired frame rate. I get 30 frames/sec in stereo 3D on an 030 Amiga, but I don't render a great deal of large polygons. If a 34020 board is created for the Amiga, I hope they don't make the same mistake as some PC vendors did by not supporting the lower resolutions of the 34020. Some applications require speed above all else, especially real time simulations. John