05.01 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 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 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 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 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 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 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 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 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 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 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 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 ;)