02.09.2016 08:55
[#1]
Rzecz o rotacji
Gniotę sobie jakiegoś tam gniota na RK16 i w sumie dotarłem do momentu, gdzie przydatna by była dla mnie rotacja bitmapy 32x32. Jak to zrobić na niedopalonym OCS?
Można by zrobić to sobie prekalkulacją, ale przy prędkościach typu jeden obrót na 4 sekundy, trzeba by dużo klatek i mi to zje bardzo dużo CHIPu.
Można by sprawę potraktować z definicji stosując macierz rotacji 2x2 i liczyć wartość każdego piksela, ale pojawia się wtedy dużo floatów i aż dwie funkcje trygonometryczne na każdy piksel. To musi być wolne.
Zacząłem sobie czytać o zabawach typu 3x shear albo shear-transpose-shear. Ten pierwszy pomysł wprowadza pionowy shear, co mi się nie podoba, bo nawet nie mam pomysłu jak to próbować wydajnie zrobić. Ten drugi wydaje się być bardziej jadalny, ale transpozycja (zamiana wierszy bitmapy na kolumny lub na odwrót) wydaje się być nie do zrobienia blitterem, tylko tu już chyba tylko CPU i to mnie od tego zraża, bo implementacja wydaje się być wolna i brzydka.
Kolejne o czym pomyślałem, to żeby te bitmapy trzymać w postaci chunky i tak sobie wygodnie trzaskać transpozycje i sheary, ale w końcu i tak trzeba przejść na planar więc pojawia się jeszcze zmuł z powodu c2p.
Na pewno się da, bo przecież są te wszystkie dema z rotozoomerami no i ten nie dający spokoju Brian the Lion. Tylko jak?
Gwoli ścisłości - jeszcze nie czuję się dobrze z asmem 68k, wszystko piszę w C. Pewno nauka rotacji w normalnych warunkach polega na deasmowaniu cudzych dem, ale na to jestem za słaby - raz żeby wykonać, dwa żeby przeczytać. Z kontrolowaniem rejestrów Amigi z poziomu C problemu nie mam.
Można by zrobić to sobie prekalkulacją, ale przy prędkościach typu jeden obrót na 4 sekundy, trzeba by dużo klatek i mi to zje bardzo dużo CHIPu.
Można by sprawę potraktować z definicji stosując macierz rotacji 2x2 i liczyć wartość każdego piksela, ale pojawia się wtedy dużo floatów i aż dwie funkcje trygonometryczne na każdy piksel. To musi być wolne.
Zacząłem sobie czytać o zabawach typu 3x shear albo shear-transpose-shear. Ten pierwszy pomysł wprowadza pionowy shear, co mi się nie podoba, bo nawet nie mam pomysłu jak to próbować wydajnie zrobić. Ten drugi wydaje się być bardziej jadalny, ale transpozycja (zamiana wierszy bitmapy na kolumny lub na odwrót) wydaje się być nie do zrobienia blitterem, tylko tu już chyba tylko CPU i to mnie od tego zraża, bo implementacja wydaje się być wolna i brzydka.
Kolejne o czym pomyślałem, to żeby te bitmapy trzymać w postaci chunky i tak sobie wygodnie trzaskać transpozycje i sheary, ale w końcu i tak trzeba przejść na planar więc pojawia się jeszcze zmuł z powodu c2p.
Na pewno się da, bo przecież są te wszystkie dema z rotozoomerami no i ten nie dający spokoju Brian the Lion. Tylko jak?
Gwoli ścisłości - jeszcze nie czuję się dobrze z asmem 68k, wszystko piszę w C. Pewno nauka rotacji w normalnych warunkach polega na deasmowaniu cudzych dem, ale na to jestem za słaby - raz żeby wykonać, dwa żeby przeczytać. Z kontrolowaniem rejestrów Amigi z poziomu C problemu nie mam.
02.09.2016 09:11
[#2]
Re: Rzecz o rotacji
@teh_KaiN, post #1
Można by sprawę potraktować z definicji stosując macierz rotacji 2x2 i liczyć wartość każdego piksela, ale pojawia się wtedy dużo floatów i aż dwie funkcje trygonometryczne na każdy piksel. To musi być wolne.
Zamiast floatow uzywasz liczb staloprzecinkowych, np przesunietych w lewo o 8 bitow (2 -> 512, 1 -> 256, 0.5 -> 128 itd). Funkcje trygonometryczne stablicuj (tablica 256-elementowa wystarczy do 4 sekundowego obrotu przy 50 fps). Wystarczy sin, cos jest tylko przesuniety o 90° (albo o 64 przy 256 elementach). Pozostaja tylko mnozenia :)
02.09.2016 09:15
[#3]
Re: Rzecz o rotacji
@mschulz, post #2
Dzięki, w sumie czemu nie, może tyle mi wystarczy. Zapomniałem dodać, że potrzebuję obracać maksymalnie 8 obiektów 32x32 i 8 obiektów 16x16.
Czuję jednak w kościach, że to chyba nie jest najszybsze możliwe rozwiązanie i bardzo chętnie bym posłuchał o jakichś innych pomysłach, w razie gdyby to było za mało. ;)
Ostatnia aktualizacja: 02.09.2016 09:17:37 przez teh_KaiN
Czuję jednak w kościach, że to chyba nie jest najszybsze możliwe rozwiązanie i bardzo chętnie bym posłuchał o jakichś innych pomysłach, w razie gdyby to było za mało. ;)
Ostatnia aktualizacja: 02.09.2016 09:17:37 przez teh_KaiN
02.09.2016 09:33
[#5]
Re: Rzecz o rotacji
@teh_KaiN, post #3
nie żebym był jakimś mega coderem, ale może coś podpowiem...
ile bitplanów ma ten klocek 32x32? bo może zrobienie faz animacji nie będzie aż tak bardzo pamięciożerne.
policzmy:
32 pixele szerokości to 4 bajty
4 bajty * 32 wysokości = 128 bajtów
zakładając że klocek 32x32 ma 5 bitplanów to masz 128*5 = 640 bajtów
640 bajtów * powiedzmy 32 fazy animacji = 20480 bajtów (20 kb)
20kb * 8 = 160 kb
sam oceń czy to dużo czy nie.
pytanie czy musi być 32 fazy czy więcej a może mniej?
musisz obracać o 360 stopni? może klocek jest "powtażalny" i wystarczy obrócić o 90 stopni?
co do faz animacji jeśli szkoda ci chipu to zawsze możesz je trzymać np w fast ramie i kopiować procesorem jako długie słowa.
całą animację dla jednego klocka możesz mieć spakowaną i rozpakowywać tylko na czas animacji...
ja podobne podejście właśnie stosuję w produkcji nad którą cały czas pracuję (idzie powoli ;) ) w pamięci trzymam skompresowane klatki animacji i rozpakowuję tylko wtedy gdy mam je wyświetlić. rozpakowanie 20 kb jest jak dla mnie wystarczająco szybkie.
ile bitplanów ma ten klocek 32x32? bo może zrobienie faz animacji nie będzie aż tak bardzo pamięciożerne.
policzmy:
32 pixele szerokości to 4 bajty
4 bajty * 32 wysokości = 128 bajtów
zakładając że klocek 32x32 ma 5 bitplanów to masz 128*5 = 640 bajtów
640 bajtów * powiedzmy 32 fazy animacji = 20480 bajtów (20 kb)
20kb * 8 = 160 kb
sam oceń czy to dużo czy nie.
pytanie czy musi być 32 fazy czy więcej a może mniej?
musisz obracać o 360 stopni? może klocek jest "powtażalny" i wystarczy obrócić o 90 stopni?
co do faz animacji jeśli szkoda ci chipu to zawsze możesz je trzymać np w fast ramie i kopiować procesorem jako długie słowa.
całą animację dla jednego klocka możesz mieć spakowaną i rozpakowywać tylko na czas animacji...
ja podobne podejście właśnie stosuję w produkcji nad którą cały czas pracuję (idzie powoli ;) ) w pamięci trzymam skompresowane klatki animacji i rozpakowuję tylko wtedy gdy mam je wyświetlić. rozpakowanie 20 kb jest jak dla mnie wystarczająco szybkie.
02.09.2016 10:16
[#9]
Re: Rzecz o rotacji
@retronav, post #5
Ajjj no właśnie jestem rozdartą sosną, bo potrzebuję 6bpp (maska też!) i obroty 360 stopni.
Teraz sobie na szybko w phpie zacząłem szkicować rotację macierzową i dotarło do mnie, że pierwotne dane najlepiej kisić w chunky, więc tu też za rogiem się czai c2p na które nie za bardzo mam ochotę.
Dość dużo RAMu mi wpiernicza w obecnym momencie obszar gry, bo musi być możliwie duży, a swoich rutynek opartych o scrollingTrick w tej chwili nie używam żeby ograniczać źródła bugów. Też nie chcę podnosić wymagań sprzętowych bez wyraźnej potrzeby, celuję gdzieś tak w 1MB chipu na samą grafikę.
Rzecz się rozchodzi o sterowanie czołgiem i niezależnie jego wieżyczką, więc im gładsze 360 tym lepiej. Chyba zostanę przy tym, że podwozie będzie się obracało bardziej skokowo, za to ruch samej wieżyczki zrobi się gładszy.
No i też prekalkulacja. Niech to będą 32 kąty - przy prędkości 1 obrotu na 4 sekundy robisz ćwierć obrotu na sekundę. W ciągu sekundy widzisz 8 klatek. Trochę kiepawo. Chyba dla podwozia zrobię 64 obroty a dla wieżyczki 128 - podwozie zajmie 50 kB a wieżyczka 25. Najwyżej mapy będą skandalicznie małe a później się je powiększy, jak odpalę scrolling trick.
Ostatnia aktualizacja: 02.09.2016 10:29:28 przez teh_KaiN
Teraz sobie na szybko w phpie zacząłem szkicować rotację macierzową i dotarło do mnie, że pierwotne dane najlepiej kisić w chunky, więc tu też za rogiem się czai c2p na które nie za bardzo mam ochotę.
Dość dużo RAMu mi wpiernicza w obecnym momencie obszar gry, bo musi być możliwie duży, a swoich rutynek opartych o scrollingTrick w tej chwili nie używam żeby ograniczać źródła bugów. Też nie chcę podnosić wymagań sprzętowych bez wyraźnej potrzeby, celuję gdzieś tak w 1MB chipu na samą grafikę.
Rzecz się rozchodzi o sterowanie czołgiem i niezależnie jego wieżyczką, więc im gładsze 360 tym lepiej. Chyba zostanę przy tym, że podwozie będzie się obracało bardziej skokowo, za to ruch samej wieżyczki zrobi się gładszy.
No i też prekalkulacja. Niech to będą 32 kąty - przy prędkości 1 obrotu na 4 sekundy robisz ćwierć obrotu na sekundę. W ciągu sekundy widzisz 8 klatek. Trochę kiepawo. Chyba dla podwozia zrobię 64 obroty a dla wieżyczki 128 - podwozie zajmie 50 kB a wieżyczka 25. Najwyżej mapy będą skandalicznie małe a później się je powiększy, jak odpalę scrolling trick.
Ostatnia aktualizacja: 02.09.2016 10:29:28 przez teh_KaiN
02.09.2016 11:20
[#10]
Re: Rzecz o rotacji
@teh_KaiN, post #9
Wszystko zależy co chcesz mieć, czy szybką animację (wtedy potrzeba więcej pamięci) czy chcesz zajmować mniej pamięci (wtedy wolniejsza animacja). Smutna prawda jest taka że musisz obydwie rzeczy zbadać sam organoleptycznie, czyli usiąść i swoje odsiedzieć.
Możesz też zastosować parę sztuczek. Skoro potrzebujesz 360 stopni to można zrobić 180 stopni a reszte odbijać w locie w osi OX. Najmniej pamięci zje tabela bajtów (256), w której będą odwrócone bajty, czyli wygląda to tak
0x00 -> 0x00
0x01 -> 0x80
Taką tabelkę sam wygenerujesz albo znajdziesz na necie bez problemów. Możesz też zrobić tabelę dla słów czyli 65kb. Jest szybciej bo odwracasz już słowo zamiast bajtów. Jeszcze lepiej jak to trzymasz w fascie, bo przy 6 bitplanach dostęp do chip ramu jest smutniutki.
Możesz też odbijać w osi OY i to już jest lepsze bo po prostu zmieniasz porządek kopiowania i idziesz od końca do początku, tu chyba nawet da radę blittera zaprząc do tego, więc wydajność tu była.
A jeśli połączysz te dwie metody to wystarczy trzymać tylko klatki od 0 do 90 stopni a reszte wyliczasz na bieżąco. oczywiście do tego dochodzi koszt tablicy odwróconych bajtów/słów.
W każdym razie da radę tu policzyć koszt pamięci. Co do wydajności to musisz przysiąść.
Możesz też zastosować parę sztuczek. Skoro potrzebujesz 360 stopni to można zrobić 180 stopni a reszte odbijać w locie w osi OX. Najmniej pamięci zje tabela bajtów (256), w której będą odwrócone bajty, czyli wygląda to tak
0x00 -> 0x00
0x01 -> 0x80
Taką tabelkę sam wygenerujesz albo znajdziesz na necie bez problemów. Możesz też zrobić tabelę dla słów czyli 65kb. Jest szybciej bo odwracasz już słowo zamiast bajtów. Jeszcze lepiej jak to trzymasz w fascie, bo przy 6 bitplanach dostęp do chip ramu jest smutniutki.
Możesz też odbijać w osi OY i to już jest lepsze bo po prostu zmieniasz porządek kopiowania i idziesz od końca do początku, tu chyba nawet da radę blittera zaprząc do tego, więc wydajność tu była.
A jeśli połączysz te dwie metody to wystarczy trzymać tylko klatki od 0 do 90 stopni a reszte wyliczasz na bieżąco. oczywiście do tego dochodzi koszt tablicy odwróconych bajtów/słów.
W każdym razie da radę tu policzyć koszt pamięci. Co do wydajności to musisz przysiąść.
02.09.2016 15:50
[#11]
Re: Rzecz o rotacji
@asman, post #10
Jeszcze lepiej jak to trzymasz w fascie, bo przy 6 bitplanach dostęp do chip ramu jest smutniutki.
Dostęp do CHIP RAM przez procesor w niskiej rozdzielczości Lores nie zmienia się przez liczbę planów. Nawet w 8 planach procesor ma wszystkie dostępne cykle.
Dopiero w większej rozdzielczości niektóre cykle są kradzione przez Bitplane DMA, który musi częściej pobierać dane obrazu wideo z pamięci CHIP.
02.09.2016 16:14
[#13]
Re: Rzecz o rotacji
@teh_KaiN, post #9
znowu się powymądrzam. :) ale...
jeśli chodzi o animację obiektu do gry to chyba tylko animacja w klatkach wchodzi pod rozwagę a nie obracanie realtime.
jako że grafika mnie też interesuje to popodglądał bym gry tego typu gdzie były obracane sprajty/itp. Np HotRod Skidmarks itp.
podpatrz bo wydaje mi się żę to po prostu animacje (ba, jestem pewien ;) )
aha no i faktycznie zakładam że mowa o OCS (A500 7MHZ)?
jeśli chodzi o animację obiektu do gry to chyba tylko animacja w klatkach wchodzi pod rozwagę a nie obracanie realtime.
jako że grafika mnie też interesuje to popodglądał bym gry tego typu gdzie były obracane sprajty/itp. Np HotRod Skidmarks itp.
podpatrz bo wydaje mi się żę to po prostu animacje (ba, jestem pewien ;) )
aha no i faktycznie zakładam że mowa o OCS (A500 7MHZ)?
02.09.2016 16:18
[#14]
Re: Rzecz o rotacji
@asman, post #12
Wiem. Na OCS/ECS też tak jest. Tablice w pamięci CHIP mogą być bez problemu, jeśli przechowują one jakieś transformacje, które trudno wykonać za pomocą procesora. Nawet wielokrotności liczb się przechowuje by uniknąć kosztownego mnożenia.
Ale zysk będzie naprawdę dopiero, gdy teh_Kain skorzysta ze wstawek asemblerowych, a on chce czystego C.
Moje 3 grosze.
Ale zysk będzie naprawdę dopiero, gdy teh_Kain skorzysta ze wstawek asemblerowych, a on chce czystego C.
Moje 3 grosze.
02.09.2016 21:21
[#16]
Re: Rzecz o rotacji
@cholok, post #15
[offtopic]
Rzeczywiście, masz rację. Ale znalazłem fragment w Hardware Manual, który najwidoczniej zapadł mi w pamięć, bo odzwierciedla to co napisałem o "wyższych rozdzielczościach", "odświeżaniu obrazu" i "kradzeniu cykli".
Z poniższego fragmentu wynika, że systemowe kanały DMA zostały zaprojektowane mając na uwadze maksymalną wydajność. I w istocie tak jest, czyż bez tego Amiga nie byłaby tak wspaniała? Tylko wykorzystanie filozofii DMA, które zwalnia procesor z wielu zadań typu obsługa grafiki, czy dźwięku umożliwiło stworzenie tak wspaniałych gier oraz programów. To jest istota Amigi.
Doom niby nie działa? No fakt, może na stockowej 68020 będzie trudno. Procesor może wykonywać operacje na pamięci FAST z pełną prędkością, zaś koprocesory wideo zajmują się grafiką i obrazem wideo. Amiga to więcej, niż komputer bardzo dobrze przemyślany. On nie tylko wyprzedza swoje czasy... Amiga jest po prostu super konstrukcją.
Czasem trzeba dokonać wyboru. W tym przypadku chodzi o rozłożenie cykli pomiędzy różne układy DMA i procesor. Myślę, że konstruktorzy Amigi wybrali dobrze. Przede wszystkim nie docenia się na tyle Copper i Blitter, a te koprocesory potrafią wiele. Ogołocenie Amigi i koncentracja wszystkiego na mocnym 680x0 to złe rozwiązanie. Takie jest moje zdanie.
Procesor 680x0 w Amidze z reguły ma małe obciążenie, to samo tyczy się chipsetu.
"As mentioned previously, the custom chips have DMA access to RAM which
allows them to perform graphics, audio, and I/O chores independently of
the CPU. This shared memory that both the custom chips and the CPU can
access directly is called Chip memory.
The custom chips and the 680x0 CPU share Chip memory on a fully
interleaved basis. Since the 680x0 only needs to access the Chip memory
bus during each alternate clock cycle in order to run full speed, the rest
of the time the Chip memory bus is free for other activities. The custom
chips use the memory bus during these free cycles, effectively allowing
the CPU to run at full speed most of the time.
There are some occasions though when the custom chips steal memory cycles
from the 680x0. In the higher resolution video modes, some or all of the
cycles normally used for processor access are needed by the custom chips
for video refresh. In that case, the Copper and the blitter in the custom
chips steal time from the 680x0 for jobs they can do better than the
680x0. Thus, the system DMA channels are designed with maximum
performance in mind.
Even when such cycle stealing occurs, it only blocks the 680x0's access to
the internal, shared memory. When using ROM or external memory, also
known as Fast memory, the 680x0 always runs at full speed."
[/offtopic]
Rzeczywiście, masz rację. Ale znalazłem fragment w Hardware Manual, który najwidoczniej zapadł mi w pamięć, bo odzwierciedla to co napisałem o "wyższych rozdzielczościach", "odświeżaniu obrazu" i "kradzeniu cykli".
Z poniższego fragmentu wynika, że systemowe kanały DMA zostały zaprojektowane mając na uwadze maksymalną wydajność. I w istocie tak jest, czyż bez tego Amiga nie byłaby tak wspaniała? Tylko wykorzystanie filozofii DMA, które zwalnia procesor z wielu zadań typu obsługa grafiki, czy dźwięku umożliwiło stworzenie tak wspaniałych gier oraz programów. To jest istota Amigi.
Doom niby nie działa? No fakt, może na stockowej 68020 będzie trudno. Procesor może wykonywać operacje na pamięci FAST z pełną prędkością, zaś koprocesory wideo zajmują się grafiką i obrazem wideo. Amiga to więcej, niż komputer bardzo dobrze przemyślany. On nie tylko wyprzedza swoje czasy... Amiga jest po prostu super konstrukcją.
Czasem trzeba dokonać wyboru. W tym przypadku chodzi o rozłożenie cykli pomiędzy różne układy DMA i procesor. Myślę, że konstruktorzy Amigi wybrali dobrze. Przede wszystkim nie docenia się na tyle Copper i Blitter, a te koprocesory potrafią wiele. Ogołocenie Amigi i koncentracja wszystkiego na mocnym 680x0 to złe rozwiązanie. Takie jest moje zdanie.
Procesor 680x0 w Amidze z reguły ma małe obciążenie, to samo tyczy się chipsetu.
"As mentioned previously, the custom chips have DMA access to RAM which
allows them to perform graphics, audio, and I/O chores independently of
the CPU. This shared memory that both the custom chips and the CPU can
access directly is called Chip memory.
The custom chips and the 680x0 CPU share Chip memory on a fully
interleaved basis. Since the 680x0 only needs to access the Chip memory
bus during each alternate clock cycle in order to run full speed, the rest
of the time the Chip memory bus is free for other activities. The custom
chips use the memory bus during these free cycles, effectively allowing
the CPU to run at full speed most of the time.
There are some occasions though when the custom chips steal memory cycles
from the 680x0. In the higher resolution video modes, some or all of the
cycles normally used for processor access are needed by the custom chips
for video refresh. In that case, the Copper and the blitter in the custom
chips steal time from the 680x0 for jobs they can do better than the
680x0. Thus, the system DMA channels are designed with maximum
performance in mind.
Even when such cycle stealing occurs, it only blocks the 680x0's access to
the internal, shared memory. When using ROM or external memory, also
known as Fast memory, the 680x0 always runs at full speed."
[/offtopic]
02.09.2016 22:01
[#17]
Re: Rzecz o rotacji
@retronav, post #13
@retronav
Zależy jaka gra i ile masz pamięci na pokładzie. W takim mortal kombat 2 jak gdzieś na EAB wspominał autor, to zważywszy na ilość klatek, były one pakowane i rozpakowywane chyba właśnie w realtime.
Oczywiście wtedy używa się dekompresorów zorientowanych na prędkość. Przykładem takie depackera będzie LZ4.
Zależy jaka gra i ile masz pamięci na pokładzie. W takim mortal kombat 2 jak gdzieś na EAB wspominał autor, to zważywszy na ilość klatek, były one pakowane i rozpakowywane chyba właśnie w realtime.
Oczywiście wtedy używa się dekompresorów zorientowanych na prędkość. Przykładem takie depackera będzie LZ4.
03.09.2016 16:20
[#19]
Re: Rzecz o rotacji
@teh_KaiN, post #1
Kiedyś wpadło mi w oko coś takiego: http://www.amiga.org/forums/showpost.php?p=402997&postcount=12 Bawił się ktoś ta techniką?
Ostatnia aktualizacja: 03.09.2016 16:25:25 przez sanjyuubi
Ostatnia aktualizacja: 03.09.2016 16:25:25 przez sanjyuubi
03.09.2016 23:18
[#20]
Re: Rzecz o rotacji
@sanjyuubi, post #19
Noice! Funkcjami liniowymi blittera jeszcze się nie bawiłem żeby oszacować ile by to mu zajęło, ale jest ona na tyle szalona że kiedyś jej na pewno spróbuję.
Do przedmówców - tak, mowa o OCS/ECS. Z tymi 6bpp to doliczam też maskę - też by ją trzeba obracać, ale samo wyświetlanie już jest 5bpp - bo przecież leci ona tylko w kanał A blittera.
Jak już pisałem postawię na precalc. Co nie zmienia faktu, że tyle się naczytałem w tym temacie o Brian the Lion i jego realtime obracaniu platform, że nie daje mi to spokoju. ;)
Do przedmówców - tak, mowa o OCS/ECS. Z tymi 6bpp to doliczam też maskę - też by ją trzeba obracać, ale samo wyświetlanie już jest 5bpp - bo przecież leci ona tylko w kanał A blittera.
Jak już pisałem postawię na precalc. Co nie zmienia faktu, że tyle się naczytałem w tym temacie o Brian the Lion i jego realtime obracaniu platform, że nie daje mi to spokoju. ;)
10.09.2016 19:44
[#22]
Re: Rzecz o rotacji
@teh_KaiN, post #1
tan wątek na tyle mnie zaintrygował, że robiłem trochę reserczu na własne potrzeby i przy okazji znalazłem to - grafikę z Battle Squadron:
http://amiga.lychesis.net/game/BattleSquadron/BattleSquadron_Overworld_Enemies.html
fajne coś bo pokazuje dokładnie jak sprite'y w Battle Squadron są zrobione.
Pojazdy mają np 16 klate animacji w 32 kolorach a zobacz ile tam jest tych sprajtów...
bardzo pouczające są takie odkrycia (przynajmniej dla mnie).
Ten podlinkowany obrazek w pamięci Amigi będzeie miał 64kb jeśli dobrze liczę więc nie ma tragedii.
Polecam podejrzeć pozostałe grafiki z tej gry na tej stronie.
http://amiga.lychesis.net/game/BattleSquadron/BattleSquadron_Overworld_Enemies.html
fajne coś bo pokazuje dokładnie jak sprite'y w Battle Squadron są zrobione.
Pojazdy mają np 16 klate animacji w 32 kolorach a zobacz ile tam jest tych sprajtów...
bardzo pouczające są takie odkrycia (przynajmniej dla mnie).
Ten podlinkowany obrazek w pamięci Amigi będzeie miał 64kb jeśli dobrze liczę więc nie ma tragedii.
Polecam podejrzeć pozostałe grafiki z tej gry na tej stronie.
12.09.2016 12:05
[#24]
Re: Rzecz o rotacji
@teh_KaiN, post #23
Możesz użyć sztuczki, którą użyć można gdy blitujesz obiekty w sposób non interleaved, czyli normalnie. Dla 5 bitplanów robisz 5 blitów i masz jedną maskę. Jeśli zmienisz porządek to uzyskasz inną kolorystykę obiektu, szczególnie gdy obiekt ma na przykład tylko 8 kolorów (uzywa trzech pierwszych bitplanów). Chodzi o to że to co wrzucasz na pierwszy bitplan, to wrzucasz na ostatni i tak dalej. Oczywiście tutaj musisz całkiem nieźle się nagłowić nad paletą, ale dzięki temu oszczędzasz pamięć.
W grze Emerald Mine ta sztuczka jest wykorzystywana na sprajtach 16 kolorowych, czyli na bohaterze. By mieć sprajta 16 kolorowego to łączysz dwa sprajty, jeśli teraz je połączysz odwrotnie to masz inne kolory. Widać to w trybie na dwie osoby w wyżej wymienionej grze.
W grze Emerald Mine ta sztuczka jest wykorzystywana na sprajtach 16 kolorowych, czyli na bohaterze. By mieć sprajta 16 kolorowego to łączysz dwa sprajty, jeśli teraz je połączysz odwrotnie to masz inne kolory. Widać to w trybie na dwie osoby w wyżej wymienionej grze.