Pinex, ja też poproszę. zapodaj jakiegoś xexa

szach mat :)

Wczoraj w nocy udało mi się dodać optymalizację w której BLiTTER generuje nową tablicę leftEdge address/rightEdge address/leftMask/rightMask. Skraca ona czas całości o trzy linie skaningowe. Nie jest to powalający wynik, ale nowy kod daje miejsce na dalsze optymalizacje.

.poly_fill_line wygląda teraz tak:

.poly_fill_line:
    movem.w  (A0)+,D0-D3        ; D0 - left; D1 - right; D2 - left mask; D3 - right mask
    movea.l  a5,a4
    lea      logLine(a5),a5     ;next y offset line
    lea      (a4,d0.w),a4       ;add line x offset
    sub.w     d0,d1              ;line width
    
    asr.w    #3,D1
    bgt.s    .multi_words

Kod jest brudny, wieczorem siądę by go oczyścić i jutro wrzucę go na forum.

Naprawdę słuszna koncepcja :)

jeśli chodzi o moją część to, mam działający kod ale niestety nie miałem jeszcze czasu zintegrować go z trianglefi. Muszę jeszcze raz przemyśleć użycie rejestrów gdyż w trianglefi większośc jest wykorzystana.

Niestety dopiero wieczorem będę miał więcej czasu, siądę do Twojego ostatniego kodu i zrobię parę testów.

Jeśli chodzi o wybraną ilość planów to jasne, zapodawaj :)
Jakby co to też mam kod, tylko jeszcze go nie publikowałem. W sumie są to kosmetyczne zmiany do aktualnej procedury blittera.

No ciekawe. Chodzi o usprawnienie compute_triangle_dx?

Jakby co to mam ideę na zmianę w fill_triangle_line_loop. BLiTTER, na podstawie leftEdge/rightEdge może wygenerować left mask/right mask. Koszt to 34 cykle szyny na inicjalizację rejestrów Halftone a potem tylko 2 cykle szyny na maskę.
A jeszcze jakby udało się przeorganizować tablice leftEdge/rightEdge na taką:

REPT rezY
 ds.w leftEdge, rightEdge, leftMask, right Mask. 
ENDR

to w fill_triangle_line_loop można by jednym zgrabnym "movem.w    (A0)+,D0-D3" ładować od razu wszystkie potrzebne dane.

dzięki

ok, a kto robił te pacze?

:)

zapodawaj :)

widzę jeszcze miejsce na drobne optymalizacje, typu:
- Jeśli ekran jest w obrębie 16bitowej strony to można:
"move.l a4,dstAddr(a6)        ; Destination Addr" --> "move.w a4,dstAddr+2(a6)        ; Destination Addr"

- zmienić adresowanie dla kodu blittera z:

    move.w    D0,hop(A6)
...
    move.w #0,endmsk3(a6)        ; EndMask3
    move.w    #-6,dstYinc(a6)        ; DestYInc
    move.l a4,dstAddr(a6)        ; Destination Addr
    move.w #2,xCount(a6)        ; xCount
    move.w d4,yCount(a6)        ; yCount
    move.b D7,lineNum(a6)        ; Do Blit, start with 3rd Half-Tone

na:

    lea        $FFFF8A3A.w,A6    ;HOP
    move.w    D0,(A6)
...
    move.w d4,-(a6)    ; yCount
    move.w #2,-(a6)        ; xCount
    move.l a4,-(a6)        ; Destination Addr
    move.w #-6,-(a6)        ; DestYInc
    move.w #0,-2(a6)        ; EndMask3

    move.b D7,$10(a6)        ; Do Blit, start with 3rd Half-Tone

Ale to urywa zaledwie kilkanaście cykli na linię.

git, czyli teraz TOS 4.04 działa na ST?
pewnie było sporo łatek. Będzie można je obejrzeć?

Dzięki. Wyprodukowałeś naprawdę fajny kod, przy nim optymalizacja BLiTTERa to błahostka :)
Swoją drogą BLiTTER był mocno niedoceniany ale myślę że może on czymś nas zaskoczyć.

pewnie tak.
można jeszcze spróbować z rozdzieleniem linii - krótkie CPU; długie BLiTTER.

hehe :)

Może jeszcze dziś uda mi się wrzucić kod źródłowy.
Główną ideą było zaoszczędzenie cykli procesora przez usunięcie zbędnych instrukcji (zaskakujące :) ). Tak więc, podzieliłem kod blittera na trzy części - wykonywaną: tylko raz; raz na trójkąt; co każda linia. Najbardziej czasochłonna jest ta ostatnia, gdzie BLiTTER był programowany tymi samymi wartościami dla każdego bitplanu osobno.
Moja optymalizacja to wykonanie tylko jednego blittu dla wszystkich bitplanów. Rejestr yCount zawiera ilość wypełnianych bitplanów a dstYinc wartość ujemną - przesunięcie każdego bitplanu.
Haczyk tkwi w wykorzystaniu rejestrów Halftone, Line Number i OP. Dla wariantu 16sto kolorowego potrzeba 128 bajtów pamięci (16kolorów * 8bajtów), a dostępnych są 32 bajty.

--edycja--
dodałem plik dla wersji 4P. Teraz obsługuje tylko 4 bitplany. W wolnej chwili dorobię wariant dla innej ilość bitplanów.