uwazaj na bana za cytowanie bezposrednio poprzedzajacego listu :)
a powaznie, to samo rysowanie jest banalne, tak jak mowisz, tylko trzeba przygotowac dane. Wyobraz sobie np ze masz obrazek na PC, powiedzmy skrinszot z second reality. Musisz tak jakby 'odwrocic blitter' i wtedy wykryc linie. Ale nie jest to takie trywialne. Pewnie sa jakies algorytmy, ktore by to zrobily, ale to bylo dawno i nie pamietam :)
w rozdzielczosci 160x100 masz 4000 bajtow do uaktualnienia, wiec sam fill by zabral 12*4000 = 48000, czyli raptem 2 ramki, masz 3 ramki na narysowanie calkiem sporo linii... zeby przyspieszyc mozesz uzyc 80x50 lub 80x100 w 16 kolorach.
powodzenia, na pewno da sie to zrobic.
Aha, i ten blitter ofkorz jest trudniejszy do zrobienia linii, bo kazda roznica w przejsciach kolorow wywoluje nowa linie, wiec potencjalnie znaczaco zwieksza ilosc linii czyli rozmiar danych i predkosc rysowania. Mozna zrobic inny blitter, ale wtedy troche fill zwolni. Na przyklad dla 16-kolorowego trybu, jesli godzimy sie stracic 1 kolor (0), mozna zrobic cos takiego:
ldy buf ; tam gdzie rysujemy linie, co wazne - nie potrafimy narysowac koloru 0
beq nochange ; jesli nie ma zmiany, kontynuuj.
and ands,y ; zgas czesc bitow
ora buf ; zapal nowe bity
stx buf ; wyczysc bufor linii, w X jest 0
nochange
sta screen
... i tak dla kazdego bajtu. duuuzy kod :)
Wlasciwie nie musi to wcale byc znaczaco wolniejsze, bo masz 11 cykli dla bajtow, gdzie nie ma zmiany koloru i 22 dla bajtow ze zmiana. Ten poprzedni ma zawsze 12, wiec jesli jest niewiele linii, moze wcale tak duzo nie tracisz.
Jak znam zycie, ludzie wymyslili tez inne blitterki, moze ktos sie podzieli?
: 404. Stopka not found