Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty
From: scotty@l5comp.UUCP (Scott Turner)
Newsgroups: comp.sys.amiga
Subject: Re: BlitzFonts query reply
Message-ID: <127@l5comp.UUCP>
Date: Sun, 17-May-87 00:11:04 EDT
Article-I.D.: l5comp.127
Posted: Sun May 17 00:11:04 1987
Date-Received: Tue, 19-May-87 06:27:07 EDT
References: <8705130700.AA24705@cory.Berkeley.EDU> <1866@cbmvax.cbmvax.cbm.UUCP>
Reply-To: scotty@l5comp.UUCP (Scott Turner)
Organization: L5 Computing, Edmonds, WA
Lines: 52
Summary: How it really works :-)

In article <1866@cbmvax.cbmvax.cbm.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes:
>In article <8705130700.AA24705@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>>>> What is BlitzFonts?  You mentioned using it to make text scroll faster...
>>>That's exactly what it is ... a program that "hooks" itself into AmigaDOS
>>>(the console.device ?) that speeds up the display of text output.  I dunno
>>
>>	Definately not the console device.
>Correct.  Blitzfonts is of the class of programs that are easy to write
>once you think of it.  Ready ?  (Individual details may vary :-)
>It replaces the Text() vector of the graphics.library with a version of Text() t
>hat does not handle proportional fonts (so you get to use multiply*8), doesn't
>have progromatic styles, kerning (positive or negative), and frequently
>uses the processor to spit out the bits, rather than the blitter.
>
>(You could use the blitter and go still faster, I think, but most 
>implementations I've seen don't use it.  Or if they do, they avoid
>the normal blitter calls, as demoed by my WatchBlit program)
>
>Got it ?
The following notes are based on the 'giveaway' BlitzFonts program.

BlitzFonts ties into the system through the graphics.library Text routine. It
doesn't use the SetFunction call, tsk tsk tsk ;-), but rather reaches in and
swaps the library vector itself. What it does is patch in a new text rendering
routine that is optimized for the topaz80 font. One item of interest about this
routine is that it uses a hardcoded 720 pixel wide template and if the string
will not fit into it (ie > 90 chars long) the routine aborts rather than just
render 720 pixels from the string. The routine is based on the fact that the
Topaz80 font is 8 bits wide by 8 bits high. Thus it is possible to use a hard-
coded memory move loop to copy the bit pattern from the font into the template
using simple move.b (Ax)+,disp(Ay) addressing. Once the template is complete
it is fed to the BlitTemplate routine to actually render it. About the only
faster way to render text than this routine would be to use a single bitplane
window and move into it rather than a template/BlitTemplate scheme, but that
wouldn't be very general purpose :-). So this routine is about as fast as we
can expect to get.

Many thanks to Mr. Haugen for this program.

[The above was prepared before Andy's reply so here's a thought on what Andy said]

The blitter is not designed for rendering a STRING of chars. It has stuff for
a single char. However, the overhead in setting up the blitter for each char
is such, that in single bitplane cases the CPU may indeed be faster than the
blitter.

Scott Turner

-- 
L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM.
GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020
If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs
[ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)