05.01.2024 14:45
[#1]
Grafika Copper + Bitmapa
Bawię się ostatnio (na potrzeby Robot Jest Action 2) w użycie Coppera do grafiki na Amidze.
To co widzicie to grafika 4 kolorowa (2 bitplany) i Copperlista zmieniająca kolory co linię dla 4 rejestrów kolorów.
Proste i stare jak świat, ale musiałem sobie wymyśleć jak to projektować abym widział w czasie rzeczywistym jak to wygląda - zwłaszcza w palecie OCS na A500, i jak to potem eksportować/konwertować do pliku copper-listy.
Kilka słów więcej o tym znajdziecie u mnie na blogu - link na dole.
Aha na screenie, paski po lewej pokazują jakie kolory są podstawianie co linię dla 4 rejestrów.
A jak to robię to opowiem albo opiszę następnym razem. Muszę tę metodę jeszcze dopracować, ale już coś tam działa. Pokażę więcej jak już będzie co pokazać, a na ten moment kilka słów na moim blogu:
http://retronavigator.com/2024/01/05/amiga-gfx-with-copper-bars/
To co widzicie to grafika 4 kolorowa (2 bitplany) i Copperlista zmieniająca kolory co linię dla 4 rejestrów kolorów.
Proste i stare jak świat, ale musiałem sobie wymyśleć jak to projektować abym widział w czasie rzeczywistym jak to wygląda - zwłaszcza w palecie OCS na A500, i jak to potem eksportować/konwertować do pliku copper-listy.
Kilka słów więcej o tym znajdziecie u mnie na blogu - link na dole.
Aha na screenie, paski po lewej pokazują jakie kolory są podstawianie co linię dla 4 rejestrów.
A jak to robię to opowiem albo opiszę następnym razem. Muszę tę metodę jeszcze dopracować, ale już coś tam działa. Pokażę więcej jak już będzie co pokazać, a na ten moment kilka słów na moim blogu:
http://retronavigator.com/2024/01/05/amiga-gfx-with-copper-bars/
A tak z ciekawości, po co robić grafikę w 4 kolorach, skoro na A500 może być 32 lub 64 w EHB? To wynika jakoś z podziału palety w grze? 05.01.2024 15:09
[#3]
Re: Grafika Copper + Bitmapa
@TuReX, post #2
to wynika z oszczędności pamięci
- grafika 320x200 w 32 kolorach zajmuje w pamięci (40*200*5 = 40000 bajtów)
- grafika 320x200 w 4 kolorach zajmuje w pamięci (40*200*2 = 16000 bajtów) a obrazek powyżej ma jakieś 85 kolorów :)
- zajmuje też odpowiednio mniej na dysku.
dla demosceny albo gierki którą robię na OCS to może być ważne.
Ostatnia aktualizacja: 05.01.2024 15:10:16 przez c64portal
- grafika 320x200 w 32 kolorach zajmuje w pamięci (40*200*5 = 40000 bajtów)
- grafika 320x200 w 4 kolorach zajmuje w pamięci (40*200*2 = 16000 bajtów) a obrazek powyżej ma jakieś 85 kolorów :)
- zajmuje też odpowiednio mniej na dysku.
dla demosceny albo gierki którą robię na OCS to może być ważne.
Ostatnia aktualizacja: 05.01.2024 15:10:16 przez c64portal
05.01.2024 16:05
[#5]
Re: Grafika Copper + Bitmapa
@c64portal, post #1
Super to wygląda.
Dodam tylko, że każdy kij ma dwa końce a proca to nawet trzy.
Jasne jest że oszczędzamy pamięć w takim przypadku ale też możemy stracić 4 kolory, bo na przykład jakieś itemki już nie mogą mieć tych kolorów. Akurat w takim rysunku, kolory są w miarę podobne i nie ma ostrych zmian z zielonego na rózówy na ten przykład.
Ciekawie się robi przy przewijaniu w pionie, bo albo kopiujemy kolory odpowiednio w copperliście albo używamy fikółków z copjmp co jest tańsze.
Dodam tylko, że każdy kij ma dwa końce a proca to nawet trzy.
Jasne jest że oszczędzamy pamięć w takim przypadku ale też możemy stracić 4 kolory, bo na przykład jakieś itemki już nie mogą mieć tych kolorów. Akurat w takim rysunku, kolory są w miarę podobne i nie ma ostrych zmian z zielonego na rózówy na ten przykład.
Ciekawie się robi przy przewijaniu w pionie, bo albo kopiujemy kolory odpowiednio w copperliście albo używamy fikółków z copjmp co jest tańsze.
05.01.2024 16:33
[#6]
Re: Grafika Copper + Bitmapa
@asman, post #5
Dodam do tematu, że możemy sobie zaoszczędzić pamięć przeznaczoną na przechowywanie obrazka również w inny sposób i co więcej:
Otóż chodzi o tzw. PlanePick oraz PlaneOnOff.
PlanePickiem sterujemy w które bitplany chcemy wpisać dane graficzne. Przygotowujemy tylko tyle danych (bitplanów) ile jest zapalonych bitów w PlanePick.
PlaneOnOff zaś decyduje jakimi bitami wypełnić resztę bitplanów (0 lub 1 dla każdego bitplanu).
W tym przypadku, jeżeli korzystamy tylko i wyłącznie z 4 kolorów, to możemy zrobić przykładowo PlanePick ustawione na %00000011 (bitowo), lub $03 (szesnastkowo), zaś PlaneOnOff wybrać pulę 4 kolorów z palety (np. 32-kolorowej).
Żeby uzyskać różne pule, po prostu dzielimy obrazek na części, ale każda cześć potrzebuje tylko 2 bitplanów do przechowania.
Czyli jeżeli chcemy wybrać pierwszą pulę piszemy w PlaneOnOff zera: %00000000 ($0), drugą pulę - %00000100 ($04), trzecią pulę: %00001000 ($08) itd. (Indeks początkowy puli rośnie o 4 kolory).
Bitmapa ekranowa musi mieć wymaganą liczbę kolorów, ale oszczędności dotyczą danych graficznych. Nie potrzeba więcej niż 2 bitplany na każdy fragment obrazka (w tym przykładzie).
Można rzecz jasna obie metody połączyć i zyskać więcej kolorów na Copperze.
Efekt który uzyskał C64Portal wygląda świetnie, ja tylko informuję o innej metodzie na kompresję/oszczędność.
Ostatnia aktualizacja: 05.01.2024 16:35:47 przez Hexmage960
- Nie mieć ograniczeń palety (nadal dostępne są 32 dowolne kolory lub więcej na ekranie w dowolnym miejscu),
- Nie mieć ograniczeń Coppera (zmiany tylko w liniach poziomych),
Otóż chodzi o tzw. PlanePick oraz PlaneOnOff.
PlanePickiem sterujemy w które bitplany chcemy wpisać dane graficzne. Przygotowujemy tylko tyle danych (bitplanów) ile jest zapalonych bitów w PlanePick.
PlaneOnOff zaś decyduje jakimi bitami wypełnić resztę bitplanów (0 lub 1 dla każdego bitplanu).
W tym przypadku, jeżeli korzystamy tylko i wyłącznie z 4 kolorów, to możemy zrobić przykładowo PlanePick ustawione na %00000011 (bitowo), lub $03 (szesnastkowo), zaś PlaneOnOff wybrać pulę 4 kolorów z palety (np. 32-kolorowej).
Żeby uzyskać różne pule, po prostu dzielimy obrazek na części, ale każda cześć potrzebuje tylko 2 bitplanów do przechowania.
Czyli jeżeli chcemy wybrać pierwszą pulę piszemy w PlaneOnOff zera: %00000000 ($0), drugą pulę - %00000100 ($04), trzecią pulę: %00001000 ($08) itd. (Indeks początkowy puli rośnie o 4 kolory).
Bitmapa ekranowa musi mieć wymaganą liczbę kolorów, ale oszczędności dotyczą danych graficznych. Nie potrzeba więcej niż 2 bitplany na każdy fragment obrazka (w tym przykładzie).
Można rzecz jasna obie metody połączyć i zyskać więcej kolorów na Copperze.
Efekt który uzyskał C64Portal wygląda świetnie, ja tylko informuję o innej metodzie na kompresję/oszczędność.
Ostatnia aktualizacja: 05.01.2024 16:35:47 przez Hexmage960
05.01.2024 20:12
[#11]
Re: Grafika Copper + Bitmapa
@c64portal, post #10
Zakładam że ten program po prostu generuje kolory palety (całe 4) dla każdej linii obrazka. Nie jestem żadnym znawcą amigowego HW ale wiem że użycie Coppera "zjada" trochę czasu i dla calej palety 32 kolorów "zje" nam obrazek po lewej stronie. Mam być może głupie pytanie - czy odpalenie przerwania Coppera co linię i zmianę palety (powiedzmy pełne 32 kolory) przez CPU będzie szybsze? Odpalenie przerwania chyba też trochę "rastra kosztuje"...
05.01.2024 20:38
[#13]
Re: Grafika Copper + Bitmapa
@pisklak, post #11
nie wiem czy umiem odpowiedzieć na Twoje pytanie, ale spróbuję.
Całej palety 32 kolorów nie da się zmienić co linię. Jeśli dobrze pamiętam to w jednej lini można zmienić 16 rejestrów ale na całej jej długości więc nie wiem czy dało by się to zastosować. 4 kolory udaje się Copperowi zdążyć zmienić zanim konkretna linia bitmapy zacznie być wyświetlana.
Zmiana koloru przez CPU nie wiem czy jest do zrobienia bo musiał byś sledzić w której lini jesteś i też wątpię czy jak uda się zdążyć zmienić kolory zanim linia się skończy, nie mówiąc już zmienić przed jej rozpoczęciem.
Może jakiś koder to wyjaśni lepiej, bo ja jestem tylko grafikiem ;)
@cholok
Screenshoty to... tylko screenshoty. nie wiem jak Wordpress je skonwertował gdy je wrzucałem na blog. Sam je tylko powiększyłem aby były czytelniejsze.
A to co opisuję to na pewno działa bo mam prosty programik to testujący. Wrzucę .exe na blog i dam tutaj znać to będziecie mogli uruchomić na A500 wzwyż.
Całej palety 32 kolorów nie da się zmienić co linię. Jeśli dobrze pamiętam to w jednej lini można zmienić 16 rejestrów ale na całej jej długości więc nie wiem czy dało by się to zastosować. 4 kolory udaje się Copperowi zdążyć zmienić zanim konkretna linia bitmapy zacznie być wyświetlana.
Zmiana koloru przez CPU nie wiem czy jest do zrobienia bo musiał byś sledzić w której lini jesteś i też wątpię czy jak uda się zdążyć zmienić kolory zanim linia się skończy, nie mówiąc już zmienić przed jej rozpoczęciem.
Może jakiś koder to wyjaśni lepiej, bo ja jestem tylko grafikiem ;)
@cholok
Screenshoty to... tylko screenshoty. nie wiem jak Wordpress je skonwertował gdy je wrzucałem na blog. Sam je tylko powiększyłem aby były czytelniejsze.
A to co opisuję to na pewno działa bo mam prosty programik to testujący. Wrzucę .exe na blog i dam tutaj znać to będziecie mogli uruchomić na A500 wzwyż.
05.01.2024 20:42
[#14]
Re: Grafika Copper + Bitmapa
@c64portal, post #1
Czemu na tym obrazku z rainbowami są paski po lewej stronie?
Pamiętaj, że warto unikać DisplayRGB dla koloru 0, bo kolory wyjadą na overscan po bokach. Wiem, że przez DisplayControls można się pozbyć tego efektu, ale niestety tylko dla AGA i ECS Denise. Przy OCS i ECS Agnus ten efekt powróci. Można się tego pozbyć jedynie tworząc w asemblerze specjalną copperlistę, lecz w Blitz Basic tego nie zrobisz, bo raczej nie ma szans stworzyć ręcznie copperlisty używając Dc.l, bo nie widziałem w Blitz Basic obsługi hunk data, jak w ASM One przykładowo:
Pamiętaj, że warto unikać DisplayRGB dla koloru 0, bo kolory wyjadą na overscan po bokach. Wiem, że przez DisplayControls można się pozbyć tego efektu, ale niestety tylko dla AGA i ECS Denise. Przy OCS i ECS Agnus ten efekt powróci. Można się tego pozbyć jedynie tworząc w asemblerze specjalną copperlistę, lecz w Blitz Basic tego nie zrobisz, bo raczej nie ma szans stworzyć ręcznie copperlisty używając Dc.l, bo nie widziałem w Blitz Basic obsługi hunk data, jak w ASM One przykładowo:
Section Copper DATA_C Copper Dc.l ... Dc.l $fffffffe
05.01.2024 21:04
[#15]
Re: Grafika Copper + Bitmapa
@tukinem, post #14
hej tukinem
Z tym kolorem 0 to chyba ja ci powiedziałem więc wiem o tym ;)
To co tutaj pokazuję to w końcu tylko testu koncepcji, więc jak dla mnie może być także na kolorze 0.
Całą copper listę generuję właśnie jako dane dc.w - da się :)
Ale wygenerowanie z tego kodu Blitza zajmuje chwilę bo do tego używam komendy CustomString w BB. W moim programie trwa to jakieś 10 sekund, ale na potrzeby sprawdzenia pomysłu na razie wystarczy.
Wrzuciłem plik .zip z programem i grafikami jak by ktoś chciał uruchomić. Powinno działać na każdej Amidze.
http://retronavigator.com/2024/01/05/amiga-gfx-with-copper-bars/
Z tym kolorem 0 to chyba ja ci powiedziałem więc wiem o tym ;)
To co tutaj pokazuję to w końcu tylko testu koncepcji, więc jak dla mnie może być także na kolorze 0.
Całą copper listę generuję właśnie jako dane dc.w - da się :)
Ale wygenerowanie z tego kodu Blitza zajmuje chwilę bo do tego używam komendy CustomString w BB. W moim programie trwa to jakieś 10 sekund, ale na potrzeby sprawdzenia pomysłu na razie wystarczy.
Wrzuciłem plik .zip z programem i grafikami jak by ktoś chciał uruchomić. Powinno działać na każdej Amidze.
http://retronavigator.com/2024/01/05/amiga-gfx-with-copper-bars/
05.01.2024 21:17
[#16]
Re: Grafika Copper + Bitmapa
@c64portal, post #13
No chodzi mi o to że można co linię odpalać przerwanie Coppera i w nim tą paletę zmieniać prockiem. W teorii powinno być szybsze tylko odpalenie przerwania też chyba sporo kosztuje.
05.01.2024 21:22
[#17]
Re: Grafika Copper + Bitmapa
@pisklak, post #16
Ale tu się żadnych przerwań nie odpala. możesz Copperowi powiedzieć jakie rejestry w jakiej pozycji rastra ma zmienić. maksymalnie 16 rejestrów w lini. Ustawia się to jako program dla Coppera podaje adres od którego jest i się go odpala.
Ale niech niskopoziomowi koderzy się wypowiedzą ...
Ale niech niskopoziomowi koderzy się wypowiedzą ...
05.01.2024 22:37
[#20]
Re: Grafika Copper + Bitmapa
@pisklak, post #16
Da się, ale nie pamiętam czy było szybciej. Chyba nie, to zależy od dostępu do pamięci chip (16 vs 32 bit). Jest problem z synchronizacją, bo odpalanie przerwań nie jest identyczne co do cyklu. Jak pamiętam na Atari ST jedno move.w zajmowało 10 pikseli, na A500 powinno być tak samo, a jeśli nawet to nie szybciej niż copper. Na Atari ST znaleźli sposób na idealną synchronizację, na Amidze nikt się w to nie bawił.
04.03.2024 12:44
[#21]
Re: Grafika Copper + Bitmapa
@cholok, post #20
Wracam do tematu. Dalej testuję, próbuję i uczę się w tej technice tworzyć grafiki.
Kilka kolejnych przykładów na mojej stronie
https://c64portal.pl/2024/03/04/en-playing-with-gfx-and-copper-again/
jak by ktoś pytał, to tak, połączyłem dwa moje blogi w jeden ;)
Kilka kolejnych przykładów na mojej stronie
https://c64portal.pl/2024/03/04/en-playing-with-gfx-and-copper-again/
jak by ktoś pytał, to tak, połączyłem dwa moje blogi w jeden ;)
14.06.2024 18:44
[#23]
Re: Grafika Copper + Bitmapa
@c64portal, post #21
No i wracam po raz kolejny i tym razem mam nadzieję że mi autorzy Tonego wybaczą.
do rzeczy...
Dzisiaj na warsztat wziąłem sobie grafikę z niedawno wydanej, świetnej gry Tony (w wersji na Amigę).
Grafika w grze jak wiadomo jest monochromatyczna, a mi przez głowę przeszło jak by mogła ona wyglądać podkolorowana copperem.
I żeby uciąć spekulacje... nie mam zamiaru poprawiać grafiki w tej grze ani w jakikolwiek sposób krytykować czy insynuować coś twórcy grafiki w Tonym czyli Rafałowi. Wykonał super robotę i myślę, że rozumiem jego zamiłowanie do monochromatycznej grafiki i decyzje arytsyczne. Pomyślałem jednak, że grafika z Tonego będzie idealnym sposobem aby poćwiczyć z moim podejściem do takiego tworzenia grafiki na Amidze.
Cały czas twierdzą że potencjał jest duży, a grafika wygląda nieźle (ba wg mnie nawet dobrze). Jest kolorowo i nie zajmuje to dużo więcej miejsca w pamięci. Kto wie, może zainspiruję twórców Tonego do zrobienia kolejnych wersji gry ;) Tak czy siak grafiki mogły by wyglądać np tak:
na mojej stronie grafiki w większym rozmiarze.
Zerknijcie na dwa pierwsze obrazki. Właściwie to ten sam obrazek tylko w innej kolorystyce. Fajne jest, jak łatwo jest zmienić nastrój grafiki, używając różnych copper barów
Co do kwestii technicznych to jeśli dobrze liczę to każda linia z kolorem wygląda w copper liscie tak:
i takie coś powtózone tyle razy ile lini w grafice. W Tonym to jest 200 lini czyli 200*12 bajtów = 2400 bajtów. Nieco ponad 2 kb dodatkowo na ekran. Powiedział bym że nie najgorzej.
No dobra ale jak to tworzyć?
Cierpliwości. Niebawem powinienem nagrać filmik w któym uchylę nieco mojego warsztatu.
Creditsy: Grafiki do tych przykładów zabralem ze strony K&A.
Ostatnia aktualizacja: 14.06.2024 18:45:12 przez c64portal
do rzeczy...
Dzisiaj na warsztat wziąłem sobie grafikę z niedawno wydanej, świetnej gry Tony (w wersji na Amigę).
Grafika w grze jak wiadomo jest monochromatyczna, a mi przez głowę przeszło jak by mogła ona wyglądać podkolorowana copperem.
I żeby uciąć spekulacje... nie mam zamiaru poprawiać grafiki w tej grze ani w jakikolwiek sposób krytykować czy insynuować coś twórcy grafiki w Tonym czyli Rafałowi. Wykonał super robotę i myślę, że rozumiem jego zamiłowanie do monochromatycznej grafiki i decyzje arytsyczne. Pomyślałem jednak, że grafika z Tonego będzie idealnym sposobem aby poćwiczyć z moim podejściem do takiego tworzenia grafiki na Amidze.
Cały czas twierdzą że potencjał jest duży, a grafika wygląda nieźle (ba wg mnie nawet dobrze). Jest kolorowo i nie zajmuje to dużo więcej miejsca w pamięci. Kto wie, może zainspiruję twórców Tonego do zrobienia kolejnych wersji gry ;) Tak czy siak grafiki mogły by wyglądać np tak:
na mojej stronie grafiki w większym rozmiarze.
Zerknijcie na dwa pierwsze obrazki. Właściwie to ten sam obrazek tylko w innej kolorystyce. Fajne jest, jak łatwo jest zmienić nastrój grafiki, używając różnych copper barów
Co do kwestii technicznych to jeśli dobrze liczę to każda linia z kolorem wygląda w copper liscie tak:
dc.w $xx07,$fffe, $180,$xxx, $182, $yyy
i takie coś powtózone tyle razy ile lini w grafice. W Tonym to jest 200 lini czyli 200*12 bajtów = 2400 bajtów. Nieco ponad 2 kb dodatkowo na ekran. Powiedział bym że nie najgorzej.
No dobra ale jak to tworzyć?
Cierpliwości. Niebawem powinienem nagrać filmik w któym uchylę nieco mojego warsztatu.
Creditsy: Grafiki do tych przykładów zabralem ze strony K&A.
Ostatnia aktualizacja: 14.06.2024 18:45:12 przez c64portal
15.06.2024 10:59
[#26]
Re: Grafika Copper + Bitmapa
@KM_Ender, post #25
Nie wiem, jak chciałbyś to uzyskać pod Blitz Basic, ale gdy pisałem tego Snake'a chciałem zarówno kolor 0 jak i kolor 1 zmieniać copperem. Na AGA to działa. Na OCS tylko jeden kolor można zmieniać. Przy próbie zmiany obu nie zmienia ani jednego. Używałem do tego DisplayRGB.
Piszesz, że wychodzi 2KB na ekran. Masz 160 linii ekranu głównego. Tablica 160 linii po 3 kolory to wychodzi w sumie 480 bajtów na komnatę. Mając 25 komnat w danym levelu to będzie około 7KB na cały taki level.
Ostatnia aktualizacja: 15.06.2024 11:06:43 przez tukinem
Piszesz, że wychodzi 2KB na ekran. Masz 160 linii ekranu głównego. Tablica 160 linii po 3 kolory to wychodzi w sumie 480 bajtów na komnatę. Mając 25 komnat w danym levelu to będzie około 7KB na cały taki level.
Ostatnia aktualizacja: 15.06.2024 11:06:43 przez tukinem
15.06.2024 12:58
[#30]
Re: Grafika Copper + Bitmapa
@tukinem, post #26
Da się w blitzu. Trzeba użyć Custom Copper... czy jakoś tak się ta komenda nazywa.
Wtedy dla każdej lini musi być stworzony taki fragment dla copper listy:
To jest 12 bajtów. czyli 2400 bajtów wychodzi dla ekranu 200 lini.
Dla 160 lini będzie 12*160 =1920 bajtów
... i nie musisz mieć dla każdej komnaty inny zestaw. Można przecież mieć wspólne copper colory dla kilku komnat. Można poza tym to też spakować. wg mnie spakuje się bardzo fajnie, ale nie robiłem jeszcze prób.
Zrobiłem to już kiedyś w BB2. Wrzucałem, ale jak chce ci się zerknąć to poniżej link do mojej strony gdzie jest plik (zaraz na górze) do pobrania. Kodu źródłowego tam niestety nie dodałem, ale może za jakąś chwilę wrzuće na mojego githuba. Link do Githuba jest w menu głównym na mojej stronie.
https://c64portal.pl/2024/01/05/amiga-gfx-with-copper-bars/
Wtedy dla każdej lini musi być stworzony taki fragment dla copper listy:
dc.w $xx07,$fffe, $180,$xxx, $182, $yyy
To jest 12 bajtów. czyli 2400 bajtów wychodzi dla ekranu 200 lini.
Dla 160 lini będzie 12*160 =1920 bajtów
... i nie musisz mieć dla każdej komnaty inny zestaw. Można przecież mieć wspólne copper colory dla kilku komnat. Można poza tym to też spakować. wg mnie spakuje się bardzo fajnie, ale nie robiłem jeszcze prób.
Zrobiłem to już kiedyś w BB2. Wrzucałem, ale jak chce ci się zerknąć to poniżej link do mojej strony gdzie jest plik (zaraz na górze) do pobrania. Kodu źródłowego tam niestety nie dodałem, ale może za jakąś chwilę wrzuće na mojego githuba. Link do Githuba jest w menu głównym na mojej stronie.
https://c64portal.pl/2024/01/05/amiga-gfx-with-copper-bars/