@tebe - ale nie o to chodzi. Ja wiem jak zrobić te wszystkie operacje w asemblerze PIC'a. Bardziej lub mniej optymalnie. Chodzi mi tylko o to co opisałem: że albo postawię na wydajność a wtedy będę miał 64 prawie identyczne procedury, trudne w serwisowaniu, albo zunifikuję wszystko kosztem wydajności.

A propos tego co napisałeś o odbiciach, to spróbuj takie pomysły zastosować w asm Atari :) Ja w PIC'u też piszę w asemblerze więc sam rozumiesz...

Co do mojego podstawowego problemu to właśnie testuję sposób, który może być złotym środkiem: bufor linii, to którego najpierw przepisuję linię obiektu robiąc w locie odpowiednie operacje (inwersja, odbicie poziome, przesunięcie bitowe), a następnie tę linię nakładam na ekran w odpowiednim trybie (XOR, OR, AND). Specyfika asemblera PIC'a jest taka, że może się to okazać optymalnym i dość uniwersalnym rozwiązaniem. Uniwersalny bufor linii się przyda, gdybym chciał w przyszłości dopisać kolejne operacje, jak np skalowanie poziome obiektu.
Zobaczymy jak to wyjdzie wydajnościowo.
Mam tylko wrażenie, że wynajduję od nowa blitter ;) a przecież ktoś już kiedyś musiał stanąć przed identycznymi problemami.

Wczoraj robiłem testy nowych procedur rysujących (maksymalnie szybkich, bez obcinania obiektów na brzegach, bez odbić, inwersji itp.) dla 4-kolorowego duszka.
W czasie kiedy antic nie rysuje obrazu udało mi się narysować 120 duszków o wymiarach 8 bajtów x 16 linii, w trybie z maską niezależną od kolorów (dokładnie jest to operacja: (maska AND obiekt) OR (INV(maska) AND tło)  ). Przy czym połowę czasu zajęło Atari na samo wysyłanie rozkazów rysowania do PIC'a.
Śmiesznie to wyglądało na ekranie :)

To nie tak. Kilkukrotnie wydłużyłby się czas wykonania, jeśli stworzyłbym jedną uniwersalną procedurę, a warnunki wstawił w sam środek pętli kopiującej. Tak jest najwygodniej, ale i najmniej wydajnie.

Zrobienie warunków poza pętlami i przekierowywanie do jednej z np. 60 procedur jest wydajne, ale poza rozwleczeniem kodu, mocno kłopotliwe. Co jeśli znajdę błąd? Będę go musiał poprawiać we wszystkich procedurach. Co jeśli zmienię format obiektów?
Taki kod jest cholernie klopotliwy w "utrzymaniu". I nieelegancki :P

Moim zdaniem nie powinieneś się w ogóle sugerować blitterem z ST. Nie jest to nalpeszy blitter pod słońcem. Może zacznij od tego jakich operacji potrzebujesz?

Poza tym, jestem pewien, że jakiś macro assemble albo preprocesor w C umożliwiłby zrobienie wszystkich kombinacji w oparciu o sprytne makra bez komplikacji, o których piszesz.

Miałem na myśli, że makra są rozwiązaniem tego problemu technicznego:

nie jest najlepszy ale jest dobry, no i w pewnych operacjach szybszy od konkurencji :p

Kuba, przeceniasz mnie ;) Faktycznie nie pomyślałem o makrach, bo na Atari praktycznie nigdy ich nie używam (tak samo jak prawie żadnych pseudorozkazów - lubię widzieć czysty i cały kod).
Pomysł słuszny i dobry.

Właściwie już wiem jak to zrobię: cudów nie ma, pójdę na kompromis. Najczęściej używane opcje będą wydzielone do osobnych wersji procedur, żeby działaly najwydajniej. Makra pomogą utrzymać spójność kodu. Będzie tego kilka wersji.
Reszta opcji będzie w zbiorczej, wolniejszej procedurze z warunkami, operującej na buforze linii.

Dzięki za pomoc.

@Fox - PIC ma architekturę harwardzką, więc żadnego kodu w locie nie wygeneruje. Z drugiej strony napisanie sobie generatorów źródeł asemblera w jakimś języku skryptowym i skonkretyzowanie ich dla wszystkich przypadków mogłoby mieć sens.

@mono - nie może. Przecież to by rozwiązało mój problem :)
Nawet organizacja pamięci jest inna i kłopotliwa: w pamięci RAM adres parzysty to słowo (16-bit), a w pamięci programu adres to 24 bity.

Można jedynie podmapować część pamięci programu (paczkę 32KB) do obszaru widzianego jako RAM, w celu odczytania danych tam przechowywanych.
Ale nie można w żaden sposób odpalić kodu z RAM'u.

Czyli automodyfikacje odpadają i to był mój problem.
Budowa rozwiązania pośredniego trwa.

qba - Czy masz na myśli, że miałbym napisać sobie jakiś rodzaj języka i pisać w nim program w RAM? :)