Zdecydowanie. Motorola tym razem pokazała pazur. :P

Można pomyśleć o tablicy divsów, to by jeszcze trochę przyspieszyło kod. Jeśli chodzi o wstawianie instrukcji w czasie działania blittera, to chyba zadziała to tylko w przypadku trybu BLIT, czyli trybu dzielonego (ale mogę się mylić). No ciekawe, jak wypadłby blitter w 4 planowym fillerze, ale zaczynam odnosić wrażenie, że mógłby być wolniejszy od motorli (jak sobie spojrzycie na 4 bitplanowego fillera z kilku tematów wstecz, to do wypełniania używam tam movemów i przy długich liniach robię bodajże 64 piksele na jednym movie - to może być już dla blittera za dużo).

Fakt, pierwsza i ostatnia część linii - to koszmar. :P Przez ten kod można rzeczywiście upatrywać zwycięstwa blittera. Chociaż jeśli, to i tak z niewielką przewagą. Wypełnienie 16 pikseli w 4 planach na blitterze i motoroli zajmuje dokładnie tyle samo czasu: w przypadku blittera są to 4 cykle * 4 plany, w przypadku movema to 8 cykli * dwa rejestry, czyli też 16. :) Czyli o zwycięstwie zadecyduje z jednej strony narzut na inicjalizację blittera, a z drugiej narzut na odkodowanie movemów (6 movemów * 16 cykli + pierwsza i ostatnia linia).

Edit:
Policzyłem sobie:
Całkowity czas dla linii 320 pikseli na motoroli (według mojej procki), to: 2*96 + 5*(12 + 8*8) + (12+4*8) -> 616.
Dla blittera to: 320 + czas inicjalizacji na poszczególnych planach. Kurde, może jednak być trochę szybciej. Chyba, że o czymś zapomniałem, bo jakoś tak za szybko tutaj mi to wygląda... :P

Oczywiście wstępna inicjalizacja blittera zajmuje czas, więc chyba bez kodu się nie obejdzie... :D

Nie do końca orientuję się, jak działa eor fill, ale pamiątaj, że obrys trójkąta trzeba wyrysować, trzeba pobrać poprzednią linię (to w blitterze zajmuje 8 taktów na 16 pikseli, a nie cztery jak przy wypełnianiu) i zeorować ją z aktualną, to z kolei zajmie albo 8 albo 12 taktów na 16 pikseli. Jak sobie podliczymy, to wcale już to tak dobrze nie wygląda. Chyba, że eor fill działa nie tak, jak napisałem? :(