13.01.2019 15:20
[#31]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Hexmage960, post #30
Ale jaki zwiazek ma konwersja hw za pomoca Akiko z mirrorowaniem bitplanow? Autor watku nie mowi, ze uzywa chunky buffer. To, ze konkretny algorytm na mirrorowanie bitow jest podobny do wstepnych krokow w c2p nie oznacza ze hw, ktory trobi taka konwersje sie w tym przypadku do czegos przyda.
13.01.2019 17:07
[#33]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Hexmage960, post #32
To ja nie rozumiem, co polecasz? Zastosowanie c2p? zastosowanie Akiko do mirrorowania bitplanow? Nie napisales tego w jasny sposob.
Poza tym jaka oszczednosc? Powtarzam ponownie - Akiko nie konwertuje chunky to planar w wielu krokach, tylko w jednym - na wejsciu chunky na wyjsciu planar - nie bedzie zadnej oszczednosci bo nie ma zadnych posrednich krokow, do ktorych masz dostep.
Poza tym jaka oszczednosc? Powtarzam ponownie - Akiko nie konwertuje chunky to planar w wielu krokach, tylko w jednym - na wejsciu chunky na wyjsciu planar - nie bedzie zadnej oszczednosci bo nie ma zadnych posrednich krokow, do ktorych masz dostep.
13.01.2019 17:16
[#34]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@docent, post #33
To ja nie rozumiem, co polecasz? Zastosowanie c2p? zastosowanie Akiko do mirrorowania bitplanow? Nie napisales tego w jasny sposob.
Nie polecam c2p. Napisałem tylko, że jeśli autor wątku pisze dla Amigi CD32, może wspomóc się Akiko.
Poza tym jaka oszczednosc? Powtarzam ponownie - Akiko nie konwertuje chunky to planar w wielu krokach, tylko w jednym - na wejsciu chunky na wyjsciu planar - nie bedzie zadnej oszczednosci bo nie ma zadnych posrednich krokow, do ktorych masz dostep.
A po co jest potrzebny dostęp do kroków pośrednich? Jeśli jest Akiko to po prostu pracujemy na chunky robiąc odbicie na pikselach chunky:
Zauważ, że kod jest dużo krótszy. Po dokonaniu odbicia za jego pomocą (i również dowolnych innych działań), wklejamy piksele (po 8 długich słów) w komórkę (a2), wyjmujemy i wklejamy do pamięci graficznej, ewentualnie korzystamy z WriteChunkyPixels().
; Wersja dla Amigi CD32 include 'graphics/gfxbase.i' xref GfxBase ; baza graphics.library (V40) movea.l GfxBase,a6 movea.l gb_ChunkyToPlanarPtr(a6),a2 ; a0: początek bufora pikseli chunky ; a1: koniec bufora pikseli chunky loop: move.l (a0),d0 ror.w #8,d0 swap d0 ror.w #8,d0 move.l -(a1),d2 ror.w #8,d2 swap d2 ror.w #8,d2 move.l d2,(a0)+ move.l d0,(a1) cmpa.l a0,a1 bgt.s loop rts
Ostatnia aktualizacja: 13.01.2019 17:27:54 przez Hexmage960
13.01.2019 18:51
[#35]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Hexmage960, post #34
W produkcji scenowej zazwyczaj (a w omawianym zagadnieniu w szczególności) nie ma znaczenia, czy kod jest krótszy. Ważne jest, czy jest szybszy. Ty całkowicie lekceważysz ten aspekt, nie po raz pierwszy zresztą. Poza tym nie wiem na jaki konfig pisze Kefir, ale nie sądzę, żeby ograniczał się do CD32.
13.01.2019 19:18
[#36]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Krashan, post #35
W przypadku użycia AKIKO kod jest i krótszy i szybszy.
Kolega wyraźnie nie czytał wątku dokładnie, stąd pochopne wnioski.
Przecież autor sam proponował rozwiązanie z użyciem wartości stablicowanych (LUT) twierdząc, że będzie szybsze niż zastosowanie konwersji wewnątrz rejestrów ponieważ odejdzie sporo instrukcji CPU. Proponował zatem rozwiązanie krótsze.
A ja wówczas proponowałem konwersję wewnątrz rejestrów sądząc, że będzie szybsza aniżeli krótki kod z dodatkowym użyciem dość sporej (64 kB) tablicy w pamięci.
Jestem fanem użycia tablic, ale nie w przypadku takiej dużej tablicy. Tablice można stosować do zwielokrotniania liczb, albo sinusów itp.
Później zaproponowałem użycie Akiko, które przyśpiesza operacje typu odbicie lustrzane i wiele innych.
Teraz pytam się kolegi - które rozwiązanie jest dłuższe, ale szybsze?
Pisze na procesor 68020, więc dość ubogo. Na razie tyle wiadomo.
Ostatnia aktualizacja: 13.01.2019 19:22:23 przez Hexmage960
Kolega wyraźnie nie czytał wątku dokładnie, stąd pochopne wnioski.
Przecież autor sam proponował rozwiązanie z użyciem wartości stablicowanych (LUT) twierdząc, że będzie szybsze niż zastosowanie konwersji wewnątrz rejestrów ponieważ odejdzie sporo instrukcji CPU. Proponował zatem rozwiązanie krótsze.
A ja wówczas proponowałem konwersję wewnątrz rejestrów sądząc, że będzie szybsza aniżeli krótki kod z dodatkowym użyciem dość sporej (64 kB) tablicy w pamięci.
Jestem fanem użycia tablic, ale nie w przypadku takiej dużej tablicy. Tablice można stosować do zwielokrotniania liczb, albo sinusów itp.
Później zaproponowałem użycie Akiko, które przyśpiesza operacje typu odbicie lustrzane i wiele innych.
Teraz pytam się kolegi - które rozwiązanie jest dłuższe, ale szybsze?
Poza tym nie wiem na jaki konfig pisze Kefir, ale nie sądzę, żeby ograniczał się do CD32.
Pisze na procesor 68020, więc dość ubogo. Na razie tyle wiadomo.
Ostatnia aktualizacja: 13.01.2019 19:22:23 przez Hexmage960
13.01.2019 19:27
[#37]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Hexmage960, post #34
Nie polecam c2p. Napisałem tylko, że jeśli autor wątku pisze dla Amigi CD32, może wspomóc się Akiko.
No jak to nie polecasz. Jesli piszesz, ze autor moze sie wspomoc akiko, ktore sluzy tylko do konwersji c2p, to co to oznacza?
A po co jest potrzebny dostęp do kroków pośrednich? Jeśli jest Akiko to po prostu pracujemy na chunky robiąc odbicie na pikselach chunky:
Czyli jednak polecasz... :)
Co do przykladu, to gdzie w nim jest wykorzystane Akiko?
Poza tym rozwiazanie, ktore proponujesz jest duzo wolniejsze od zwyklej rotacji bitow w formie planarnej - konwersja 32 chunky pixeli zajmuje 480+minimum 332 cykli na c2p przez Akiko. Rotacja bitow planarnych zajmuje 196 cykli plus troche na petle.
Ostatnia aktualizacja: 13.01.2019 19:35:23 przez docent
13.01.2019 19:29
[#38]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Hexmage960, post #36
Później zaproponowałem użycie Akiko, które przyśpiesza operacje typu odbicie lustrzane i wiele innych.
Przestan siac dezinformacje! Akiko nie przyspiesza operacji typu odbicie lustrzane - sluzy tylko do konwersji c2p i niczego wiecej.
Ostatnia aktualizacja: 13.01.2019 19:30:45 przez docent
13.01.2019 19:32
[#39]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@docent, post #37
No jak to nie polecasz. Jesli piszesz, ze autor moze sie wspomoc akiko, ktore sluzy tylko do konwersji c2p, to co to oznacza?
Poleciłem tryb chunky tylko w przypadku, gdy jest dostępne AKIKO. Wówczas c2p nie ma!
W przeciwnym przypadku nie polecałem c2p, tylko rozwiązanie planarne.
Ileż można to powtarzać?
Co do przykladu, to gdzie w nim jest wykorzystane Akiko?
Przeczytaj dokładnie tamten post.
Kończę wypowiadać się w temacie.
Ostatnia aktualizacja: 13.01.2019 19:34:22 przez Hexmage960
13.01.2019 20:35
[#40]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Hexmage960, post #39
Poleciłem tryb chunky tylko w przypadku, gdy jest dostępne AKIKO. Wówczas c2p nie ma!
W przeciwnym przypadku nie polecałem c2p, tylko rozwiązanie planarne.
Ileż można to powtarzać?
Nie polecales chunky, tylko napisales by uzyl Akiko na cd32 w temacie o lustrzanym odbiciu grafiki planarnej. I ani slowa o chunky, ktore wymaga Akiko jako input.
Przeczytaj dokładnie tamten post.
Przeczytalem - zamiesciles kod, ktory jest duzo wolniejszy od zwyklej petli typu move.b (a0)+, -(a1), w naglowku ma napisane wersja na cd32, w kodzie sa komentarze nt chunky pixeli, ale nie ma w nim sladu z uzycia Akiko do konwersji.
Ja chcesz by ktos korzystal z Twoich rad, to publikuj kompletny dzialajacy kod, a jesli nie umiesz tego zrobic, to od razu powiedz, zamiac walczyc do usranej smierci.
Kończę wypowiadać się w temacie.
Moze to i dobrze, bo o Akiko to chyba nie masz wiekszego pojecia.
13.01.2019 22:04
[#41]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@docent, post #40
Przeczytalem - zamiesciles kod, ktory jest duzo wolniejszy od zwyklej petli typu move.b (a0)+, -(a1), w naglowku ma napisane wersja na cd32, w kodzie sa komentarze nt chunky pixeli, ale nie ma w nim sladu z uzycia Akiko do konwersji.
Zrobię wyjątek i odpowiem, ale proszę stonować wypowiedzi.
Komentarz zamieściłem wewnątrz posta nad kodem. Po obróceniu kolejności bajtów w longwordzie oraz obróceniu longwordów należy skorzystać z AKIKO do wklejenia pikseli. Można to zrobić w dwojaki sposób (tak jak wówczas napisałem):
- skorzystać z wygodnej funkcji WriteChunkyPixels(), akcelerowanej AKIKO,
- samodzielnie użyć rejestru gb_ChunkyToPlanar w bazie biblioteki graphics.
AKIKO akceleruje dowolne operacje na grafice chunky, w tym:
- mapowanie pikseli,
- obracanie kolejności
- przemieszczanie pikseli
- transpozycja,
- itp.
Służy "tylko" do błyskawicznej konwersji pikseli chunky, ale w konsekwencji przyśpiesza i inne operacje na grafice.
13.01.2019 22:24
[#42]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Hexmage960, post #41
Masz na myśli, że Akiko powoduje, że c2p jest na tyle szybkie na gołym konfigu, że można rozważyć operację na danych chunky.
Możemy śmiało założyć, że Kefir nie będzie się ograniczał do CD32, więc możemy przestać się łapać za słówka i myśleć dalej. Bardzo bym chciał, by z tego wątku coś wynikło, bo mi też by się przydało szybko działające rozwiązanie. W tej chwili marnuję (?) sporo chipu trzymając grafiki dwukrotnie, ale lepszego rozwiązania na A500 nie znalazłem.
Mamy póki co opcje:
- LUT + CPU - wcina RAM, zajmuje sporo czasu CPU
- sam CPU - wolniej niż powyższe
- blitter słupami 1px - wolne
- blitter zamienia bity - wolniejsze niż wersja słupkowa (?)
- operacje na chunky + c2p - to drugie jest wąskim gardłem bez szybkiego proca lub akiko
kto da więcej? Czy jednak CPU okazuje się być najlepszym wyjściem?
Ostatnia aktualizacja: 13.01.2019 22:27:32 przez teh_KaiN
Możemy śmiało założyć, że Kefir nie będzie się ograniczał do CD32, więc możemy przestać się łapać za słówka i myśleć dalej. Bardzo bym chciał, by z tego wątku coś wynikło, bo mi też by się przydało szybko działające rozwiązanie. W tej chwili marnuję (?) sporo chipu trzymając grafiki dwukrotnie, ale lepszego rozwiązania na A500 nie znalazłem.
Mamy póki co opcje:
- LUT + CPU - wcina RAM, zajmuje sporo czasu CPU
- sam CPU - wolniej niż powyższe
- blitter słupami 1px - wolne
- blitter zamienia bity - wolniejsze niż wersja słupkowa (?)
- operacje na chunky + c2p - to drugie jest wąskim gardłem bez szybkiego proca lub akiko
kto da więcej? Czy jednak CPU okazuje się być najlepszym wyjściem?
Ostatnia aktualizacja: 13.01.2019 22:27:32 przez teh_KaiN
13.01.2019 22:35
[#43]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@teh_KaiN, post #42
- pakować grafikę i rozpakowywać jakiś szybkim depackerem w czasie gry/dema.
- to chyba słabe, ale na przykład gdy masz jakiś tam obiekt dajmy na to 32x32 to tylko połowe masz obróconą w x. Wtedy przy narzucaniu tylko połowę musisz odwracać. Tylko to daje straty bo zawsze musisz odwracać - dlategoż słabe.
Tutaj można znaleźć przydatne rzeczy link - na bardzo szybkim sprzęcie może mieć to sens.
- to chyba słabe, ale na przykład gdy masz jakiś tam obiekt dajmy na to 32x32 to tylko połowe masz obróconą w x. Wtedy przy narzucaniu tylko połowę musisz odwracać. Tylko to daje straty bo zawsze musisz odwracać - dlategoż słabe.
Tutaj można znaleźć przydatne rzeczy link - na bardzo szybkim sprzęcie może mieć to sens.
13.01.2019 22:40
[#44]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Hexmage960, post #41
AKIKO akceleruje dowolne operacje na grafice chunky, w tym:
•mapowanie pikseli,
•obracanie kolejności
•przemieszczanie pikseli
•transpozycja,
•itp.
Bzdury, Akiko akceleruje tylko konwersje chunky to planar, nie przyspiesza obracania, transpozycji ani mapowania pixeli. Poczytaj moze jakas dokumentacje z Commodore na ten temat zanim zaczniesz pisac.
13.01.2019 22:42
[#45]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@teh_KaiN, post #42
Ja raczej liczyłem na jakiś dobry trick blitter + copper. Wszelkie procedury konwersji będą zawsze wolniejsze niż zwykłe kopiowanie z fastmem. W moim przypadku odbijanie dotyczy prerenderowanej animacji, to oznacza że ją też można wcześniej odpowiednio przygotować pod jakieś dalsze mody blitterem lub copperem.
13.01.2019 22:48
[#47]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Kefir_Union, post #45
Mam pytanie w temacie kompresji, którą poruszono - w jakim formacie trzymasz swoją animację. Czy jest to format ANIM, albo podobny?
W grze Dune II lustrzane obracanie pojazdów, które odbywa się na żywo, gdy potrzebna jest obrócona grafika, jest zrealizowane za pomocą 256-elementowej tablicy LUT.
Z kolei cało-ekranowe animacje, które w tej grze występują, są skompresowane i rozpakowywane podczas wyświetlania.
Ostatnia aktualizacja: 13.01.2019 22:55:40 przez Hexmage960
W grze Dune II lustrzane obracanie pojazdów, które odbywa się na żywo, gdy potrzebna jest obrócona grafika, jest zrealizowane za pomocą 256-elementowej tablicy LUT.
Z kolei cało-ekranowe animacje, które w tej grze występują, są skompresowane i rozpakowywane podczas wyświetlania.
Ostatnia aktualizacja: 13.01.2019 22:55:40 przez Hexmage960
14.01.2019 09:51
[#49]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@docent, post #48
448x384 w 16 kolorach = 84kb na klatkę, Klatek 20, puszczane 25fps. Razem 1680kb.
Wyświetlana przesuwającym się oknem 360x286.
Animacja jest od linii 192 odbiciem w pionie i poziomie.
Chcę zmniejszyć objętość o połowę.
Na operacje związane z odbijaniem jest ok jednej ramki czasu dla blittera i maksimum 1/4 ramki jeśli ma to robić CPU.
Zmniejszanie rozdzielczości na razie nie wchodzi w grę.
A1200 + 4mb fast.
Ostatnia aktualizacja: 14.01.2019 09:52:35 przez Kefir_Union
Wyświetlana przesuwającym się oknem 360x286.
Animacja jest od linii 192 odbiciem w pionie i poziomie.
Chcę zmniejszyć objętość o połowę.
Na operacje związane z odbijaniem jest ok jednej ramki czasu dla blittera i maksimum 1/4 ramki jeśli ma to robić CPU.
Zmniejszanie rozdzielczości na razie nie wchodzi w grę.
A1200 + 4mb fast.
Ostatnia aktualizacja: 14.01.2019 09:52:35 przez Kefir_Union
14.01.2019 11:20
[#51]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Kefir_Union, post #49
Animacja jest od linii 192 odbiciem w pionie i poziomie.
O, wazna informacja.
Jesli chcesz odbic w pionie mozesz uzyc modulo. Zrob liste do coppera, w ktorej na poczatku ustawiasz bpl1mod, bpl2mod na 11, dalej czekaj copperem do 192 linii i ustawiaj modulo na -112+11.
W ten sposob skrocisz objetosc animacji o polowe, czyli tyle ile potrzebujesz.
14.01.2019 11:30
[#52]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Hexmage960, post #50
Tak, można zrobić ale trzeba gdzieś je umieścić. Jedynym miejscem jest fastmem, dlatego też wcześniej pisałem że używanie LUTów czy odwracanie kolejności bitów nie ma sensu w tym przypadku. Odbicie przebiega nie w połowie okna a w połowie klatki 448x384. Ponieważ okno się przesuwa po klatce w trakcie odtwarzania zapętlonej animacji także w pionie więc do skopiowania będzie różna ilość danych.
Załóżmy że zmniejszę okno do 320x256. Jeśli będzie się znajdować po środku klatki 448x384 to odbity kawałek do skopiowania ma 20kb (320x128). Jeżeli okno poruszy się w górę to do skopiowania będzie mniej, w skrajnym przypadku tylko 10kb (320x64). analogicznie, gdy okno wyświetlania przesunie się maksymalnie do dołu to kopiować trzeba 30kb (320x192).
Załóżmy że zmniejszę okno do 320x256. Jeśli będzie się znajdować po środku klatki 448x384 to odbity kawałek do skopiowania ma 20kb (320x128). Jeżeli okno poruszy się w górę to do skopiowania będzie mniej, w skrajnym przypadku tylko 10kb (320x64). analogicznie, gdy okno wyświetlania przesunie się maksymalnie do dołu to kopiować trzeba 30kb (320x192).
14.01.2019 11:51
[#54]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Kefir_Union, post #52
Myslalem raczej o czyms takim:
animacje, skrocona do polowy (bez dolnej polowy klatek) umieszczasz w chipramie - poniewaz target to a1200, wiec masz miejsce. Ustawiasz bplxpth, bplxptl na adres okna na twoja animacje, ktore bedziesz pokazywal. W zaleznosci od tego, jak zmienia sie polozenie okna, przesuwasz takze linie, do ktorej czeka copper, ktory zmienia modulo. Czyli jesli pokazujesz okno od 0,0, 360,192 to wait i zmiana modulo w copperze jest do 192 linii. Gdy okno bedzie np.od 0,100,360,392 to wait w copperze bedzie w linii 192-100
Ostatnia aktualizacja: 14.01.2019 11:55:47 przez docent
animacje, skrocona do polowy (bez dolnej polowy klatek) umieszczasz w chipramie - poniewaz target to a1200, wiec masz miejsce. Ustawiasz bplxpth, bplxptl na adres okna na twoja animacje, ktore bedziesz pokazywal. W zaleznosci od tego, jak zmienia sie polozenie okna, przesuwasz takze linie, do ktorej czeka copper, ktory zmienia modulo. Czyli jesli pokazujesz okno od 0,0, 360,192 to wait i zmiana modulo w copperze jest do 192 linii. Gdy okno bedzie np.od 0,100,360,392 to wait w copperze bedzie w linii 192-100
Ostatnia aktualizacja: 14.01.2019 11:55:47 przez docent
14.01.2019 12:38
[#58]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Kefir_Union, post #57
Jest jeszcze jeden mankament wynikający z kopiowania brakującej połówki. Gdy cała animacja mieści się w chip to klatki są umieszczone bezpośrednio po sobie i ich wyświetlanie to prosta zmiana adresów bitplanów. Jeżeli mam tylko połowę każdej klatki to muszę ją skopiować na bufor ekranu do którego będę kopiować dolną, odbitą połówkę. Pierwsze kopiowanie zrobi blitter ale zajmie mi w tym czasie dostęp do chip i CPU będzie czekać ze skopiowaniem dolnej części.
14.01.2019 13:22
[#59]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Kefir_Union, post #58
yyy chyba nie musisz komponować klatki blitem/cpu za każdym razem. Miej górną połowę animacji w RAMie z klatkami po sobie i oddzielny bufor na dolną część klatki. Copperlistę ustaw tak, by Ci copper przełączył bitplane'y ekranu po wyświetleniu góry na bufor dołu. Wtedy Ci odpada kopiowanie blitterem, zostaje tylko CPU. Możesz tu potrzebować podwójne buforowanie.
Ostatnia aktualizacja: 14.01.2019 13:23:04 przez teh_KaiN
Ostatnia aktualizacja: 14.01.2019 13:23:04 przez teh_KaiN
14.01.2019 14:11
[#60]
Re: Lustrzane odbicie grafiki w poziomie. Blitter.
@Kefir_Union, post #57
Moim zdaniem nie musisz nic kopiowac w trakcie wyswietlania - chyba ze masz jeszcze dodatkowe wymaganie typu rysowanie czegos w dolnej polowie ekranu itp.
Jesli nie, ponizszy algorytm bedze ok:
Zalozenie: dane do animacji sa wygenerowane w postaci lewej gornej cwiartki kazdej ramki animacji.
1. Dane wczytaj do fastu
2. skopiuj kazda cwiartke klatki do chipu np. zaczynajac od adresu $10000 co $a800
tak aby kazda linia pierwszego bpl zaczynala sie od adresu start, start+56, start+112 itp
3. odbij kazda cwiartke procesorem w poziomie pod adres start+28
tak aby kazda linia zaczynala sie od adresu start+28, start+56+28, start+112+28 itp
4. Zbuduj copperliste, w ktorej:
- ustaw copper wait na 1 linie ekranu
- ustaw kolory i diwsrt, diwstop na rozmiar okna, ktore chcesz wyswietlac (360x286)
- ustaw bplpth, bplptl odpowiednio na adres w pamieci, definiujacy okno ktore chcesz wyswietlic
- ustaw bpl1mod, bpl2mod na 11
- ustaw copper wait na 192
- ustaw bpl1mod, bpl2mod na -112-11
5. Rozpocznij animowanie - na przerwaniu vsync albo copper w zaleznosci of polozenia okna w animacji zmieniaj w copperliscie:
- bplth, bplptl
- copper wait (192-start okna) - to tylko gdy zmienia sie y okna
Potrzebny bufor w chipie to o $d2000 czyli 840kb
Przelaczanie i przeliczanie adresu startu ekranu praktycznie nic czasu nie zajmie i bedziesz mial caly czas procesora do dyspozycji.
Ostatnia aktualizacja: 14.01.2019 14:15:18 przez docent
Jesli nie, ponizszy algorytm bedze ok:
Zalozenie: dane do animacji sa wygenerowane w postaci lewej gornej cwiartki kazdej ramki animacji.
1. Dane wczytaj do fastu
2. skopiuj kazda cwiartke klatki do chipu np. zaczynajac od adresu $10000 co $a800
tak aby kazda linia pierwszego bpl zaczynala sie od adresu start, start+56, start+112 itp
3. odbij kazda cwiartke procesorem w poziomie pod adres start+28
tak aby kazda linia zaczynala sie od adresu start+28, start+56+28, start+112+28 itp
4. Zbuduj copperliste, w ktorej:
- ustaw copper wait na 1 linie ekranu
- ustaw kolory i diwsrt, diwstop na rozmiar okna, ktore chcesz wyswietlac (360x286)
- ustaw bplpth, bplptl odpowiednio na adres w pamieci, definiujacy okno ktore chcesz wyswietlic
- ustaw bpl1mod, bpl2mod na 11
- ustaw copper wait na 192
- ustaw bpl1mod, bpl2mod na -112-11
5. Rozpocznij animowanie - na przerwaniu vsync albo copper w zaleznosci of polozenia okna w animacji zmieniaj w copperliscie:
- bplth, bplptl
- copper wait (192-start okna) - to tylko gdy zmienia sie y okna
Potrzebny bufor w chipie to o $d2000 czyli 840kb
Przelaczanie i przeliczanie adresu startu ekranu praktycznie nic czasu nie zajmie i bedziesz mial caly czas procesora do dyspozycji.
Ostatnia aktualizacja: 14.01.2019 14:15:18 przez docent