30.04.2020 22:39
[#241]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #240
W tym przypadku chodzi o to, że zapis 4 pikseli chunky, gdybyśmy zapisywali je pojedynczo wynosi: O(d*n), gdzie d to liczba bitplanów, a n to liczba pikseli. Czyli dla 8 bitplanów byłyby to 64 operacje.
Ale wszyscy poza toba mowia o teoretycznej sytuacji, gdzie sprzet pracuje w trybie chunky. Tam zapis 4 dowolnych pikseli chunky to w najgorszym razie 4 operacje (cztery jednobajtowe zapisy gdzies do pamieci), w przypadku optymalnym (4 kolejne piksele) to jest jedna operacja. Ty dla odmiany uwazasz ze mowimy o rysowaniu piksela z bitmapy w trybie chunky do amigowej planarnej bitmapy.
Niewątpliwie racja, ale ja przyznam, że nie potrzebuję tak chunky, bo w moich grach używam BOBów. A ustawianie Blittera jest dość proste.
Dzieki takiemu podejsciu dyskusja z Toba o trybie chunky przypomina, przepraszam za paskudny kolokwializm, dyskusje ze slepym o kolorach...
01.05.2020 09:50
[#243]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@mschulz, post #241
OK, tryb Chunky ma oczywiste zalety, jest nim zapis jednego piksela jedną operacją, ja chciałem przedstawić czy można zapisać piksele Chunky w trybie Planar efektywnie.
I według tego co napisałem da się. Zapisujemy do pamięci CHIP dopiero jak przygotujemy 4 lub 8 sąsiadujących pikseli co jest konieczne ze względu na budowę pamięci. Ale w takiej postaci:
Chyba warto dociekać takich rzeczy. Może to być przydatne dla wielu osób. Sam na razie nie widzę zastosowania u siebie, ale jakieś może się znajdzie.
Ostatnia aktualizacja: 01.05.2020 10:03:14 przez Hexmage960
I według tego co napisałem da się. Zapisujemy do pamięci CHIP dopiero jak przygotujemy 4 lub 8 sąsiadujących pikseli co jest konieczne ze względu na budowę pamięci. Ale w takiej postaci:
- Piksele możemy transponować jedną operacją - czyli to na czym paru kolegom zależy najbardziej,
- Możemy zapisać do 4/8 pikseli w rejestrze jednym poleceniem MOVE.L, więc odpada nawet narzut O(n)! Pozostaje O(d).
- Możemy zapisywać piksele w mniejszych detalach 2x1 szybciej.
Chyba warto dociekać takich rzeczy. Może to być przydatne dla wielu osób. Sam na razie nie widzę zastosowania u siebie, ale jakieś może się znajdzie.
Ostatnia aktualizacja: 01.05.2020 10:03:14 przez Hexmage960
02.05.2020 10:33
[#245]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #244
Dodam w temacie, że gdyby Amigowe bitplany można było efektywnie zapisywać po 4 piksele, tak jak jest w chunky - nie byłoby z chunky na Amidze najmniejszego problemu.
Tymczasem pamięć graficzna Amigi składa się z 16/32-bitowych słów, co odpowiada 16/32 pikselom. A łączenie paczek pikseli jest kosztowne również pod względem użycia rejestrów.
Proszę. Oto kod, który efektywnie konwertuje 4 piksele (pełne 8-bitowe) C2P. Konwersja zajmuje całe 19 instrukcji, czyli 4,75 instrukcji na piksel. Może służyć jako fajna podstawa.
Ostatni krok (łączenie pikseli a+b, c+d) można uprościć i od razu zapisywać do pamięci, jak ktoś sobie życzy. Aktualnie funkcja zwraca 32-bitowy rejestr z wynikiem.
Wniosek jest też taki, że planar ma pole optymalizacyjne. Bo jak mam już te 32 piksele przygotowane (Boby, jakieś tło, paralaksa itp.), kopiowanie do pamięci graficznej jest szybkie.
Tymczasem pamięć graficzna Amigi składa się z 16/32-bitowych słów, co odpowiada 16/32 pikselom. A łączenie paczek pikseli jest kosztowne również pod względem użycia rejestrów.
Proszę. Oto kod, który efektywnie konwertuje 4 piksele (pełne 8-bitowe) C2P. Konwersja zajmuje całe 19 instrukcji, czyli 4,75 instrukcji na piksel. Może służyć jako fajna podstawa.
Ostatni krok (łączenie pikseli a+b, c+d) można uprościć i od razu zapisywać do pamięci, jak ktoś sobie życzy. Aktualnie funkcja zwraca 32-bitowy rejestr z wynikiem.
Wniosek jest też taki, że planar ma pole optymalizacyjne. Bo jak mam już te 32 piksele przygotowane (Boby, jakieś tło, paralaksa itp.), kopiowanie do pamięci graficznej jest szybkie.
; Input: d0 - 4 chunky pixels d2 - mask #$3333cccc d3 - mask #$55aa55aa ; Output: d0 - 4 planar pixels move.l d0,d1 and.l d2,d0 ; d0: ....a5a4 ....a1a0 ....b5b4 ....b1b0 c7c6.... c3c2.... d7d6.... d3d2.... eor.l d0,d1 lsr.w #2,d0 swap d0 lsl.w #2,d0 or.l d1,d0 ; d0: a7a6c7c6 a3a2c3c2 b7b6d7d6 b3b2d3d2 a5a4c5c4 a1a0c1c0 b5b4d5d4 b1b0d1d0 move.l d0,d1 and.l d3,d0 ; d0: ..a6..c6 ..a2..c2 b7..d6.. b3..d3.. ..a4..c4 ..a0..c0 b5..d5.. b1..d1.. eor.l d0,d1 ; d1: a7..c7.. a3..c3.. ..b6..d6 ..b2..d2 a5..c5.. a1..c1.. ..b4..d4 ..b0..d0 lsr.b #1,d0 ror.w #8,d0 add.b d0,d0 swap d0 swap d1 lsr.b #1,d0 ror.w #8,d0 add.b d0,d0 or.l d1,d0 rts
02.05.2020 11:25
[#246]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #245
Caly problem polega na tym ze caly czas teoretyzujesz.
Najlepszym dowodem na pokazaniu komus ze cos dziala jest pokazeanie z ze cos dziala.
Do tej pory nic takiego nie pokazales.
Przedstaw dowolny przyklad ze to faktycznie ma sens. Ale jesli piszesz ze:
To pewnie nikomu innemu tez sie nie przyda.
Na tej samej zasadzie moge ci przedstawic algorytm bezstratnej kompresji danych
o dowolnej dlugosci ze skutecznoscia 99%.
Ba, nawet caly program ktory to realizuje. Tylko co z tego jesli nikomu sie nie przyda?
Najlepszym dowodem na pokazaniu komus ze cos dziala jest pokazeanie z ze cos dziala.
Do tej pory nic takiego nie pokazales.
Przedstaw dowolny przyklad ze to faktycznie ma sens. Ale jesli piszesz ze:
Sam na razie nie widzę zastosowania u siebie, ale jakieś może się znajdzie.
To pewnie nikomu innemu tez sie nie przyda.
Na tej samej zasadzie moge ci przedstawic algorytm bezstratnej kompresji danych
o dowolnej dlugosci ze skutecznoscia 99%.
Ba, nawet caly program ktory to realizuje. Tylko co z tego jesli nikomu sie nie przyda?
02.05.2020 12:12
[#247]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Phibrizzo, post #246
Bardzo słusznie.
To mój głos w dyskusji, która tu się niedawno rozpoczęła.
Aktualnie pokazałem, że zapis 8-bitowego piksela chunky może kosztować 2 zamiast 8 zapisów (bo zapisujemy 4 piksele w 8 zapisach).
Wszystko rozchodzi się o zastosowanie, gdyż bardzo często trzeba algorytm dopasować do obranego celu.
W mojej grze Magazyn aktualnie nie potrzebuję takich efektów. Byłoby to z deka marnotrawstwem, skoro planarne BOBy mi wystarczą w tej grze.
Nie mam żadnego doświadczenia z efektami chunky, ale mam już troszkę doświadczenia z samym algorytmem do zapisu pikseli.
Mogę też pokazać benchmark, ale nie o to mi chodzi, żeby zapisać jak najszybciej wszystkie 81920 pikseli w klatce animacji na MC68020.
Chodzi mi o pokazanie gotowego pomysłu. A nawet gotowy kod pokazałem, więc teoretyzowania jakby mniej.
Każdy kto potrzebuje takiego algorytmu, znajdzie sobie zastosowanie.
Może Kefir lub SKOLMAN?
Ja sam wykażę się, kończąc Magazyn.
Efekty chunky wykorzystam później, po ukończeniu Magazynu, być może nawet w jakimś programie użytkowym, bo efekty na żywo - na razie nie przychodzą mi do głowy.
To mój głos w dyskusji, która tu się niedawno rozpoczęła.
Aktualnie pokazałem, że zapis 8-bitowego piksela chunky może kosztować 2 zamiast 8 zapisów (bo zapisujemy 4 piksele w 8 zapisach).
Wszystko rozchodzi się o zastosowanie, gdyż bardzo często trzeba algorytm dopasować do obranego celu.
W mojej grze Magazyn aktualnie nie potrzebuję takich efektów. Byłoby to z deka marnotrawstwem, skoro planarne BOBy mi wystarczą w tej grze.
Nie mam żadnego doświadczenia z efektami chunky, ale mam już troszkę doświadczenia z samym algorytmem do zapisu pikseli.
Mogę też pokazać benchmark, ale nie o to mi chodzi, żeby zapisać jak najszybciej wszystkie 81920 pikseli w klatce animacji na MC68020.
Chodzi mi o pokazanie gotowego pomysłu. A nawet gotowy kod pokazałem, więc teoretyzowania jakby mniej.
Każdy kto potrzebuje takiego algorytmu, znajdzie sobie zastosowanie.
Może Kefir lub SKOLMAN?Ja sam wykażę się, kończąc Magazyn.
Efekty chunky wykorzystam później, po ukończeniu Magazynu, być może nawet w jakimś programie użytkowym, bo efekty na żywo - na razie nie przychodzą mi do głowy.