09.02.2019 12:39
[#126]
Re: W temacie mojej procedury konwersji c2p
@Arturo, post #124
Tak jak napisałem, procedura jest autorska i ma mi pomóc zaimplementować szybką funkcję typu WritePixelArray8() w mojej grze Magazyn.
Adaptowanie mojej procedury c2p do DoomAttack, czy Glooma nie jest obecnie dla mnie ważne, ponieważ trzeba by ją zupełnie przerabiać.
Zobaczycie efekt działania procedury w grze Magazyn. Planuję kilka efektów na pikselach.
Ostatnia aktualizacja: 09.02.2019 12:41:30 przez Hexmage960
Adaptowanie mojej procedury c2p do DoomAttack, czy Glooma nie jest obecnie dla mnie ważne, ponieważ trzeba by ją zupełnie przerabiać.
Zobaczycie efekt działania procedury w grze Magazyn. Planuję kilka efektów na pikselach.
Ostatnia aktualizacja: 09.02.2019 12:41:30 przez Hexmage960
09.02.2019 13:46
[#128]
Re: W temacie mojej procedury konwersji c2p
@recedent, post #127
Nie potrzebuje przerobienia do 3D. Jest to najzwyczajniejsza procedura rysowania pikseli na Amidze. Jak kto jej użyje - do 2D, czy 3D to jego sprawa.
Potrzebuje przerobienia pod te konkretne gry Gloom i DoomAttack. Jestem pewien co do Glooma, jego c2p inaczej rozdysponowuje rejestrami CPU.
Dodatkowo nie wiadomo jak modyfikacje wpłynęłyby na wydajność.
Ja na razie nie zawracam sobie tym głowy, procedurę będę używać we własnym zakresie do rysowania grafiki na ekranie.
P.S. Właśnie skorygowałem kilka drobnych błędów w numeracji rejestrów, przepisałem procedurkę do Amigi i przetestowałem. Działa prawidłowo.
Z ciekawostek to dowiedziałem się (uświadomiłem sobie), że skoki bajtowe są z zakresu -128 do 127, bo to liczba ze znakiem. Dziwiłem się, że BLT.S nie chce przejść.
Ale cała procedura zamyka się w mniej niż 256 bajtów, więc w cache się zmieści.
Teraz tylko opakować by zapisywała do struktury BitMap i gotowe.
Zauważcie, że procedura zapisuje całą szerokość danej bitmapy. Do rozlokowania utworzonych bitmap na ekranie mogę użyć Blittera. To przyniesie oszczędności, bo nie muszę konwertować całego ekranu.
Jeszcze muszę dorobić lekko zmodyfikowaną wersję procedury by zapisywała do pozostałej czwórki bitplanów 4-7. Wystarczy zmodyfikować kilka instrukcji. Ale Magazyn ma działać na OCS, czyli w 4 lub 5 bitplanach, więc jeszcze tym się nie zająłem.
Ostatnia aktualizacja: 09.02.2019 14:02:36 przez Hexmage960
Potrzebuje przerobienia pod te konkretne gry Gloom i DoomAttack. Jestem pewien co do Glooma, jego c2p inaczej rozdysponowuje rejestrami CPU.
Dodatkowo nie wiadomo jak modyfikacje wpłynęłyby na wydajność.
Ja na razie nie zawracam sobie tym głowy, procedurę będę używać we własnym zakresie do rysowania grafiki na ekranie.
P.S. Właśnie skorygowałem kilka drobnych błędów w numeracji rejestrów, przepisałem procedurkę do Amigi i przetestowałem. Działa prawidłowo.
Z ciekawostek to dowiedziałem się (uświadomiłem sobie), że skoki bajtowe są z zakresu -128 do 127, bo to liczba ze znakiem. Dziwiłem się, że BLT.S nie chce przejść.
Ale cała procedura zamyka się w mniej niż 256 bajtów, więc w cache się zmieści.Teraz tylko opakować by zapisywała do struktury BitMap i gotowe.
Zauważcie, że procedura zapisuje całą szerokość danej bitmapy. Do rozlokowania utworzonych bitmap na ekranie mogę użyć Blittera. To przyniesie oszczędności, bo nie muszę konwertować całego ekranu.
Jeszcze muszę dorobić lekko zmodyfikowaną wersję procedury by zapisywała do pozostałej czwórki bitplanów 4-7. Wystarczy zmodyfikować kilka instrukcji. Ale Magazyn ma działać na OCS, czyli w 4 lub 5 bitplanach, więc jeszcze tym się nie zająłem.
Ostatnia aktualizacja: 09.02.2019 14:02:36 przez Hexmage960
09.02.2019 20:41
[#129]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #128
Zrobiłem swój pierwszy efekt chunky. 
Traktujcie to jako pierwszy, realny sprawdzian mojej procedury.
Efekt jest bardzo prosty - ekran jest wypełniany kwadratami 64x64, które pojawiają się stopniowo. Kwadraty składają się z pikseli, które renderowane są na żywo.
Zamiast jednolitego koloru mogłaby być to tekstura. I tak chciałbym by było w grze Magazyn. Pamiętajcie, że jestem początkujący w te rzeczy.
Załączam archiwum z tym pierwszym efektem oraz kod źródłowy do podglądu.
Efekt trwa dosłownie kilka sekund. Publikuję, bo na pewno nie możecie doczekać się efektu pracy nad tą procedurą.
W grze Magazyn plansze najprawdopodobniej będą właśnie się tak pojawiać (lub w podobny sposób). Wówczas uporządkuję kolory według jasności.
Wymagania to Amiga OCS + system OS3.0.
http://coreprogramming.pl/c2p/Screen.c.txt
http://coreprogramming.pl/c2p/WPA.s.txt
http://coreprogramming.pl/c2p/Screen.lha
Traktujcie to jako pierwszy, realny sprawdzian mojej procedury.
Efekt jest bardzo prosty - ekran jest wypełniany kwadratami 64x64, które pojawiają się stopniowo. Kwadraty składają się z pikseli, które renderowane są na żywo.
Zamiast jednolitego koloru mogłaby być to tekstura. I tak chciałbym by było w grze Magazyn. Pamiętajcie, że jestem początkujący w te rzeczy.
Załączam archiwum z tym pierwszym efektem oraz kod źródłowy do podglądu.
Efekt trwa dosłownie kilka sekund.
Publikuję, bo na pewno nie możecie doczekać się efektu pracy nad tą procedurą.W grze Magazyn plansze najprawdopodobniej będą właśnie się tak pojawiać (lub w podobny sposób). Wówczas uporządkuję kolory według jasności.
Wymagania to Amiga OCS + system OS3.0.
http://coreprogramming.pl/c2p/Screen.c.txt
http://coreprogramming.pl/c2p/WPA.s.txt
http://coreprogramming.pl/c2p/Screen.lha
09.02.2019 21:26
[#131]
Re: W temacie mojej procedury konwersji c2p
@Phibrizzo, post #130
Procedura konwertuje i zapisuje do 4 osobnych bitplanów. Chodzi o to, że wypełnia całą szerokość docelowej bitmapy.
Dlatego też, używam jej w ten sposób, że konwertuję do mniejszej (węższej) bitmapy, którą docelowo nanoszę na ekran za pomocą Blittera.
Można konwertować bezpośrednio do bitmapy ekranu. Ale wówczas nie możemy sobie dowolnie wycentrować.
Ta technika ma swoje zalety, bo chciałbym konwertować tylko to co potrzeba.
Dlatego też, używam jej w ten sposób, że konwertuję do mniejszej (węższej) bitmapy, którą docelowo nanoszę na ekran za pomocą Blittera.
Można konwertować bezpośrednio do bitmapy ekranu. Ale wówczas nie możemy sobie dowolnie wycentrować.
Ta technika ma swoje zalety, bo chciałbym konwertować tylko to co potrzeba.
10.02.2019 02:26
[#136]
Re: W temacie mojej procedury konwersji c2p
@Phibrizzo, post #135
Wersja dla 8 bitplanów oczywiście powstanie. Zauważ, że bitplany są "równoległe" do siebie, zatem zapis do 4 pozostałych bitplanów pozostawiam po prostu po zapisaniu pierwszych 4 (po zapisaniu całych bitplanów).
Lekko zmodyfikowana procedura zostaje po prostu powtórzona dla bitplanów 4, 5, 6 i 7.
Modyfikacje są dwie:
- Maska w D4 przyjmuje postać $f0f0f0f0
- Przesuwam o 4 bity w prawo.
@Blady
Jako człowiek przyzwyczajony do programowania duszków i BOBów przyznam, że nie jest łatwo tworzyć interesujące efekty na pikselach chunky. Efekt spodobał mi się, więc go zamieściłem.
W każdym razie procedura spisuje się znakomicie.
Ostatnia aktualizacja: 10.02.2019 02:43:54 przez Hexmage960
Lekko zmodyfikowana procedura zostaje po prostu powtórzona dla bitplanów 4, 5, 6 i 7.
Modyfikacje są dwie:
- Maska w D4 przyjmuje postać $f0f0f0f0
- Przesuwam o 4 bity w prawo.
@Blady
Jako człowiek przyzwyczajony do programowania duszków i BOBów przyznam, że nie jest łatwo tworzyć interesujące efekty na pikselach chunky. Efekt spodobał mi się, więc go zamieściłem.
W każdym razie procedura spisuje się znakomicie.
Ostatnia aktualizacja: 10.02.2019 02:43:54 przez Hexmage960
10.02.2019 22:29
[#137]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #129
Załączam archiwum z tym pierwszym efektem oraz kod źródłowy do podglądu.
W polowie procedury WPA masz blad. Jest:
move.l (a0)+,d3 and.l d4,d3 and.l (a0)+,d4 lsl.l #4,d3
a powinno byc:
move.l (a0)+,d3 and.l d4,d3 move.l (a0)+,d4 lsl.l #4,d3
Ale to tylko drobnostka. Poza tym nie bede marudzil tak jak inni tylko ladnie podziekuje za kod. Przydal sie do testowania mojego JIT-a tlumaczacego kod m68k na kod dla procesora ARM. Potrzebowalem jakiejs dlugiej petli intensywnie wykorzystujacej rejestry (mam cache tylko dla 8 rejestrow wiec moj JIT musi nimi troche zonglowac), a tu nagle bach! Pojawiasz sie z twoja procedura.
Dla zainteresowanych - ustawiajac moj JIT tak, zeby procedura zmiescila sie w jednej linijce cache (czyli cala procedura moze byc jako jednosc przetlumaczona na kod ARM) osiagnalem pod RasPi 2 250 MIPS-ow (przerobienie chunky o rozmiarach 6400x4800 pikseli zajmuje 0,4 sekundy). Z domyslnym cache w ktorym ta procedura sie zdecydowanie nie miesci (cache ma miejsce na 64 instrukcje m68k) mam tylko 160 MIPS.
10.02.2019 22:54
[#138]
Re: W temacie mojej procedury konwersji c2p
@mschulz, post #137
W polowie procedury WPA masz blad. Jest:
Hej, to jest na pewno poprawne.
Wykorzystuję rejestr D4 jako maskę lecz w tym miejscu zostaje on wykorzystany jako dodatkowy rejestr danych.(cache ma miejsce na 64 instrukcje m68k)
Wygląda na to, że tu masz rację.
Ostatnia aktualizacja: 10.02.2019 23:01:37 przez Hexmage960
11.02.2019 01:41
[#139]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #138
@MSchulz
Hej, jest to dość ciekawa kwestia. Bo według dokumentu Commodore poświęconego pisaniu gier pod system jest napisane:
"For good performance, it is critical that you code your important loops
to execute entirely from the on-chip 256-byte cache. A straight line loop 258 bytes
long will execute far slower than a 254 byte one."
Wynikałoby z tego, że jednak długość kodu w bajtach ma znaczenie.
Tak, czy siak, przygotowałem pętlę zajmującą 54 polecenia procesora, i konwertującą 16 pikseli na raz. Można porobić testy, by się przekonać.
Ostatnia aktualizacja: 11.02.2019 01:45:33 przez Hexmage960
(cache ma miejsce na 64 instrukcje m68k)
Hej, jest to dość ciekawa kwestia. Bo według dokumentu Commodore poświęconego pisaniu gier pod system jest napisane:
"For good performance, it is critical that you code your important loops
to execute entirely from the on-chip 256-byte cache. A straight line loop 258 bytes
long will execute far slower than a 254 byte one."
Wynikałoby z tego, że jednak długość kodu w bajtach ma znaczenie.
Tak, czy siak, przygotowałem pętlę zajmującą 54 polecenia procesora, i konwertującą 16 pikseli na raz. Można porobić testy, by się przekonać.
Ostatnia aktualizacja: 11.02.2019 01:45:33 przez Hexmage960
11.02.2019 08:02
[#140]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #139
Hej, jest to dość ciekawa kwestia. Bo według dokumentu Commodore poświęconego pisaniu gier pod system jest napisane:
Ale ty mowisz o dokumencie Commodore i o prawdziwym procesorze motoroli. A ja mowie o moim emulatorze m68k, gdzie do testow wykorzystuje twoj kod :)
PS. z twojej procedury moj JIT wygenerowal cos takiego: link
17.02.2019 13:27
[#143]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #142
Tak w ramach luzu miedzy pierwszym a drugim daniem zrobilem test "pure c2p" Twojej procedury na 060/66MHz.
Czyli w petli dokonywala sie tylko kowersja c2p o rozmiarach 320x256x4.
Wynik to srednio 104 fps.
Jak przedstawisz wersje dla 8bit to zrobie podobna i porowna z inna.
Czyli w petli dokonywala sie tylko kowersja c2p o rozmiarach 320x256x4.
Wynik to srednio 104 fps.
Jak przedstawisz wersje dla 8bit to zrobie podobna i porowna z inna.
17.02.2019 13:47
[#144]
Re: W temacie mojej procedury konwersji c2p
@Phibrizzo, post #143
Dziękuję za przeprowadzenie testu.
Ja też zrobiłem niedawno test, w którym liczę czas wykonania tej procedury. Wynik wyszedł bardzo zadowalający zarówno dla 030/50MHz oraz 020/14MHz bez FAST.
Możesz spokojnie założyć, że na Twoim sprzęcie procedura w 8bit osiąga 52 fps, ponieważ konwertuje dokładnie dwa razy więcej danych.
To fajny wynik, widać że ten procesor przerabia naprawdę wiele pikseli na sekundę i spokojnie obsłuży cały ekran Lores w 50 fps.
030/50MHz obsłuży ok. połowy ekranu Lores w 50 fps.
Będę wdzięczny, jak porównasz wynik dla mojej procedury c2p z wynikami dla innych procedur c2p. Ciekaw jestem wyników.
Ja też zrobiłem niedawno test, w którym liczę czas wykonania tej procedury. Wynik wyszedł bardzo zadowalający zarówno dla 030/50MHz oraz 020/14MHz bez FAST.
Możesz spokojnie założyć, że na Twoim sprzęcie procedura w 8bit osiąga 52 fps, ponieważ konwertuje dokładnie dwa razy więcej danych.
To fajny wynik, widać że ten procesor przerabia naprawdę wiele pikseli na sekundę i spokojnie obsłuży cały ekran Lores w 50 fps.
030/50MHz obsłuży ok. połowy ekranu Lores w 50 fps.
Będę wdzięczny, jak porównasz wynik dla mojej procedury c2p z wynikami dla innych procedur c2p. Ciekaw jestem wyników.
17.02.2019 15:01
[#146]
Re: W temacie mojej procedury konwersji c2p
@Phibrizzo, post #145
No to super! Wynik jest zatem bardzo zadowalający. Czuję się zaszczycony.
Jeśli chodzi o konwersję 8bit, to moja procedura mogłaby wykorzystać fakt, że podczas podziału na bitplany 3-0 i 7-4 dokonywana jest wstępna konwersja i zapisać te wstępnie skonwertowane dane.
Wówczas konwersja bitplanów 7-4 będzie krótsza. Odchodzi łączenie za pomocą maski $0f0f0f0f. Koszt to pomocniczy bufor pamięci FAST o rozmiarze połowy bufora chunky, chyba że nadpiszę oryginalny bufor chunky - wtedy nie będzie dodatkowego kosztu pamięciowego.
Tu te brakujące 8 fps powinno się osiągnąć.
Proszę również pamiętać, że wykorzystuję fakt, że bitplany są równoległe (więc można je konwertować oddzielnie) i celuję w 256-bajtowy cache.
Postaram się później dorobić obsługę 8bit.
Czuję się zaszczycony.Jeśli chodzi o konwersję 8bit, to moja procedura mogłaby wykorzystać fakt, że podczas podziału na bitplany 3-0 i 7-4 dokonywana jest wstępna konwersja i zapisać te wstępnie skonwertowane dane.
Wówczas konwersja bitplanów 7-4 będzie krótsza. Odchodzi łączenie za pomocą maski $0f0f0f0f. Koszt to pomocniczy bufor pamięci FAST o rozmiarze połowy bufora chunky, chyba że nadpiszę oryginalny bufor chunky - wtedy nie będzie dodatkowego kosztu pamięciowego.
Tu te brakujące 8 fps powinno się osiągnąć.
Proszę również pamiętać, że wykorzystuję fakt, że bitplany są równoległe (więc można je konwertować oddzielnie) i celuję w 256-bajtowy cache.
Postaram się później dorobić obsługę 8bit.
18.02.2019 13:56
[#148]
Re: W temacie mojej procedury konwersji c2p
@Phibrizzo, post #147
Hej, obliczyłem złożoność czasową (koszt czasowy) procedury c2p.
Po sprawdzeniu okazało się, że wyszło mi dokładnie tyle, ile podaje Kalms. Zapewniam, że doszedłem do wyniku sam.
Otóż w konwersji c2p mamy przekształcić 256-bitowy blok, stosując sprytny algorytm polegający na łączeniu. Koszt takiego algorytmu jest logarytmiczny, czyli gdyby słowo maszyny miało 256 bitów, to wówczas koszt wynosiłby dokładnie log(256) = 8 operacji dominujących, gdzie operacja dominująca to ciąg operacji o stałym koszcie O(1).
Każda operacja odpowiada ciągowi bitów o długości odpowiednio: 1, 2, 4, 8, 16, 32, 64, 128.
W przypadku 32-bitowych słów jest sytuacja dwojaka: otóż dla ciągów bitów o długości 1, 2, 4, 8 oraz 16 musimy wykonać operację dominującą. Dla 32, 64 i 128 nie musimy wykonywać takich operacji, gdyż dane już są rozlokowane w rejestrach. Operację dominującą powtarzamy dla par 32-bitowych słów w 256-bitowym słowie, których jest 4.
Koszt operacji dominującej dla 1, 2, 4 i 8 bitów to 7 instrukcji:
Zaś dla 16 bitów to 5 instrukcji:
Koszt zatem wynosi (4*7+1*5)*4=132 instrukcje dla 32 pikseli w 8 bitplanach.
Pozwala to naświetlić realny czas wykonania takiej procedury. Dla 68020/030 warto zredukować liczbę obsługiwanych na raz bitplanów, żeby mieściło się to w cache tych procesorów.
Można teraz, na podstawie odpowiednich parametrów (MIPS) obliczyć obsługiwaną pulę pikseli dla poszczególnych procesorów.
Potencjalnym elementem optymalizacyjnym to wykorzystanie tzw. MaxPen oraz WriteMask, czyli zredukowanej liczby kolorów ołówków w poszczególnych blokach.
Chyba się nigdzie nie pomyliłem. Jak zauważycie błąd, to proszę skorygować.
Po sprawdzeniu okazało się, że wyszło mi dokładnie tyle, ile podaje Kalms.
Zapewniam, że doszedłem do wyniku sam.Otóż w konwersji c2p mamy przekształcić 256-bitowy blok, stosując sprytny algorytm polegający na łączeniu. Koszt takiego algorytmu jest logarytmiczny, czyli gdyby słowo maszyny miało 256 bitów, to wówczas koszt wynosiłby dokładnie log(256) = 8 operacji dominujących, gdzie operacja dominująca to ciąg operacji o stałym koszcie O(1).
Każda operacja odpowiada ciągowi bitów o długości odpowiednio: 1, 2, 4, 8, 16, 32, 64, 128.
W przypadku 32-bitowych słów jest sytuacja dwojaka: otóż dla ciągów bitów o długości 1, 2, 4, 8 oraz 16 musimy wykonać operację dominującą. Dla 32, 64 i 128 nie musimy wykonywać takich operacji, gdyż dane już są rozlokowane w rejestrach. Operację dominującą powtarzamy dla par 32-bitowych słów w 256-bitowym słowie, których jest 4.
Koszt operacji dominującej dla 1, 2, 4 i 8 bitów to 7 instrukcji:
operacja: move.l d0,d2 and.l d6,d0 eor.l d0,d2 lsl.w #n,d0 swap d0 lsr.w #n,d0 or.l d2,d0 ; połącz
Zaś dla 16 bitów to 5 instrukcji:
operacja: swap d0 eor.w d0,d2 ; zamień miejscami eor.w d2,d0 eor.w d0,d2 swap d0
Koszt zatem wynosi (4*7+1*5)*4=132 instrukcje dla 32 pikseli w 8 bitplanach.
Pozwala to naświetlić realny czas wykonania takiej procedury. Dla 68020/030 warto zredukować liczbę obsługiwanych na raz bitplanów, żeby mieściło się to w cache tych procesorów.
Można teraz, na podstawie odpowiednich parametrów (MIPS) obliczyć obsługiwaną pulę pikseli dla poszczególnych procesorów.
Potencjalnym elementem optymalizacyjnym to wykorzystanie tzw. MaxPen oraz WriteMask, czyli zredukowanej liczby kolorów ołówków w poszczególnych blokach.
Chyba się nigdzie nie pomyliłem. Jak zauważycie błąd, to proszę skorygować.
22.02.2019 12:36
[#149]
Re: W temacie mojej procedury konwersji c2p
@Phibrizzo, post #143
Tak w ramach luzu miedzy pierwszym a drugim daniem zrobilem test "pure c2p" Twojej procedury na 060/66MHz.
Czyli w petli dokonywala sie tylko kowersja c2p o rozmiarach 320x256x4.
Wynik to srednio 104 fps.
1. Czy to byl test FAST-FAST?
2. Czy moglbys zwiekszyc rozmiar bitmapy do rozmiaru przy ktorym osiagasz mniej wiecej 2 fps? Chodzi mi o wydajnosc samej procedury z pominieciem narzutu JSR/RTS
3. Jezeli ty osiagnales 104fps przy 320x256x4 a ja 1,6fps przy 25600x4800x4 to znaczy ze RasPi z JIT-em osiaga wydajnosc porownywalna z 68060@1.5 GHz...
Ciekawe :)
Ostatnia aktualizacja: 22.02.2019 12:37:25 przez mschulz
Ostatnia aktualizacja: 22.02.2019 12:37:36 przez mschulz