13.12.2017 14:43
[#91]
Re: W temacie mojej procedury konwersji c2p
@pisklak, post #80
Sam nie wiem, zarabiać na tym kodzie nie zamierzam (może dopiero na produktach finalnych, jak gry), ale raczej nie chcę publikować tego w ten sposób, żeby każdy mógł sobie pobrać i zrobić swoją wersję. Być może też dlatego, że procedura jest zupełnie moja - autorska.
Nie każdy przecież wydaje oprogramowanie na zasadzie Public Domain. Taki np. freeware jest darmowy, ale gwarantuje, że pakietu nikt nie przerobi, a shareware - że za wysiłek autora wypada zapłacić parę groszy.
Nie każdy przecież wydaje oprogramowanie na zasadzie Public Domain. Taki np. freeware jest darmowy, ale gwarantuje, że pakietu nikt nie przerobi, a shareware - że za wysiłek autora wypada zapłacić parę groszy.
13.12.2017 14:45
[#92]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #89
Oryginalne procedury chunky2planar w Gloomie czy Alien Breedzie 3D II nie są najszybsze.
Mierzyłeś ? Sprawdziłeś ? Jeśli tak to jak ? Masz wgląd w kod źródłowy ?
Chunky nie stosuje się tylko w 3D. Z powodzeniem może posłużyć do procedur 2D, takich w których mapujemy piksele (np. zmieniamy jasność, obliczamy wypadkową dwóch barw, czy robimy inne efekty).
Będzie z tego gra ? Jak nie to gra nie warta zachodu, ale to oczywiście tylko moje zdanie i Twój czas.
13.12.2017 14:55
[#94]
Re: W temacie mojej procedury konwersji c2p
@xray, post #92
Mierzyłeś ? Sprawdziłeś ? Jeśli tak to jak ? Masz wgląd w kod źródłowy ?
Do Glooma powstały inne procedury c2p, bo gra korzysta z prostego linkera i oficjalnie wspomaga własne c2p. Co do Alien Breeda 3D II, to powstał nieoficjalny patch, w którym procedura została podmieniona.
@AmigaPL
Masz gotową procedurę oraz gotowy program testujący. Sprawa z tym taka, że ta procedura to tylko część programu, ale stanowi autonomiczną całość, z której można korzystać i w tym względzie została ukończona.
Ostatnia aktualizacja: 13.12.2017 15:00:38 przez Hexmage960
13.12.2017 15:18
[#95]
Re: W temacie mojej procedury konwersji c2p
@jarokuczi, post #83
@Jarokuczi
Zgadza się i ja to rozumiem, bo programiści mają dużo lepiej płatne prace gdzie indziej.
Ja po prostu preferuję programy natywne zamiast portów. Programy takie zawsze są szybsze, bo dostosowane do danej platformy.
Programy dostosowane pod Amigę z reguły śmigają, zaś porty są często wolne i nawet czasami niestabilne. Ponieważ programista nie ma wpływu na działanie takiego programu nawet posiadając źródła, jak i trudno mu wychwycić błędy.
Programiści jednak nie mają czasu ani na pisanie natywnych programów, ani na optymalizowanie. I portowane programy są najczęściej dość wolne na słabszych maszynach pod AmigaOS4.1 (choć jak ktoś się uprze to tych programów poużywa).
Z dobrych programów to znam m.in. PeteFTP, TuneNet. Sam system jest też całkiem szybki. Ale taki OWB pod AmigaOS 4.1. działa dosyć wolno na Sam440ep (jak również jest niestabilny i potrafi zawiesić system). A na szybszy sprzęt mnie nie stać.
Ostatnia aktualizacja: 13.12.2017 15:19:56 przez Hexmage960
Skończyły się czasy kiedy programiści rozwijali pod AmigaOS komercyjne programy (z małymi wyjątkami).
Zgadza się i ja to rozumiem, bo programiści mają dużo lepiej płatne prace gdzie indziej.
Generalnie według mnie gdyby nie porty, nie mielibyśmy prawie żadnego nowego oprogramowania.
Ja po prostu preferuję programy natywne zamiast portów. Programy takie zawsze są szybsze, bo dostosowane do danej platformy.
Programy dostosowane pod Amigę z reguły śmigają, zaś porty są często wolne i nawet czasami niestabilne. Ponieważ programista nie ma wpływu na działanie takiego programu nawet posiadając źródła, jak i trudno mu wychwycić błędy.
Programiści jednak nie mają czasu ani na pisanie natywnych programów, ani na optymalizowanie. I portowane programy są najczęściej dość wolne na słabszych maszynach pod AmigaOS4.1 (choć jak ktoś się uprze to tych programów poużywa).
Z dobrych programów to znam m.in. PeteFTP, TuneNet. Sam system jest też całkiem szybki. Ale taki OWB pod AmigaOS 4.1. działa dosyć wolno na Sam440ep (jak również jest niestabilny i potrafi zawiesić system). A na szybszy sprzęt mnie nie stać.
Ostatnia aktualizacja: 13.12.2017 15:19:56 przez Hexmage960
13.12.2017 15:23
[#96]
Re: W temacie mojej procedury konwersji c2p
@nogorg, post #84
@Nogorg
Mój program zakłada konkretny protokół - wejściowy bufor Chunky oraz wyjściowa Bitmapa, zatem ogranicza to pulę algorytmów c2p poddających się porównywaniu.
Poza tym myślę, że dużo ciekawsze będzie po prostu wykorzystanie procedury w praktyce. Dlatego na tym się skoncentruję.
Mój program zakłada konkretny protokół - wejściowy bufor Chunky oraz wyjściowa Bitmapa, zatem ogranicza to pulę algorytmów c2p poddających się porównywaniu.
Poza tym myślę, że dużo ciekawsze będzie po prostu wykorzystanie procedury w praktyce. Dlatego na tym się skoncentruję.
13.12.2017 16:06
[#98]
Re: W temacie mojej procedury konwersji c2p
@skipp, post #90
@Skipp
Wiesz co, być może ta różnica wynika z tego, że obliczam z dokładnością do 0.01 ms
Muszę przerobić test (co zresztą planowałem), by obliczał czas w formacie zmiennoprzecinkowym (użyję biblioteki matematycznej). Wtedy wynik będzie w pełni dokładny.
Ostatnia aktualizacja: 13.12.2017 16:06:55 przez Hexmage960
Wiesz co, być może ta różnica wynika z tego, że obliczam z dokładnością do 0.01 ms
Muszę przerobić test (co zresztą planowałem), by obliczał czas w formacie zmiennoprzecinkowym (użyję biblioteki matematycznej). Wtedy wynik będzie w pełni dokładny.Ostatnia aktualizacja: 13.12.2017 16:06:55 przez Hexmage960
14.12.2017 22:13
[#100]
Re: W temacie mojej procedury konwersji c2p
@BULI, post #99
@BULI
Dziękuję za przetestowanie. Widzę, że wynik różni się nieznacznie, ale korzyść jest.
Dzisiaj robiłem procedurę, która dla danej tablicy 256 kolorów liczy wypadkową barwę każdej pary barw. Będzie mi to potrzebne do mieszania tekstur (coś jak kanał alpha).
Oto zrzut ekranu z mojej Amigi:
Dziękuję za przetestowanie. Widzę, że wynik różni się nieznacznie, ale korzyść jest.
Dzisiaj robiłem procedurę, która dla danej tablicy 256 kolorów liczy wypadkową barwę każdej pary barw. Będzie mi to potrzebne do mieszania tekstur (coś jak kanał alpha).
Oto zrzut ekranu z mojej Amigi:
14.12.2017 23:24
[#101]
Re: W temacie mojej procedury konwersji c2p
@BULI, post #99
Cały ekran 320x256 konwertuje w 150ms, czyli 0,15 sekundy (6,6 FPS).
Ekran 160x100 konwertuje w mniej niż 30ms, czyli 0,03 sekundy (30 FPS).
160x100 => 0,02605960 s czyli 38,3FPS
320x256 => 0,13656860 s czyli 7.3FPS
Rzeczywiście przyrost jest, ale liczyłem po cichu na troszkę większy, chociaż 8 FPS więcej dla 160x100 to nie jest tak mało.
08.04.2018 08:40
[#102]
Re: W temacie mojej procedury konwersji c2p
@BULI, post #101
"chunky 2 planar - plain and simple :)"
Jedna z najbardziej przejrzystych procedur, co napisałem. Szczególnie użycie rejestrów jest bardzo klarowne. Jeszcze nie testowana.
- Konwertuje 32 piksele w jednej iteracji,
- Wolne rejestry A5 i A6 (np. do zapisu),
- Wolne robocze rejestry D4 i D5 (oraz D6 i D7, używane do masek),
- EXG zapamiętuje i wstawia rejestry za jednym zamachem,
- Algorytm o koszcie liniowym względem liczby pikseli.
Jedna z najbardziej przejrzystych procedur, co napisałem.
Szczególnie użycie rejestrów jest bardzo klarowne. Jeszcze nie testowana.- Konwertuje 32 piksele w jednej iteracji,
- Wolne rejestry A5 i A6 (np. do zapisu),
- Wolne robocze rejestry D4 i D5 (oraz D6 i D7, używane do masek),
- EXG zapamiętuje i wstawia rejestry za jednym zamachem,
- Algorytm o koszcie liniowym względem liczby pikseli.
08.04.2018 11:58
[#105]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #104
jak wywołać tę procedurę? nie ma rts na końcu(??)
gdzie podać adres do mapy chunky a gdzie adresy bitplanów?
co to jest working pixels?
co to jest other pixels?
które są które?
w pliku .txt dałeś opis działania, ale jeśli to ma być użyte jako "API" np w mojej jakiejś produkcji oczekiwał bym opisu użycia.
i tak wiem mogę to sobie wywnioskować i dodać rts na końcu albo zrobić jako unrolled code ale wolał bym mieć takie rzeczy gotowe
gdzie podać adres do mapy chunky a gdzie adresy bitplanów?
co to jest working pixels?
co to jest other pixels?
które są które?
w pliku .txt dałeś opis działania, ale jeśli to ma być użyte jako "API" np w mojej jakiejś produkcji oczekiwał bym opisu użycia.
i tak wiem mogę to sobie wywnioskować i dodać rts na końcu albo zrobić jako unrolled code ale wolał bym mieć takie rzeczy gotowe
10.04.2018 03:05
[#107]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #106
@Retronav i koledzy
Hej, zapomnijcie o tamtej wersji.
Oto nowa wersja. Procedury są napisane w taki sposób, by użytkownik - programista w łatwy sposób zaimportował je do swojego kodu jako funkcje w asemblerze (można je również łatwo przekształcić w razie potrzeby w makra).
Moja procedura C2P pracuje jak jest to w Amidze CD32 - przyjmuje dane w rejestrach procesora i zwraca w rejestrach. Z tego też względu moja procedura dzieli konwersję na dwa etapy dla każdej czwórki bitplanów, ze względu na wykorzystanie rejestrów danych.
Nie powoduje to żadnych problemów, do użytkownika należy wybranie kolejności konwersji - procedura jest rozbita na 3 etapy:
- Konwersja wstępna (c2p_pass1) - podział na dwie czwórki bitplanów. Po tym etapie w każdym rejestrze jest po 8 pikseli.
- Konwersja główna (c2p_pass2) - konwersja do 16 pikseli po cztery bitplany.
- Konwersja zamykająca (c2p_pass3) - połączenie w 32 pikselowe bloki.
Każda procedura pobiera dane chunky w rejestrach d2-d3 plus niezbędne maski w rejestrach od d4 do d6 w zależności od funkcji i zwraca wynik w rejestrach d2-d3. Rejestry d0 i d1 to rejestry robocze i mogą ulec modyfikacji przez funkcje.
Konwersję wstępną należy wykonywać dla każdych 8 pikseli, po czym należy wybrać czy konwertujemy dalej wyższe czy niższe bitplany (resztę możemy zapamiętać w dowolny sposób). Następnie wykonujemy konwersję główną raz lub więcej dla każdych 16 pikseli (jeżeli wykonamy ją dwa razy, możemy połączyć 16-pikselowe wyniki w jeden 32-pikselowy blok za pomocą konwersji zamykającej).
Dalsze ew. manipulacje, zapis do pamięci graficznej należą do programu głównego. Jest to już bardzo proste i program główny ma duże pole do popisu.
Oto kod (może zawierać ew. usterki, jeśli tak - będę korygował):
Kod źródłowy procedur chunky-to-planar
Szybkość procedury powinna być na dobrym poziomie, zresztą dużo zależy od użytkownika tych funkcji - ile potrzebuje bitplanów i pikseli, jak przechowuje dane tymczasowe itp.
Mam nadzieję, że jest to dość przystępne opracowanie. Zapraszam do testowania i chętnie posłucham uwag. Liczę na to, że moje procedury znajdą zastosowanie w .. nowych superprodukcjach na Amigę naszej braci scenowej.
Hej, zapomnijcie o tamtej wersji.
Oto nowa wersja. Procedury są napisane w taki sposób, by użytkownik - programista w łatwy sposób zaimportował je do swojego kodu jako funkcje w asemblerze (można je również łatwo przekształcić w razie potrzeby w makra).
Moja procedura C2P pracuje jak jest to w Amidze CD32 - przyjmuje dane w rejestrach procesora i zwraca w rejestrach. Z tego też względu moja procedura dzieli konwersję na dwa etapy dla każdej czwórki bitplanów, ze względu na wykorzystanie rejestrów danych.
Nie powoduje to żadnych problemów, do użytkownika należy wybranie kolejności konwersji - procedura jest rozbita na 3 etapy:
- Konwersja wstępna (c2p_pass1) - podział na dwie czwórki bitplanów. Po tym etapie w każdym rejestrze jest po 8 pikseli.
- Konwersja główna (c2p_pass2) - konwersja do 16 pikseli po cztery bitplany.
- Konwersja zamykająca (c2p_pass3) - połączenie w 32 pikselowe bloki.
Każda procedura pobiera dane chunky w rejestrach d2-d3 plus niezbędne maski w rejestrach od d4 do d6 w zależności od funkcji i zwraca wynik w rejestrach d2-d3. Rejestry d0 i d1 to rejestry robocze i mogą ulec modyfikacji przez funkcje.
Konwersję wstępną należy wykonywać dla każdych 8 pikseli, po czym należy wybrać czy konwertujemy dalej wyższe czy niższe bitplany (resztę możemy zapamiętać w dowolny sposób). Następnie wykonujemy konwersję główną raz lub więcej dla każdych 16 pikseli (jeżeli wykonamy ją dwa razy, możemy połączyć 16-pikselowe wyniki w jeden 32-pikselowy blok za pomocą konwersji zamykającej).
Dalsze ew. manipulacje, zapis do pamięci graficznej należą do programu głównego. Jest to już bardzo proste i program główny ma duże pole do popisu.
Oto kod (może zawierać ew. usterki, jeśli tak - będę korygował):
Kod źródłowy procedur chunky-to-planar
Szybkość procedury powinna być na dobrym poziomie, zresztą dużo zależy od użytkownika tych funkcji - ile potrzebuje bitplanów i pikseli, jak przechowuje dane tymczasowe itp.
Mam nadzieję, że jest to dość przystępne opracowanie. Zapraszam do testowania i chętnie posłucham uwag. Liczę na to, że moje procedury znajdą zastosowanie w .. nowych superprodukcjach na Amigę naszej braci scenowej.
10.04.2018 09:03
[#108]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #107
Uważam, że procedura jest naprawdę porządnie opracowana i prosta w użyciu. Jej siłą jest - prostota, przejrzystość, kompletność i możliwość swobodnego użycia przez programistę.
Myślę, że dobrze wyodrębniłem etapy konwersji i powtarzające się czynności. Lepiej zmieszczą się też w cache.
Pokuszę się jednak o przykładowy sposób wykorzystania w "pełnoprawnym" c2p - z zapisem danych do pamięci graficznej Amigi, coś jak WriteChunkyPixels().
Po czym będę pisać moją grę.
Ostatnia aktualizacja: 10.04.2018 09:13:13 przez Hexmage960
Myślę, że dobrze wyodrębniłem etapy konwersji i powtarzające się czynności. Lepiej zmieszczą się też w cache.
Pokuszę się jednak o przykładowy sposób wykorzystania w "pełnoprawnym" c2p - z zapisem danych do pamięci graficznej Amigi, coś jak WriteChunkyPixels().
Po czym będę pisać moją grę.
Ostatnia aktualizacja: 10.04.2018 09:13:13 przez Hexmage960
11.04.2018 12:30
[#114]
Re: W temacie mojej procedury konwersji c2p
@Phibrizzo, post #113
Chodzi o to by mieć parę punktów pomiarowych a nie jeden. Zawsze można w pętli 100 razy puścić to samo, ale w przypadku użycia czegoś wyżej niż asembler istnieje ryzyko wycięcia pętli w optymalizacji.
Obrót to było w sumie pierwsze co przyszło mi do głowy, można do tego chociażby wziąć moją chunkyRotate z ACE'a.
Obrót to było w sumie pierwsze co przyszło mi do głowy, można do tego chociażby wziąć moją chunkyRotate z ACE'a.
13.01.2019 12:13
[#117]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #116
Hej, chciałem tylko poinformować, że odświeżyłem moją procedurę chunky2planar.
Można ją obejrzeć w ładnej oprawie HTML tutaj:
http://www.coreprogramming.pl/Blog2.html
Myślę, że jest to najprzejrzystsza wersja spośród opracowanych przeze mnie procedur. Jest też całkiem szybka.
Do odświeżenia zainspirował mnie kolega z forum.
Procedura konwertuje 32 piksele w 8 bitplanach i zapisuje 32 piksele w formie długich słów, przy czym robi to dwuetapowo. Drugi etap jest krótszy i konwertuje pozostałe 4 bitplany.
Zweryfikowałem poprawność póki co pierwszego, dłuższego etapu, ale drugi też powinien działać poprawnie. W razie błędów skoryguję.
Myślę, że kod się przyda i może kogoś również zainspiruje. W każdym razie można korzystać z tego kodu do woli.
Można ją obejrzeć w ładnej oprawie HTML tutaj:
http://www.coreprogramming.pl/Blog2.html
Myślę, że jest to najprzejrzystsza wersja spośród opracowanych przeze mnie procedur. Jest też całkiem szybka.
Do odświeżenia zainspirował mnie kolega z forum.
Procedura konwertuje 32 piksele w 8 bitplanach i zapisuje 32 piksele w formie długich słów, przy czym robi to dwuetapowo. Drugi etap jest krótszy i konwertuje pozostałe 4 bitplany.
Zweryfikowałem poprawność póki co pierwszego, dłuższego etapu, ale drugi też powinien działać poprawnie. W razie błędów skoryguję.
Myślę, że kod się przyda i może kogoś również zainspiruje. W każdym razie można korzystać z tego kodu do woli.
13.01.2019 22:12
[#119]
Re: W temacie mojej procedury konwersji c2p
@Norbert, post #118
Tak jak napisałem, główną własnością tej procedury jest przejrzystość. Dzięki niej kod jest całkiem łatwy w czytaniu. Szybkości gruntownie nie testowałem.
Może to służyć jako baza do nauki tej procedury chunky-to-planar oraz - nawet - przyszłych optymalizacji.
Myślałem, żeby podpiąć to do Glooma dla testów, jednakże nie w tej chwili. Mam obecnie inne obowiązki.
Ostatnia aktualizacja: 13.01.2019 22:14:27 przez Hexmage960
Może to służyć jako baza do nauki tej procedury chunky-to-planar oraz - nawet - przyszłych optymalizacji.
Myślałem, żeby podpiąć to do Glooma dla testów, jednakże nie w tej chwili. Mam obecnie inne obowiązki.
Ostatnia aktualizacja: 13.01.2019 22:14:27 przez Hexmage960
07.02.2019 21:44
[#120]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #119
Hej!
Najnowsza odsłona mojej procedury (razem z zapisem do bitplanów). Pobiłem swój rekord życiowy.
Cechy procedury:
Pełna pętla konwersji 32 pikseli w 4 bitplanach zajmuje dokładnie 97 instrukcji procesora (wliczając odczyt, zapis oraz instrukcję pętli BGT). Oznacza to 3 instrukcje procesora na piksel (czyli 6 instrukcji dla 8 bitplanów).
Procedura nie korzysta z instrukcji EXG, ani buforów w pamięci. Mocno zoptymalizowałem wykorzystanie rejestrów procesora. Dwie maski są cały czas w rejestrach, dwie ładuję tylko raz.
Zapis odbywa się do bitplanów wskazywanych przez rejestry adresowe: A1, A2, A3 i A4. A0 wskazuje na bufor chunky, zaś A5 na koniec tego bufora.
Instrukcje są sparowane oraz jest jedna instrukcja pomiędzy dostępami do pamięci. Zatem procedura powinna działać dobrze na 68060 oraz na Amidze tylko z pamięcią CHIP (bez FAST).
Procedura ze względu na 97 instrukcji na pewno mieści się w cache 256 bajtów.
http://coreprogramming.pl/c2p/chunky-to-planar.txt/txt
Myślę, że tyle optymalizacji już wystarczy. Procedura powinna być naprawdę szybka, ok. 1 ramki na cały ekran na 68030. Będę ją później wykorzystywał. Chciałem uporządkować tę kwestię.
Najnowsza odsłona mojej procedury (razem z zapisem do bitplanów). Pobiłem swój rekord życiowy.
Cechy procedury:
- liniowo ułożone piksele,
- konwertuje 32 piksele po 4 bitplany,
- zapisuje do bitplanów.
Pełna pętla konwersji 32 pikseli w 4 bitplanach zajmuje dokładnie 97 instrukcji procesora (wliczając odczyt, zapis oraz instrukcję pętli BGT). Oznacza to 3 instrukcje procesora na piksel (czyli 6 instrukcji dla 8 bitplanów).
Procedura nie korzysta z instrukcji EXG, ani buforów w pamięci. Mocno zoptymalizowałem wykorzystanie rejestrów procesora. Dwie maski są cały czas w rejestrach, dwie ładuję tylko raz.
Zapis odbywa się do bitplanów wskazywanych przez rejestry adresowe: A1, A2, A3 i A4. A0 wskazuje na bufor chunky, zaś A5 na koniec tego bufora.
Instrukcje są sparowane oraz jest jedna instrukcja pomiędzy dostępami do pamięci. Zatem procedura powinna działać dobrze na 68060 oraz na Amidze tylko z pamięcią CHIP (bez FAST).
Procedura ze względu na 97 instrukcji na pewno mieści się w cache 256 bajtów.
http://coreprogramming.pl/c2p/chunky-to-planar.txt/txt
Myślę, że tyle optymalizacji już wystarczy.
Procedura powinna być naprawdę szybka, ok. 1 ramki na cały ekran na 68030. Będę ją później wykorzystywał. Chciałem uporządkować tę kwestię.