ciąg dalszy "wersji z III obiegu": Jaguar to następny model Amstrada, Lynx następny model amigi a Macintosh to taki poprawiony Atari Pong
:)

gratulacje Kroll!

no nie wiem, dla mnie słaba jest ta amiga
w sumie to xt również mi nie podchodzi

ale jeśli chodzi o nakład pracy i jakość to szacun

swinkamor12, no i jeszcze 68030  - DML w tym porcie intensywnie używa DataCache którego nie ma w 020.

następne wideo:
https://www.youtube.com/watch?v=7BBSOJudnvM

nie zaglądałem jeszcze do kodu ale mam w głowie jeszcze jedną optymalizację.
Jeśli adres ekranu (ekranów) będzie zaczynał się od pełnej 16bitowej strony, np $10000, wtedy:
- zapisujemy tylko jedno - młodsze słowo do dstAddr BLiTTERa (4 cykle oszczędzone);
- zastępujemy "add.l    (a5)+,d0" przez "add.w    (a5)+,d0" w poniższym kodzie (4 cykle oszczędzone):

    movem.w    (a2)+,d0-d3            ;left x offset, right x offset, left mask, right mask
    sub.w    d0,d1                ;line width
    ext.l    d0
    add.l    (a5)+,d0
    asr.w    #3,d1
    bgt.s    .multi_words

jest moc!

Myślisz o tylko jednym przejściu dla leftEdge i rightEdge? Teraz widzę że powinno dać radę dzięki ujemnemu dstYinc.

Swoją drogą to dzięki bo zmobilizowałeś mnie do ruszenia szarymi komórkami :)

---Edycja---
ok, właśnie przeczytałem PMa :)
Więc miałeś na myśli leftEdge i rightEdge w jedym przebiegu. Dobry pomysł. Teraz wydaje mi się on oczywisty, no ale nie przyszło mi to wcześniej do głowy.

Co do przebiegów to robię inicjalizację i cztery:
- Inicjalizacja ładuje maski do Halftone.
- Pierwszy przebieg generuje maskę dla lewej strony linii na podstawie leftMask oraz Halftone.
- Drugi przebieg generuje maskę dla prawej strony linii na podstawie rightMask oraz NOT Halftone.
- Trzeci przebieg generuje adres pamięci dla lewej strony linii - (leftMask >>1) AND  $7FF8
- Czwarty przebieg generuje adres pamięci dla prawej strony linii - (rightMask >>1) AND  $7FF8

Dzięki temu mogłem skrócić "poly_fill_line" do:

    .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

To uwolniło mi parę rejestrów które mogłem wykorzystać do programowania BLiTTERa.

---Edycja---

ok, gotowe. udało mi się z deka wygładzić kod.
wieczorem może uda mi się uzupełnić brakujący kod dla blitMode (nowa procedura sblit3).

fajny pomysł, mam gdzieś dwa wyświetlacze 4:3 z latptopów HP, może dało by się je zaadoptować

Sikor, zgłaszam się.

wrzuć mi na PM maila to wyślę ci "brudnopis"

Skrzyp, mój błąd, otóż nie chodziło mi o wstążkę  :)
Miałem na myśli konfigurowalne menu nad nią - "Quick Access Toolbar":

Dla mnie jest on super, dzięki niemu mogę schować zwykły zajmujący sporo miejsca toolbar/wstążkę.

W LibreOffice również można konfigurować toolbar ale tylko główny, MS dał opcję wyboru - główny toolbar bez modyfikacji plus własny "Quick Access Toolbar".

Swoją drogą, mam wrażenie że LO 4.4.2.2 jest bardziej przyjazny niż 4.3.6. Trzeba się przyjrzeć co poprawili.