Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!knuth!mjbtn!raider!elgamy!elg
From: elg@elgamy.RAIDERNET.COM (Eric Lee Green)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: 3D stuff & quick line drawing
Message-ID: <00672624939@elgamy.RAIDERNET.COM>
Date: 26 Apr 91 00:15:39 GMT
References: <1991Apr24.203219.22776@cs.umu.se> <1991Apr21.081925.4722@lynx.CS.ORST.EDU> <1991Apr22.122442.25505@cs.umu.se> <20884@cbmvax.commodore.com>
Organization: Eric's Amiga 2000 @ Home
Lines: 57

From article <1991Apr24.203219.22776@cs.umu.se>, by dvljrt@cs.umu.se (Joakim Rosqvist):
> Sorry, I though Ownblitter meant
> 'when you have called this function, you own the blitter'

Right. The system will no longer try to use the blitter. However, the
blitter might still be doing something itself. The fact that OwnBlitter
doesn't try to WaitBlit means that you can overlap some of your own
processing with the blitter's operation, i.e. do all your calculations
before calling WaitBlit().

>>** Better to use WaitBlit(), which knows about various Agnus hardware bugs
>>** (see Autodocs for more details)
> The issue here was fast lines, if I could consider calling a ROM-routine

WaitBlit() isn't *THAT* bad!

> BTW, i read in another article that using the blitter on short lines
> should be a disadvantage because of the long setup-time. The breakoff
> was given to about 150 pixels. I don't know what processor was intended
> but I made a little test in the following environment:
>
> Program ran from fastmem, 68000 used, 1 bitplane 640x256 shown and
> no interrupts enabled.
> With the blitter i got 738000 pixels/second and 23 microsecond startup-time
> which equals 17 extra pixels on every line. Lines between 1..25 pixels
> all take the same time. The is beacuse the setup-time was really 58 micros
> but for longer lines some of this could be done while the blitter was
> drawing the previous line.
> With the 68000 i could get about 150000 pixels/sec and 24 micros 'setup'

Note that using the blitter to draw lines into a four bitplane screen takes
four times longer than into one bitplane. Four times the setup. Four times
the drawing. Meanwhile, extending your one-bitplane CPU-driven whatzit to
four bitplanes basically consists of putting in three more BSET
instructions into your loop. Which does NOT increase the overhead by four
times, and affects setup time very little (basically have to MOVEM four
bitplane pointers into address registers, rather than a single bitplane
pointer). You might end up with, say, 170000 pixels/second + 92 microsecond
setup time for the blitter version, and 130000 pixels/sec with 25 us setup
for the CPU version. The tradeoffs, for short lines, then become much more
obvious, though the blitter is still fastest for long lines on
unaccellerated Amigas. (on accelerated ones, no way!).

I *DO* assume that you're using assembly language for all of this?

And you can also unroll loops for faster drawing. But I suspect you already
knew that.

So -- if you're drawing into one bitplane, the speed advantage is obvious
for all line lengths. If you were drawing into 4 or more bitplanes, though,
things become quite different. I think Jez San has done some timings on BIX
of the 4-bitplane situation. I'll try to fetch them for you.

--
Eric Lee Green   (318) 984-1820  P.O. Box 92191  Lafayette, LA 70509
elg@elgamy.RAIDERNET.COM               uunet!mjbtn!raider!elgamy!elg
 Looking for a job... tips, leads appreciated... inquire within...