From: u894776@bruny.cc.utas.edu.au (James McCoull)
Subject: Re: Amiga Blitter 40% slower than Atari Blitter (???)
Organization: University of Tasmania, Australia.
Date: Thu, 8 Oct 1992 21:55:11 GMT

micro@imada.ou.dk (Klaus Pedersen) writes:

>Both blitters take a long time to set up, compared to small blits, like
>normal sprites. (or BLOBS).
>This is the reason that the blitters aren't used by people who have figured out
>how to do 68000 blits of preshifted mask and data.

Utter crap.  You must have been programming on the Atari ST too long.
68000 blits on the amiga with preshifted data, do not come close to using the
blitter.  Sure any decent ST programmer has always used preshifted data
and cpu based blit routines - but on the amiga I can tell you now - there is
*NO REASON* to use the cpu unless you are looking at sub 12x12 pixel images.

>The Amiga blitter can do cookie-cut directly 
>        (screen and mask or data) -> screen
>but the setup time is enormous.

	What is this "setup time" you talk of?  Setup time doesnt become an
issue until you are dealing with line drawing and template generation and
filling - for straight bitmap manipulations I can't find this setup time you
seem to be babbling about.

>The polygon fill in the Amiga blitter is useless because it is so slow, and the
>line drawing really can't be used as a general drawing primitive. (because it 
>lack features like adjustable thickness and patterns). (but for wireframe 3D
>games it might be good?)

Misguided truths.  Polygon filling on the amigas
blitter - is just like anything in life - right tool for the right job.  The
amigas blitter has no "polygon fill" mode - its a matter of using the features
it provides to generate polygons. These are some fast methods for drawing
polygons on the amiga:

	(1) APPEL method:
		Clear your bitplanes.
		Draw your lines cpu+68000 [depending on size] based on
			line segments you must draw after you have applied
			APPELs algorithm or a varient thereof.
		Template fill each bitplane [entirely].

		For one bitplane images this is very common technique.

	(2) LAMER:
		Draw each polygon using the lamer method of:  clear polygon
		buffer - draw polygon edges into buffer, copy buffer with
		template fill mode onto destination.  Hmm it doesnt take much
		work to decide that this method is slower than even poor
		68000 polygon filling code.

	(3) COOL:
		Triple or more buffering of course!
		[no one double buffers only anymore?]
		Clear your bitplanes to dominant polygon colour.
		Draw your polygons - as follows:

		Large polygons -
			Rectanglular subdivision - work out D=A [no sources
				enabled] areas.  Fill the remaining edge parts
				in using either the 68000, or the blitter
				[with a few tricks - put it in line mode,
				 and play with the registers - until you
				 have worked out how to get it to draw other
				 shapes than lines :) - or the other alternative				 is to convince the blitter to use a lookup
				 table as one of its sources :)]

		Medium polygons -
			Get the blitter to draw horizontal lines [*not* line
				mode, again D=A no sources enabled].  Bang the
				end words of each line down with the CPU - or
				add them all later using the above technique.

		Small polygons - use CPU... or blitter trick as mentioned in
				a previous post of mine.  The blitter trick
				*is* faster but takes a lot of memory, and
				takes a hell of a lot of time to get right
				[maybe I'm just a lame coder...]
		
		Of course all your code is fully optimised, the standard
		addx tricks and so forth, polygon size is flagged at generation
		time, your perspective transform has 0 muls [huge log/antilog
		tables :)], you are using a combined spherical and rectangular
		coordinate system to get your rotates down to around 5 muls [
		or if you really do have the ram - you have no muls but a two
		level table lookup scheme].  You are using BSPs, or better
		still the graph-theoretic edge-adjacency technique.  And for
		asteroid fields and the like... you are using the forward
		difference technique.

		All these techniques are worth it in the end - they buy you
		about a factor of 2x to 5x the performance of commonly used
		lamer routines - but take a sizeable amount of time to code :(

		(4) COOLEST - heck I can't give out details on this yet...  just
		one word... frame-frame coherence [and a DSP, or second CPU].

>>In article <u894776.718249257@bruny> u894776@bruny.cc.utas.edu.au (James McCoull) writes:
>>>wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:

>>>Anyway if you are really after speed... then you split it up into three
>>>blits no?

>>Sure, but we were talking hardware. If you are multitasking and you are doing
>>split blits, I suspect it might not look so good, when task switches hit
>>you between blits.

>Again : for small blits the setup time is enourmous! And splitting a blit
>into 3 don't help a bit.

Yep but we are talking about scrolling a window on a user interface screen.
Its not exactly gonna be small is it?

Again... what is this setup time you talk of?  Don't forget the time spent
in any recursively enumerable function can normally be reduced by look up
table.