Dokładnie tak.. :D

Spróbujemy jednak teoretycznie na początek, ok? :P Nadmiarowy kod dla blittera to:

    asr.w    #3,d3
    move.w    d1,endmsk1(a6)
    move.l    d4,xCount(a6)
    move.b    #$a0,lineNum(a6); HOG

w przypadku linii poniżej 16 pikseli i

    asr.w    #3,d3  ;8+6
    addq.w    #1,d3  ;4
                   
    swap    d3   ;4
    move.w    d5,d3  ;4

    move.w    d0,endmsk1(a6)  ;12
    move.w    d1,endmsk3(a6)  ;12
    move.l    d3,xCount(a6)     ;16
                   
    move.b    #$a0,lineNum(a6); HOG   16

w przypadku linii powyżej 16 pikseli.

Mamy więc 82 cykle na odpalenie blittera.

Na motorli dochodzi wyliczenie skoku do właściwej długości linii i sam skok. Coś takiego:

        move.l    linesAdr(a4,d3.w),a5  ;20
    jmp        (a5)  ; 8

       and.w   d0,d2   ; maski w linii pierwszej wypełniającej   +4
       and.w   d1,d3  ; maski w linii ostatniej wypałniającej     +4

Rejestry są z czapy, chodzi o wyliczenia :)

Odejmując wszystko wychodzi, że inicjalizacja blittera zabiera o 46 cykle więcej, a to jest  w przybliżeniu 4  "move.w d0,i(a6)" - wypełniania na motoroli. To daje 4*16 = 64 piksele. Tyle w najlepszym przypadku zdąży narysować motorola, zanim blitter weźmie się do pracy. Czyli gdzieś po 80-100 blitter dogoni motorolkę.

Zmiana wypełniania z blittera na motorolkę jest w sumie banalna, więc można sobie napisać procedurę i zobaczyć, czy wyliczenia się potwierdzą. :)

Wydaje mi się, że 1-bitplanowe trójkąty wykorzystuje się jednak do wypełniania prostych (i dużych) figur, bo jeśli chcemy mieć skomplikowany obiekt (który prawdopodobnie nie zmieści się jednej ramce), to warto rozważyć użycie wieloplanowego wypełniania, żeby obiekt odpowiednio pokolorować.

@Wachu no właśnie miałem podobne obserwacje, aż moje face'y miały relatywnie krótkie linie to nie widziałem ogólnie zysku ze scan line fill na bliterze. przy duuuuzych face'a racja zysk będzie dokładnie jak to udowodniłeś.

@Adam blitterem można wypełniać kilka obiektów na raz ale nie scan line fill'em tylko eor fill'em. technika jest tu inna. no ale wtedy blitter musi czytać i zapisywać dane przez co działa wolniej. ale jest inicjalizowany raz i tak jak mówisz wypełniasz całą scenę "na raz". wszystko ma swoje wady i zalety:) dodatkowo eor fill'em dostajesz bonus wypełniania obiektów niewypukłych.

:D

Macie gdzieś jakieś materiały o tym?

Wachu: wygogluj eor fill. Chwile zajęło mi zrozumienie jak to działa, ale MKM mi dopomógł :)

z tego co widzę to masz parę rejestrów adresowych wolnych.
tak więc, tutaj mógłbyś przypisać każdej masce osobny An i zejść z 24 do 16 cykli:

                    move.w    d0,endmsk1(a6)        ;first line mask
                    move.w    d1,endmsk3(a6)        ;last line mask

tutaj również dedykowany An, dodatkowo nie ma potrzeby zmiany yCount, więc zamiast Longa możesz zapisać Word:

                    move.l    d3,xCount(a6)        ;xcount = d3, ycount = 1 at once

czyli zamiast 16 mamy 8 cykli

tu również dedykowany An:

                    move.b    #$a0,lineNum(a6); HOG   16

zamiast 16 mamy 12 cykle

Czyli z 82 cykli inicjalizacji mógłbyś zejść do 62.

faktycznie masz rację z yCount. 
Ale możesz zamienić xCount z yCount (czyli również Destination X increment oraz Destination y increment) dzięki temu xCount będzie tylko raz inicjowany a yCount przed każdym blitem.
Takie rozwiązanie zastosowałem w mojej procedurze dla sprajtów:

;BLiTTER Init
    move.l    #$00020002,(A0)+        ; source X increment / source Y increment
    move.l    A2,(A0)+            ; source address
    move.l    #-1,(A0)+            ; mask 1 /2
    move.w    #-1,(A0)+            ; mask 3
    move.l    #$00080080,(A0)+        ; destination X increment / destination Y increment
    lea        2(A0),A4            ; remember source destination
    move.l    A3,(A0)+            ; destination address
    move.w    #$0005,(A0)+        ; count X surface
    movea.l    A0,A1                ; remember count Y surface
    move.w    D0,(A0)+            ; count Y surface
    move.w    #$0204,(A0)+        ; HOP / LOP
    move.w    D4,(A0)                ; BUSY / HOG / SMUDGE / LINE NUMBER // FXSR / NFSR / SKEW


; Copy MaskSprite to Screen
    move.b    D2,(A0)                ; start blitter

    REPT    3
        lea        2(A3),A3
        move.w    A3,(A4)            ; destination address
        move.w    D0,(A1)            ; count Y surface
        move.b    D2,(A0)            ; start blitter
    ENDR

;
;BLITTER RE-INIT Sprite to Screen
    lea        $FFFF8A3C.w,A0
    move.l    A5,A3
    move.w    #$0207,$FFFF8A3A.w        ; HOP / LOP

; Copy Sprite to Screen
    move.w    A3,(A4)                ; destination address
    move.w    D0,(A1)                ; count Y surface
    move.b    D2,(A0)                ; start blitter

    REPT    3
        lea        2(A3),A3
        move.w    A3,(A4)            ; destination address
        move.w    D0,(A1)            ; count Y surface
        move.b    D2,(A0)            ; start blitter
    ENDR

no tak, ale możesz dać albo:

  xCount = 40 / yCount = 1

albo:

  xCount = 1 / yCount = 40

z tego co pamiętam efekt jest ten sam operacja dokonywana jest na tych samych 40stu słowach.
Oczywiście w zależności od wariantu trzeba odpowiednio ustawić Destination X/Y increment.

---edycja---

przemyślałem to jeszcze raz,  w wariancie xCount = 1 może być problem z zastosowaniem EndMask

w międzyczasie wyedytowałem posta:
przemyślałem to jeszcze raz,  w wariancie xCount = 1 może być problem z zastosowaniem EndMask

i jeszcze coś mi wpadło do głowy. Czy faktycznie poniższa instrukcja jest potrzebna?

   move.w    d5,d3  ;4

"addq.w    #1,d3  ;4" robisz w obrębie Word a nie Long

Panowie, bardzo proszę o poprawienie cytatów zgodnie z regulaminem. Tego się czytać nie da. Timer 24h.