19.03.2020 08:39
[#212]
Re: Akiko 32
@sanjyuubi, post #210
Wiem tylko że jednak trzeba mieć jakąś wiedzę żeby zacząć dłubać przy MMU, a ja jej nie mam. Komunikat - fakt jest uciety, zarówno na monitorze jak i na telewizorze crt.
Próbowałem podmienić plik MMU-Configuration z mojej płyty z kopią systemu i też nic to nie dało. Chyba nie do końca w nim leży problem bo wagowo i zawartościowo są takie same.
Pytanie gdzie musetcachemode zapisuje wynik swojej ingerencji ?
Po wykasowaniu MMU-Confoguration, system odpala już bez komunikatu.
Ostatnia aktualizacja: 19.03.2020 08:40:26 przez mikecios
Próbowałem podmienić plik MMU-Configuration z mojej płyty z kopią systemu i też nic to nie dało. Chyba nie do końca w nim leży problem bo wagowo i zawartościowo są takie same.
Pytanie gdzie musetcachemode zapisuje wynik swojej ingerencji ?
Po wykasowaniu MMU-Confoguration, system odpala już bez komunikatu.
Ostatnia aktualizacja: 19.03.2020 08:40:26 przez mikecios
19.03.2020 09:50
[#215]
Re: Akiko 32
@juen, post #214
W sys:Prefs/Env-Archive/MMU-Configuration zakomentować dwie linie
;VA2000
For 28014 1 SetCacheMode {base} 0x10000 Valid CacheInhibit IOSpace
For 28014 1 SetCacheMode {base+0x10000} {size-0x10000} Valid CacheInhibit NonSerial Imprecise
na
;VA2000
;For 28014 1 SetCacheMode {base} 0x10000 Valid CacheInhibit IOSpace
;For 28014 1 SetCacheMode {base+0x10000} {size-0x10000} Valid CacheInhibit NonSerial Imprecise
Ostatnia aktualizacja: 19.03.2020 09:51:36 przez swinkamor12
Ostatnia aktualizacja: 19.03.2020 09:51:49 przez swinkamor12
;VA2000
For 28014 1 SetCacheMode {base} 0x10000 Valid CacheInhibit IOSpace
For 28014 1 SetCacheMode {base+0x10000} {size-0x10000} Valid CacheInhibit NonSerial Imprecise
na
;VA2000
;For 28014 1 SetCacheMode {base} 0x10000 Valid CacheInhibit IOSpace
;For 28014 1 SetCacheMode {base+0x10000} {size-0x10000} Valid CacheInhibit NonSerial Imprecise
Ostatnia aktualizacja: 19.03.2020 09:51:36 przez swinkamor12
Ostatnia aktualizacja: 19.03.2020 09:51:49 przez swinkamor12
30.04.2020 09:37
[#219]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
Istnienie trybu planarnego 8-bit w AGA ma o tyle sens aby zachować ten sam sposób operowania na danych co w poprzednich modelach chipsetu i w zasadzie to tyle bo ani wydajnościowo nie jest to optymalne rozwiązanie ani tym bardziej dla programisty. Blitter można by używać w dokładnie taki sam sposób w trybie chunky co planarnym tylko było by to znacznie prostsze i wydajniejsze.
Akiko z CD32 nie ma nic wspólnego z trybem chunky bo to koślawa proteza która robi konwersję C2P a same CD32 to powinno dostać trochę fast ramu bo tutaj by najwięcej zyskało, także w kwestii konwersji C2P. W ogóle mi to wygląda na to że Commodore nie zrobiło dla Amigi dokładnie nic. Wszystko co dobre w tym komputerze zostało zrobione za czasów Amiga Inc. a w Commodore (jak i w innych firmach po Commore...
) panowie w garniturach skoncentrowali się na odcinaniu kuponów...
Zobacz sobie ile operacji musisz zrobić aby napisać prostą funkcję putPixel(x,y,c) w trybie chunky 8-bit a w trybie planarnym 8-bit. Do tego stopnia jest to różnica że ja bym nawet poszedł tak daleko i powiedział że od samego początku już w OCS powinien być tryb Chunky. Oczywiście wtedy nic nie stało by na przeszkodzie aby dać 256 kolorów i wtedy to faktycznie można by mówić o forward thinkinu na najbliższe 10 lat.
@moderacja
Proszę oznaczyć mój post jako offtop. Dziękuję
Akiko z CD32 nie ma nic wspólnego z trybem chunky bo to koślawa proteza która robi konwersję C2P a same CD32 to powinno dostać trochę fast ramu bo tutaj by najwięcej zyskało, także w kwestii konwersji C2P. W ogóle mi to wygląda na to że Commodore nie zrobiło dla Amigi dokładnie nic. Wszystko co dobre w tym komputerze zostało zrobione za czasów Amiga Inc. a w Commodore (jak i w innych firmach po Commore...
) panowie w garniturach skoncentrowali się na odcinaniu kuponów...Zobacz sobie ile operacji musisz zrobić aby napisać prostą funkcję putPixel(x,y,c) w trybie chunky 8-bit a w trybie planarnym 8-bit. Do tego stopnia jest to różnica że ja bym nawet poszedł tak daleko i powiedział że od samego początku już w OCS powinien być tryb Chunky. Oczywiście wtedy nic nie stało by na przeszkodzie aby dać 256 kolorów i wtedy to faktycznie można by mówić o forward thinkinu na najbliższe 10 lat.
@moderacja
Proszę oznaczyć mój post jako offtop. Dziękuję
30.04.2020 09:46
[#220]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@XoR, post #219
Zobacz sobie ile operacji musisz zrobić aby napisać prostą funkcję putPixel(x,y,c) w trybie chunky 8-bit a w trybie planarnym 8-bit. Do tego stopnia jest to różnica że ja bym nawet poszedł tak daleko i powiedział że od samego początku już w OCS powinien być tryb Chunky. Oczywiście wtedy nic nie stało by na przeszkodzie aby dać 256 kolorów i wtedy to faktycznie można by mówić o forward thinkinu na najbliższe 10 lat.
To nie takie proste. Po pierwsze tak jak pisałem kiedyś, koszt zamortyzowany operacji putPixel() jest identyczny. Koszt zamortyzowany, to koszt ciągu operacji, a nie pojedynczej.
Otóż jeżeli chcemy zapisać 32 piksele, możemy to zrobić w od 1 do 8 instrukcji w trybie planar. Zaś w trybie chunky 32 piksele to zawsze 8 instrukcji.
Niby zapisanie pojedynczego piksela chunky jest nieefektywne w trybie planar, bo to od 1 do 8 operacji. Ale zapis 32 pikseli chunky w trybie planar to również od 1 do 8 operacji! Widzisz?
To koszt zamortyzowany.Akiko z CD32 nie ma nic wspólnego z trybem chunky bo to koślawa proteza która robi konwersję C2P a same CD32 to powinno dostać trochę fast ramu bo tutaj by najwięcej zyskało, także w kwestii konwersji C2P. W ogóle mi to wygląda na to że Commodore nie zrobiło dla Amigi dokładnie nic. Wszystko co dobre w tym komputerze zostało zrobione za czasów Amiga Inc. a w Commodore (jak i w innych firmach po Commore... ) panowie w garniturach skoncentrowali się na odcinaniu kuponów...
Wydaje mi się, że nie korzystałeś z CD32 i chunky, bo to naprawdę jest szybkie. W praktyce sprawuje się bardzo dobrze.
30.04.2020 11:55
[#221]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@XoR, post #219
W ogóle mi to wygląda na to że Commodore nie zrobiło dla Amigi dokładnie nic. Wszystko co dobre w tym komputerze zostało zrobione za czasów Amiga Inc. a w Commodore (jak i w innych firmach po Commore...
Ekipa Amiga Inc zaprojektowała fajny komputer. Commodore wiedziało jak go zrobić tanio. Popatrz na płytę A1000 a potem na A500 i A2000 rev. 4.
30.04.2020 14:37
[#223]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #220
Problem w tym że najczęściej nie chcemy zapisywać po 32 piksele ale jeden. Żaden Wolf3D, Doom, Gloom, Descent i podobne nie rysują grafiki po 32 piksele na raz. Po 32 piksele na raz to można zrobić czyszczenie ekranu albo kopiowanie tła.
Bitplany nie są przeznaczone do rysowania pojedynczych pikseli. Wymyślono je po to aby szybko kopiować bloki o szerokości 16 czy 32 pikseli w niedużej liczbie kolorów czego typowym zastosowaniem są kafelki w grach platformowych. Przy okazji można uzyskać prosto efekty warstw obrazu (Dual Playfield) oraz przezroczystości planów przez odpowiednie ustawienie palety kolorów. W czasach gdy pamięci były bardzo drogie i typowy komputer nie posiadał jej zbyt wiele, bitplany były ewidentną korzyścią.
Dla mnie w OCS zabrakło spakowanych formatów chunky np. dwa piksele 4-bit w jednym bajcie.
Bitplany nie są przeznaczone do rysowania pojedynczych pikseli. Wymyślono je po to aby szybko kopiować bloki o szerokości 16 czy 32 pikseli w niedużej liczbie kolorów czego typowym zastosowaniem są kafelki w grach platformowych. Przy okazji można uzyskać prosto efekty warstw obrazu (Dual Playfield) oraz przezroczystości planów przez odpowiednie ustawienie palety kolorów. W czasach gdy pamięci były bardzo drogie i typowy komputer nie posiadał jej zbyt wiele, bitplany były ewidentną korzyścią.
Dla mnie w OCS zabrakło spakowanych formatów chunky np. dwa piksele 4-bit w jednym bajcie.
30.04.2020 15:53
[#224]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@] SKOLMAN_MWS ˇ agrEssOr [, post #222
@SKOLMAN_MWS @Kefir_Union
Ale ja z Panami się zgadzam. Tylko czemu od razu podawać gry 3D?
No niestety, kosztem planar jest niemożność zmienienia wszystkich bitów w pikselu jedną operacją. Trzeba rozkładać sobie zapis na bitplany.
Jednakże umiejętnie przygotowując sobie grafikę, możemy wklejać po jednym pikselu. Jednak jako że najefektywniejszy zapis do pamięci CHIP to 16/32 piksele, zamiast 1 w Chunky należy dane buforować.
Przecież gdyby np. GeForce GTX 1080 nie buforował i miał zapis 1-bitowy to chyba by nie dał rady. Dlatego stosuje się zapis wielobitowy.
No, przykładowo tekstura musi być w jakimś formacie. Ona musi mieć szerokość i składać się z grupy pikseli.
Najwygodniej jest stosować teksturę w formacie planar. Wtedy kopiowanie jest proste.
Jeżeli zaś potrzebujemy więcej bitów zmienić możemy składać bitplany obok siebie, np. tak:
Złoży liniowo dwa bitplany do jednego rejestru. Teraz piksele są dostępne w ten sposób, tylko że odpowiednie bity są oddzielone od siebie, ale nadal w jednym rejestrze.
Możemy tak składać dalej aż do 8 pikseli w 4 bitplanach lub 4 pikseli w 8 bitplanach. Jeżeli zależy nam tylko na 4 pikselach, złożymy to w 8 operacjach (2 operacje na piksel!).
W takim formacie np. transpozycja grafiki jest prosta bo kopiujemy zawartość 1 rejestru. Więc jak ktoś chce wklejać piksele pionowo też może!
Wklejenie tego do pamięci CHIP może odbywać się na wartościach 4 pikseli, lub po złożeniu w większe bloki. Jeżeli zapisujemy 4 piksele będziemy potrzebować znów 8 operacji.
Podałem sposób na taką manipulację grafiki, której koszt to 2N, gdzie N to liczba pikseli chunky (pełnych 8-bitowych). Tylko, że wykorzystuje 1/8 pełnej przepustowości planar.
Jak ktoś nie wierzy niech sprawdzi sam.
Ale ja z Panami się zgadzam. Tylko czemu od razu podawać gry 3D?
No niestety, kosztem planar jest niemożność zmienienia wszystkich bitów w pikselu jedną operacją. Trzeba rozkładać sobie zapis na bitplany.
Jednakże umiejętnie przygotowując sobie grafikę, możemy wklejać po jednym pikselu. Jednak jako że najefektywniejszy zapis do pamięci CHIP to 16/32 piksele, zamiast 1 w Chunky należy dane buforować.
Przecież gdyby np. GeForce GTX 1080 nie buforował i miał zapis 1-bitowy to chyba by nie dał rady. Dlatego stosuje się zapis wielobitowy.
No, przykładowo tekstura musi być w jakimś formacie. Ona musi mieć szerokość i składać się z grupy pikseli.
Najwygodniej jest stosować teksturę w formacie planar. Wtedy kopiowanie jest proste.
Jeżeli zaś potrzebujemy więcej bitów zmienić możemy składać bitplany obok siebie, np. tak:
MOVE.W (A0)+,D0 SWAP D0 MOVE.W (A1)+,D0
Złoży liniowo dwa bitplany do jednego rejestru. Teraz piksele są dostępne w ten sposób, tylko że odpowiednie bity są oddzielone od siebie, ale nadal w jednym rejestrze.
Możemy tak składać dalej aż do 8 pikseli w 4 bitplanach lub 4 pikseli w 8 bitplanach. Jeżeli zależy nam tylko na 4 pikselach, złożymy to w 8 operacjach (2 operacje na piksel!).
a7...... a6...... a5...... a4...... a3...... a2...... a1...... a0......
W takim formacie np. transpozycja grafiki jest prosta bo kopiujemy zawartość 1 rejestru. Więc jak ktoś chce wklejać piksele pionowo też może!
Wklejenie tego do pamięci CHIP może odbywać się na wartościach 4 pikseli, lub po złożeniu w większe bloki. Jeżeli zapisujemy 4 piksele będziemy potrzebować znów 8 operacji.
Podałem sposób na taką manipulację grafiki, której koszt to 2N, gdzie N to liczba pikseli chunky (pełnych 8-bitowych). Tylko, że wykorzystuje 1/8 pełnej przepustowości planar.
Jak ktoś nie wierzy niech sprawdzi sam.
30.04.2020 16:12
[#226]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Phibrizzo, post #225
W każdym rejestrze masz liniowo ułożone bloki 4-pikselowe. Więc adresujesz sobie jeden taki blok za pomocą starszych bitów pozycji, a następnie wyciągasz piksel za pomocą odpowiedniej maski przesuniętej o 0-3 bity, w zależności od najmłodszych 2 bitów pozycji piksela.
Przy czym można kopiować do 4 pikseli na raz w jednym bloku, z czego też można skorzystać i przyśpieszyć dodatkowo kopiowanie, gdy jest dosunięte.
Przy czym można kopiować do 4 pikseli na raz w jednym bloku, z czego też można skorzystać i przyśpieszyć dodatkowo kopiowanie, gdy jest dosunięte.
30.04.2020 17:46
[#227]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #224
Najwygodniej jest stosować teksturę w formacie planar. Wtedy kopiowanie jest proste.
No właśnie operowanie w trybie planarnym w ogóle nie jest proste
Mając planarną pamieć video musisz się martwić o to że adresowanie pamięci jest w bajtach więc już 7 na 8 przypadków musisz kombinować z wyrównywaniem i wtedy nawet bez koloru przeźroczystości masz potrzebę robić odczyty z pamięci video.
W przypadku chunky nie musisz nigdy nic kombinować bo masz piksele zawsze wyrównane do adresów pamięci i możesz kopiować całe słowa.
Jak masz kolor przeźroczystości to w chunky albo jak jesteś bardzo leniwy to robisz rysowanie bajt po bajcie i nie musisz nigdy czytać zawartości ekranu po którym rysujesz albo czytasz np. całe 32-bit słowa tekstury i ekranu, w rejestrach sprawdzasz które bajty podmienić i zapisujesz zawartość ekranu po 4 piksele. Dla 16bit to już chyba lepiej na bajtach to robić, przynajmniej zapisy do pamięci video aby uniknąć jej czytania.
W trybie planarnym kolor przeźroczystości oznacza 8 odczytów tekstury, 8 operacji aby wygenerować maskę bitową przeźroczystości, 8 odczytów zawartości pamięci video, 8 operacji AND na masce bitowej i bitplanie teksturze, 8 inwersji maski, 8 operacji na masce i bitplanie pamięci video, 8 operacji połączenia przetworzonych wcześniej tekstury i pamięci video, no i 8 na zapisanie tego. Jak masz piksele wyrównane bo jak nie masz (7 na 8 przypadków) to czytasz odpowiednio więcej i dochodzą operacje przesunięć bitowych i generalnie część operacji się podwaja. Zapewne da się to trochę zoptymalizować, szczególnie dla szerszych bitmap ale i tak ani to nigdy nie będzie w pełni optymalne ani proste w zaprogramowaniu.
Podajesz przykłady zalet trybu planarnego które w ogóle nie odnoszą się do 8bit tylko do 2-bit i ignorujesz problem wyrównania rysowanej bitmapy do pamięci video. I tak, w trybach gdzie mamy czarny i biały (tudzież ogólnie kolor A i kolor B) i nic więcej do martwienia się w danym obszarze ekranu reprezentowanie jednego piksela jednym bitem ma dość duży sens i tutaj zgoda. Tylko jeszcze raz: mówimy o 8-bit i 255/256 kolorach a nie 1-bit i 2 kolorach
No właśnie operowanie w trybie planarnym w ogóle nie jest proste
Mając planarną pamieć video musisz się martwić o to że adresowanie pamięci jest w bajtach więc już 7 na 8 przypadków musisz kombinować z wyrównywaniem i wtedy nawet bez koloru przeźroczystości masz potrzebę robić odczyty z pamięci video.
W przypadku chunky nie musisz nigdy nic kombinować bo masz piksele zawsze wyrównane do adresów pamięci i możesz kopiować całe słowa.
Jak masz kolor przeźroczystości to w chunky albo jak jesteś bardzo leniwy to robisz rysowanie bajt po bajcie i nie musisz nigdy czytać zawartości ekranu po którym rysujesz albo czytasz np. całe 32-bit słowa tekstury i ekranu, w rejestrach sprawdzasz które bajty podmienić i zapisujesz zawartość ekranu po 4 piksele. Dla 16bit to już chyba lepiej na bajtach to robić, przynajmniej zapisy do pamięci video aby uniknąć jej czytania.
W trybie planarnym kolor przeźroczystości oznacza 8 odczytów tekstury, 8 operacji aby wygenerować maskę bitową przeźroczystości, 8 odczytów zawartości pamięci video, 8 operacji AND na masce bitowej i bitplanie teksturze, 8 inwersji maski, 8 operacji na masce i bitplanie pamięci video, 8 operacji połączenia przetworzonych wcześniej tekstury i pamięci video, no i 8 na zapisanie tego. Jak masz piksele wyrównane bo jak nie masz (7 na 8 przypadków) to czytasz odpowiednio więcej i dochodzą operacje przesunięć bitowych i generalnie część operacji się podwaja. Zapewne da się to trochę zoptymalizować, szczególnie dla szerszych bitmap ale i tak ani to nigdy nie będzie w pełni optymalne ani proste w zaprogramowaniu.
Podajesz przykłady zalet trybu planarnego które w ogóle nie odnoszą się do 8bit tylko do 2-bit i ignorujesz problem wyrównania rysowanej bitmapy do pamięci video. I tak, w trybach gdzie mamy czarny i biały (tudzież ogólnie kolor A i kolor B) i nic więcej do martwienia się w danym obszarze ekranu reprezentowanie jednego piksela jednym bitem ma dość duży sens i tutaj zgoda. Tylko jeszcze raz: mówimy o 8-bit i 255/256 kolorach a nie 1-bit i 2 kolorach
30.04.2020 18:02
[#228]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@XoR, post #227
W trybie planarnym przeźroczystość to najłatwiejsza z operacji, jeżeli masz przygotowaną maskę. A rozumiem, że mówimy o 2D, czyli o BOBach - obiektach Blittera. Maskę dla każdego BOBa robi się raz, a później wklejamy robiąc tzw. "Cookie-Cut", czyli Blitując przez maskę.
Wyrównanie masz - bo "mój format" grafiki jest ustawiony liniowo. I dotyczy 8 bitów, co przedstawiłem. Transpozycja i dowolna inna operacja na 1 pikselu kosztuje wtedy 1. A wklejanie zaledwie 2 * ilość pikseli (dla 4 pikseli jest to 8 wklejeń). Jak widać można niwelować narzut, dzięki amortyzacji.
Przy czym jeżeli chcemy naturalne bajtowe chunky szybko, to należy składać bitplany w innej kolejności (co nie stanowi żadnego problemu), a potem złożyć to w 2 operacjach:
Ilustracja:
Możemy tak składać do 4 pikseli równocześnie. W drugą stronę odbywa się to w analogiczny sposób.
Z takimi pikselami możemy robić dokładnie to co z chunky. Porównywać, dodawać wartość do indeksu piksela, mapować, przestawiać itd.
W praktyce odczyt grafiki nie będzie nam potrzebny, tylko zapis.
Wyrównanie masz - bo "mój format" grafiki jest ustawiony liniowo. I dotyczy 8 bitów, co przedstawiłem. Transpozycja i dowolna inna operacja na 1 pikselu kosztuje wtedy 1. A wklejanie zaledwie 2 * ilość pikseli (dla 4 pikseli jest to 8 wklejeń). Jak widać można niwelować narzut, dzięki amortyzacji.
Przy czym jeżeli chcemy naturalne bajtowe chunky szybko, to należy składać bitplany w innej kolejności (co nie stanowi żadnego problemu), a potem złożyć to w 2 operacjach:
Ilustracja:
a7...... a3...... a6...... a2...... a5...... a1...... a4...... a0...... a7..a5.. a3..a1.. a6..a4.. a2..a0.. a7a6a5a4 a3a2a1a0
Możemy tak składać do 4 pikseli równocześnie. W drugą stronę odbywa się to w analogiczny sposób.
Z takimi pikselami możemy robić dokładnie to co z chunky. Porównywać, dodawać wartość do indeksu piksela, mapować, przestawiać itd.
W praktyce odczyt grafiki nie będzie nam potrzebny, tylko zapis.
30.04.2020 19:24
[#229]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #228
"BOB" 8bit z oddzielnie przygotowaną maską zajmuje już 9 bitów na piksel czyli z oszczędności pamięci w trybie planar robi się dodatkowy narzut na dodatkową maskę którą jeszcze trzeba odczytać z pamięci
Wyrównanie o którym mówię to nie problem formatu grafiki bo tutaj zawsze wszystko będzie wyrównane tylko formatu pamięci video. Nie ważne jak sobie poustawiasz dane to jak chcesz narysować coś co jest nie wyrównane do bajtu to musisz zrobić jeden dodatkowy zapis/odczyt niż wynikało by to z ilości danych do skopiowania. Nawet jeśli kopiowanie i wyrównanie robi za Ciebie Blitter (w sumie to nie wiem, nie programowałem go) to nie robi to specjalnie różnicy bo i tak te wszystkie operacje muszą być wykonane i dostępy do pamięci muszą się odbyć.
"Amortyzacja" czy sprytna optymalizacja nie mówię że nie działa tylko że jest to takie kombinowanie jak niepodkuty koń pod górkę w środek zimy. I tak nie osiągniesz lepszego efektu niż miałbyś na chunky tylko musisz poświęcić mnóstwo czasu na najpierw w ogóle zrobienie działającego kodu a potem jego optymalizację
Wyrównanie o którym mówię to nie problem formatu grafiki bo tutaj zawsze wszystko będzie wyrównane tylko formatu pamięci video. Nie ważne jak sobie poustawiasz dane to jak chcesz narysować coś co jest nie wyrównane do bajtu to musisz zrobić jeden dodatkowy zapis/odczyt niż wynikało by to z ilości danych do skopiowania. Nawet jeśli kopiowanie i wyrównanie robi za Ciebie Blitter (w sumie to nie wiem, nie programowałem go) to nie robi to specjalnie różnicy bo i tak te wszystkie operacje muszą być wykonane i dostępy do pamięci muszą się odbyć.
"Amortyzacja" czy sprytna optymalizacja nie mówię że nie działa tylko że jest to takie kombinowanie jak niepodkuty koń pod górkę w środek zimy. I tak nie osiągniesz lepszego efektu niż miałbyś na chunky tylko musisz poświęcić mnóstwo czasu na najpierw w ogóle zrobienie działającego kodu a potem jego optymalizację
30.04.2020 19:34
[#230]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #220
To nie takie proste. Po pierwsze tak jak pisałem kiedyś, koszt zamortyzowany operacji putPixel() jest identyczny. Koszt zamortyzowany, to koszt ciągu operacji, a nie pojedynczej.Koszt zamortyzowany to teoretyczne pojęcie, które w praktyce nie jest do osiągnięcia.
Otwieramy okienko w trybie 256-kolorowym i mamy do narysowania 32 piksele o dowolnych współrzędnych mieszczących się w oknie i dowolnym indeksie koloru. W trybie chunky zawsze poradzimy sobie za pomocą 32 instrukcji MOVE.B. W trybie planarnym prawie nigdy nie zapalisz tych pikseli 32 instrukcjami, najczęściej będzie ich kilkaset. Jeszcze gorzej będzie gdy przyjmiemy założenie, że stawiamy piksele na już istniejącym tle bez niszczenia go.
Twórców Amigi usprawiedliwiają niewyobrażalne dzisiaj ceny pamięci [chip]. Ekran 8-bit chunky w High Resie bez przeplotu (640×256) zajmuje 160 kB pamięci, czyli ⅓ chipu w standardowej pięćsetce. No a AGA musiała być kompatybilna wstecz, więc tak już zostało...
30.04.2020 19:54
[#231]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Krashan, post #230
Koszt zamortyzowany to teoretyczne pojęcie, które w praktyce nie jest do osiągnięcia.
Proszę policzyć ile poniższy kod ma instrukcji. Wkleja 8 pikseli w 4 bitplanach w przedstawionym przeze mnie wcześniej formacie:
; Wklejenie 8 pikseli move.b d0,(a1) lsr.w #8,d0 move.b d0,(a2) swap d0 move.b d0,(a3) lsr.w #8,d0 move.b d0,(a4)
~8 instrukcji na 8 4-bitowych pikseli to chyba OK.
Cały czas przechowujemy piksele w tym formacie. Ustawienie jednego pełnego piksela (do 8 pikseli równocześnie) w rejestrze to wtedy będą dwie instrukcje MOVE.L na rejestrze danych.
Takie buforowanie jest konieczne ze względu na rozbicie bitplanów, ale dalej są to zapisy 8-bitowe. Koszt zredukowany do 2n to dużo lepszy niż 8n, co nie?
P.S. Zamortyzowany koszt nie jest pojęciem abstrakcyjnym. Odnosi się on do wielu zagadnień informatycznych, nawet sortowania, znajdywania wartości w tablicy, odkładania na stos itd.
Ostatnia aktualizacja: 30.04.2020 20:03:46 przez Hexmage960
30.04.2020 20:12
[#232]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #231
~8 instrukcji na 8 4-bitowych pikseli to chyba OK.
Tak ale to nie jest jeden dowolnie wybrany piksel.
Jak mam obrazek w pamięci video i chcę postawić piksel na nim to nie chcę zapisać 8 pikseli tylko jeden a więc muszę odczytać najpierw 8 pikseli w miejscu gdzie chcę piksel, wygenerować nową zawartość tych 8 pikseli z uwzględnieniem koloru mojego nowego piksela i to potem wrzucić to do pamięci w sposób który przedstawiłeś tylko dla wszystkich 8 bitplanów.
BTW. Polecam poprogramować na jakimś innym sprzęcie dla odmiany. Zobaczysz zarówno wady Amigi jak i jej zalety i będziesz miał lepszy osąd komputerowej rzeczywistości
Ostatnia aktualizacja: 30.04.2020 20:13:40 przez XoR
Tak ale to nie jest jeden dowolnie wybrany piksel.
Jak mam obrazek w pamięci video i chcę postawić piksel na nim to nie chcę zapisać 8 pikseli tylko jeden a więc muszę odczytać najpierw 8 pikseli w miejscu gdzie chcę piksel, wygenerować nową zawartość tych 8 pikseli z uwzględnieniem koloru mojego nowego piksela i to potem wrzucić to do pamięci w sposób który przedstawiłeś tylko dla wszystkich 8 bitplanów.
BTW. Polecam poprogramować na jakimś innym sprzęcie dla odmiany. Zobaczysz zarówno wady Amigi jak i jej zalety i będziesz miał lepszy osąd komputerowej rzeczywistości
Ostatnia aktualizacja: 30.04.2020 20:13:40 przez XoR
30.04.2020 20:15
[#233]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #231
Dlaczego ciągle zjeżdżasz niżej z przykładami niż 8-bitplanów? Kolegów raczej interesują operacje na 256 kolorowych pikselach, a nie 16-tu i w tym kontekście dyskutują. Przypomina mi się wywiad z pewną posłanką, która na zadawane pytania udzielała szerokich i wyczerpujących odpowiedzi, szkoda tylko, że... prawie na temat.
Ostatnia aktualizacja: 30.04.2020 20:16:34 przez sanjyuubi
Ostatnia aktualizacja: 30.04.2020 20:16:34 przez sanjyuubi
30.04.2020 20:35
[#234]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@XoR, post #232
Jak mam obrazek w pamięci video i chcę postawić piksel na nim to nie chcę zapisać 8 pikseli tylko jeden
Cały czas przechowujemy pamięć Video w tym moim formacie. Więc jeżeli chcesz nanieść zmiany buforujesz odpowiednie słowo pamięci video w rejestrze, zapisujesz wybrane piksele (może być 1) w rejestrze (nie pamięci), a następnie zapisujesz do bitplanów.
Krok buforowania jest konieczny, ale nie powinien on odwracać uwagi od istoty zagadnienia.
Ostatnia aktualizacja: 30.04.2020 20:38:38 przez Hexmage960
30.04.2020 20:38
[#235]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@sanjyuubi, post #233
Dlaczego ciągle zjeżdżasz niżej z przykładami niż 8-bitplanów? Kolegów raczej interesują operacje na 256 kolorowych pikselach, a nie 16-tu i w tym kontekście dyskutują.
Zjechałem do 4 bitplanów bo w istocie jak jest 8 bitplanów, to wtedy mamy 4 piksele, które mieszczą się w rejestrze i zapis do pamięci CHIP jest troszkę bardziej złożony.
Ale proszę zauważyć, że cały czas pisałem o tym, że operację trzeba powtórzyć dla drugiej czwórki bitplanów.
30.04.2020 21:47
[#236]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #235
Ale ty w każdym wątku, w którym pada słowo chunky, piszesz w kółko to samo o zaletach plannar i podajesz jak to się ładnie zapisuje grupę pikseli, kiedy zainteresowanego zapisem chunky interesuje bezpośredni dostęp do pojedyńczego piksela, a to przecież jedna instrukcja zapisu, a w plannar to ile będzie instrukcji dla piksela 8 planowego?
Może zamiast w kółko wałkować ten sam temat, może ktoś wymyśli zadania (np. modyfikacja pojedynczego piksela, modyfikacja 32 pikseli co drugi w ciągu 64 pikseli, kopiowanie bloków z maską, itd) związane z modyfikacją pikseli, a zwolennicy chunky i plannar przedstawią swoje algorytmy dla porównania.
Ostatnia aktualizacja: 30.04.2020 21:52:46 przez sanjyuubi
Może zamiast w kółko wałkować ten sam temat, może ktoś wymyśli zadania (np. modyfikacja pojedynczego piksela, modyfikacja 32 pikseli co drugi w ciągu 64 pikseli, kopiowanie bloków z maską, itd) związane z modyfikacją pikseli, a zwolennicy chunky i plannar przedstawią swoje algorytmy dla porównania.
Ostatnia aktualizacja: 30.04.2020 21:52:46 przez sanjyuubi
30.04.2020 21:54
[#237]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #234
Cały czas przechowujemy pamięć Video w tym moim formacie.
Dzieki czemu marnujesz pamiec, bo trzymasz dane w twoim buforze i jednoczesnie mamy dane w bitmapie.
Ja rozumiem ze probujesz z uporem godnym pochwaly wykazac nam tutaj jaki tryb planar jest wspanialy, ale sprobuj popracowac troche nad obrazami w formacie chunky i zobacz na wlasne oczy w ktorych momentach tryb chunky ma niezaprzeczalne zalety.
Twoje wywody przypominaja troche algorytm quick sort. Jego koszt zamortyzowany wlasnie to O(n*log(n)), ale w najgorszym wypadku jest to O(n*n). W przypadku trybu planar jest dokladnie na odwrot - owszem, sa przypadki szczegolne kiedy tryb planar bedzie co najmniej tak samo optymalny jak tryb chunky, jednak w wiekszosci przypadkow tutaj dyskutowanych (chocby taki random access), tryb planarny bedzie zdecydowanie gorszy. Owe gorsze "momenty" starasz sie jednak ignorowac ciagle podnoszac, ze w szczegolnych przypadkach planar moze byc jednak dobry. Taka dyskusja jest bez sensu, nie uwazasz?
30.04.2020 22:07
[#238]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@mschulz, post #237
Twoje wywody przypominaja troche algorytm quick sort. Jego koszt zamortyzowany wlasnie to O(n*log(n)), ale w najgorszym wypadku jest to O(n*n).
Ma kolega na myśli koszt średni i pesymistyczny. To zupełnie co innego niż koszt zamortyzowany.
Tutaj koszt jest stały, tzn. średni i pesymistyczny są takie same.
Dzieki czemu marnujesz pamiec, bo trzymasz dane w twoim buforze i jednoczesnie mamy dane w bitmapie.
Ale przecież to są dane chunky w pamięci FAST. Przecież normalnie trzeba je gdzieś przechować, prawda?
Ostatnia aktualizacja: 30.04.2020 22:12:21 przez Hexmage960
30.04.2020 22:13
[#239]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@Hexmage960, post #238
Ma kolega na myśli koszt średni i pesymistyczny. To zupełnie co innego niż koszt zamortyzowany.
Tutaj koszt jest stały.
Ale ty w zadnym miejscu nie udowodniles ze koszt zamortyzowany w przypadku planar jest taki sam jak w przypadku chunky, bo to bardzo zalezy od konkretnego przypadku. Sa takie w ktorych koszt obu bedzie taki sam, sa takie gdzie planar przy tej samej glebi kolorow bedzie wielokrotnie wolniejszy.
Ale przecież to są dane chunky w pamięci FAST. Przecież normalnie trzeba je gdzieś przechować, prawda?
Tak, w przypadku trybu chnky tak jest. Ale w trybie planar chcielibysmy chyba pracowac bezposrednio na bitmapie, co? Trzymajac dane w dodatkowym buforze mozna od razu wykorzystac tryb chunky, bez zadnych dziwnych hybryd proponowanych przez ciebie.
Jak juz koledzy sugerowali - popracuj z troche wiecej z danymi w trybie chunky, to bedziesz mogl sie w bardziej wywazony sposob na temat obu wypowiedziec.
30.04.2020 22:29
[#240]
Re: MorphOS oczami użytkownika OS4 - pytania i odpowiedzi
@mschulz, post #239
Ale ty w zadnym miejscu nie udowodniles ze koszt zamortyzowany w przypadku planar jest taki sam jak w przypadku chunky, bo to bardzo zalezy od konkretnego przypadku
O tym pisałem w pierwszym poście na ten temat.
Koszt zamortyzowany to koszt szeregu operacji, w których jedne operacje mogą wpływać na inne i tym samym sumaryczny koszt jest inny (mniejszy) niż gdybyśmy wykonywali te operacje pojedynczo.
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.
Jednak jeżeli dodamy funkcję buforowania, która polega na umieszczeniu pikseli w rejestrze w przedstawiony sposób, to koszt zapisania n pikseli jest już O(n). Następnie opróżnienie bufora i zapis w pamięci to już O(d), bo tyle jest zapisów ile bitplanów.
A zapewniam, że O(n)+O(d) < O(d*n)
Jak juz koledzy sugerowali - popracuj z troche wiecej z danymi w trybie chunky, to bedziesz mogl sie w bardziej wywazony sposob na temat obu wypowiedziec.
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.