Forum AmigaOne Zone

Forum użytkowników Amigi i nie tylko
Teraz jest środa, 6 lis 2024, 15:02

Strefa czasowa: UTC + 1




Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 21 ]  Przejdź na stronę Poprzednia strona  1, 2
Autor Wiadomość
PostNapisane: niedziela, 12 lis 2017, 21:13 
Offline
Elitarny forumowicz
Elitarny forumowicz
Avatar użytkownika

Dołączył(a): piątek, 20 sty 2012, 05:09
Posty: 566
Lokalizacja: Warszawa
Witam!

Moja praca nad własnym modelem c2p wreszcie dobiega końca.

Oznacza to, że doszedłem do konkluzji, na bazie której mogę stworzyć efektywną procedurę c2p oraz, w analogiczny sposób - p2c. Mam nadzieję, że następnie wykorzystam tą procedurę w praktyce.

Mój model różni się nieco od modelu Kalmsa. Kalms rozumie c2p jako transpozycję macierzy.

Ja rozumiem c2p jako skalowanie wektora.

Te modele różnią się od siebie zasadniczo.

W moim modelu proces c2p jest nieco przejrzystszy i łatwiejszy do zrozumienia i implementacji na każdym etapie.

W rzeczywistości mój model ma koszt liniowy względem liczby bitplanów razy liczba pikseli.

Otóż określiłem formaty: planarny, chunky 2-pikselowy, chunky 4-pikselowy oraz ten właściwy chunky 8-pikselowy oraz opisałem konwersję.

Chunky 2-pikselowy oznacza, że dwa sąsiadujące ze sobą bity opisują piksel.

Konwersja przebiega od Chunky 8-pikselowego do planarnego. Stosowane są wspomniane formaty pośrednie.

Opiszę teraz co to jest to skalowanie. Dla każdego formatu stosowany jest odpowiedni algorytm skalowania.

Otóż skalowanie to zawężanie lub rozszerzanie bitów w słowie. Zawężanie stosuje się przy konwersji chunky to planar, zaś rozszerzanie w procesie odwrotnym (planar to chunky).

Zawężanie polega na tym, że każdy bit (lub bloki 2/4 bitów) słowa przesuwa się w lewo na pozycję n/2.

Oto przykład:
Kod:
Skalowanie chunky 8-pikselowego do chunky 4-pikselowego

a7a6a5a4a3a2a1a0 b7b6b5b4b3b2b1b0 c7c6c5c4c3c21c0 d7d6d5d4d3d2d1d0 - chunky 8-pikselowe

a7a6a5a4........ b7b6b5b4........ c7c6c5c4........ d7d6d5d4........
........a3a2a1a0 ........b3b2b1b0 ........c3c2c1c0 ........d3d2d1d0

Po przeskalowaniu:

a7a6a5a4 b7b6b5b4 c7c6c5c4 d7d6d5d4 - chunky 4-pikselowe (bitplany wyższe)
a3a2a1a0 b3b2b1b0 c3c2c1c0 d3d2d1d0 - chunky 4-pikselowe (bitplany niższe)

Co ciekawe okazuje się, że skalowanie bloków o większej długości jest mniej kosztowne aniżeli ta sama operacja dla bloków o mniejszej długości. W przypadku chunky 2-pikselowego najlepiej użyć wartości umieszczonych w tablicy o długości 256 lub 65 tys. elementów. W przypadku chunky 8-pikselowego można zrobić to algorytmicznie.

Pozostałe dwa etapy:

Kod:
a7a6a5a4 b7b6b5b4 c7c6c5c4 d7d6d5d4 e7e6e5e4 f7f6f5f4 g7g6g5g4 h7h6h5h4 - chunky 4-pikselowe

a7a6.... b7b6.... c7c6.... d7d6.... e7e6.... f7f6.... g7g6.... h7h6....
....a5a4 ....b5b4 ....c5c4 ....d5d4 ....e5e4 ....f5f4 ....g5g4 ....h5h4

Po przeskalowaniu:

a7a6 b7b6 c7c6 d7d6 e7e6 f7f6 g7g6 h7h6 - chunky 2-pikselowe
a5a4 b5b4 c5c4 d5d4 e5e4 f5f4 g5g4 h5h4 - chunky 2-pikselowe

a7a6 b7b6 c7c6 d7d6 e7e6 f7f6 g7g6 h7h6 i7i6 j7j6 k7k6 l7l6 m7m6 n7n6 o7o6 p7p6

a7.. b7.. c7.. d7.. e7.. f7.. g7.. h7.. i7.. j7.. k7.. l7.. m7.. n7.. o7.. p7..
..a6 ..b6 ..c6 ..d6 ..e6 ..f6 ..g6 ..h6 ..i6 ..j6 ..k6 ..l6 ..m6 ..n6 ..o6 ..p6

Po przeskalowaniu:

a7b7c7d7e7f7g7h7 i7j7k7l7m7n7o7p7 - format planarny
a6b6c6d6e6f6g6h6 i6j6k6l6m6n6o6p6


Mam nadzieję, że przejrzystość tego rozwiązania jest dobrze widoczna. :-) Algorytm odwrotny, czyli planar to chunky jest realizowany identycznie z tą różnicą, że skalujemy w drugą stronę.

Mam nadzieję, że te informacje komuś się przydadzą - nie tylko mnie.

Pozdrawiam.

_________________
Robert "Hextreme" Szacki - Gear Works software


Udostępnij dla FacebookUdostępnij dla Twitter
Góra
 Zobacz profil  
Cytuj  
PostNapisane: poniedziałek, 13 lis 2017, 10:19 
Offline
Elitarny forumowicz
Elitarny forumowicz
Avatar użytkownika

Dołączył(a): piątek, 20 sty 2012, 05:09
Posty: 566
Lokalizacja: Warszawa
Tak się zastanawiam, że można robić konwersję w jednym kroku z chunky-8 do planar dzięki mojej metodzie. Nie trzeba korzystać z formatów przejściowych, które okazały się gmatwać w tym przypadku sytuację.

Mam pomysł, żeby skalowanie przy c2p odbywało się na zasadzie wyszukiwania binarnego z tablicy 256-elementowej, które będzie powtarzane 4 razy dla kolejnych 8 pikseli, a następnie dla każdego bitplanu.

Średnia liczba poszukiwań dla losowych danych wynosiłaby wówczas 16 dla 32 pikseli.

Oznacza to:
  • bardzo krótką i prostą procedurę (zmieści się w cache 256-bajtów),
  • dosyć szybki czas wykonania,
  • tani zapis 32-bitowy.

Z minusów:
  • iteracje wewnątrz procedury

Myślę, że gra jest warta świeczki.

_________________
Robert "Hextreme" Szacki - Gear Works software


Góra
 Zobacz profil  
Cytuj  
PostNapisane: poniedziałek, 11 gru 2017, 20:09 
Offline
Elitarny forumowicz
Elitarny forumowicz
Avatar użytkownika

Dołączył(a): piątek, 20 sty 2012, 05:09
Posty: 566
Lokalizacja: Warszawa
Witam serdecznie!

Wklejam post z PPA, który napisałem odnośnie mojej nowej, szybkiej i przejrzystej (łatwej w zrozumieniu) procedury chunky-to-planar: :D

-------------------------
Zoptymalizowałem moją sympatyczną procedurę chunky-to-planar. A jakże! :-)

Włożyłem maski do rejestrów, a pola bm_BytesPerRow i bm_Rows z nich wyjąłem, gdyż korzystam z nich rzadziej.

Rezultat: na 68020/14MHz z CHIP przyrost prędkości +25%.
  • 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).
Jeśli chodzi o 68030/50MHz z FAST, przyrost prędkości +17%.
  • Cały ekran konwertuje w 53ms, czyli 0,053 sekundy (18,8 FPS).
  • Ekran 192x245 konwertuje w 30,2ms, czyli 0,0302 sekundy (30 FPS)!
  • Ekran 160x175 konwertuje w 18,5ms, czyli 0,0185 sekundy (54 FPS).
Oczywiście test jest przy pełnej wielozadaniowości systemu Amigi (niezmieniony priorytet 0). Można odpalać inne programy.

Sprawdzałem też poprzednią wersję na 68060/50MHz (teraz mam włożoną 68030) i z tego co pamiętam tam mieściłem się w ramce przy pełnym ekranie.

Nie posiadam karty (ani Amigi) z 040 i jeżeli ktoś może przeprowadzić mały test, byłbym wdzięczny.

Należy też pamiętać, że mogę zrobić wersję 2x1 procedury o obniżonych detalach. A tak, trzeba użyć mniejszego okienka by rozkoszować się np. 30 FPS. A to na 030/50MHz można łatwo osiągnąć.

Pomimo, że ta procedura tylko konwertuje, oczywiście obrazuje ile pikseli można przerabiać w tym czasie. Bo czy wykonamy jedną, czy dwie operacje na pikselu to nie czyni dużej różnicy, bo koszt nadal jest liniowy. Dopiero jak wykonamy n operacji na każdym z n pikseli, różnica jest, bo wówczas koszt jest kwadratowy na przykład.

Oczywiście na Amidze CD32 problem z konwersją odchodzi, bo tam jest sprzętowy, ale chciałbym by Amiga 1200 też mogła korzystać z dobrodziejstw tej techniki.

Przepraszam, że jeszcze nie opublikowałem programu demonstracyjnego, ale takowy zrobię. :-)

Format BMP jest całkiem prosty, nawet mam źródła datatypa do BMP, ale jednak trzeba nad tym trochę popracować. Myślałem też by zrobić program testujący z prostym GUI, dla umilenia procesu testowania.

Niestety nie mam w ogóle doświadczenia w mapowaniu tekstur i innych technikach (nawet 2D), więc takich efektów szybko nie zrobię.

Myślałem, żeby później wykorzystać kod w mojej grze. W każdym razie trochę to potrwa, ale już teraz warsztat pracy jest coraz lepszy.

Troszkę zastanawiam się również nad zaadaptowaniem procedury do Glooma, bo być może nie będzie to takie trudne.

Tymczasem oto linki do:
Pozdrawiam i niech Amiga będzie z Wami. :-)
-------------------------

_________________
Robert "Hextreme" Szacki - Gear Works software


Góra
 Zobacz profil  
Cytuj  
PostNapisane: wtorek, 12 gru 2017, 15:39 
Offline
Doborowy forumowicz
Doborowy forumowicz
Avatar użytkownika

Dołączył(a): wtorek, 17 sty 2012, 15:11
Posty: 936
Super :thumbup:

_________________
Amiga Rulez / YouTube

Interes życia https://www.youtube.com/watch?v=EUkYy2YItvo


Góra
 Zobacz profil  
Cytuj  
PostNapisane: wtorek, 10 kwi 2018, 02:11 
Offline
Elitarny forumowicz
Elitarny forumowicz
Avatar użytkownika

Dołączył(a): piątek, 20 sty 2012, 05:09
Posty: 566
Lokalizacja: Warszawa
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. :D

_________________
Robert "Hextreme" Szacki - Gear Works software


Góra
 Zobacz profil  
Cytuj  
PostNapisane: wtorek, 10 kwi 2018, 08:49 
Offline
Doborowy forumowicz
Doborowy forumowicz
Avatar użytkownika

Dołączył(a): wtorek, 17 sty 2012, 15:11
Posty: 936
A może udostępnij tą procedurę w jakimś prostym silniku 3d i dla porównania z wyłączeniem tej procedury no i z wyświetlaniem ilości klatek na sekundę. Byśmy zobaczyli jak to w praktyce wygląda. No, ale może Ci się nie chce :)

_________________
Amiga Rulez / YouTube

Interes życia https://www.youtube.com/watch?v=EUkYy2YItvo


Góra
 Zobacz profil  
Cytuj  
Wyświetl posty nie starsze niż:  Sortuj wg  
Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 21 ]  Przejdź na stronę Poprzednia strona  1, 2

Strefa czasowa: UTC + 1


Kto przegląda forum

Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 1 gość


Nie możesz rozpoczynać nowych wątków
Nie możesz odpowiadać w wątkach
Nie możesz edytować swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Skocz do:  
Powered by phpBB® Forum Software © phpBB Group
Przyjazne użytkownikom polskie wsparcie phpBB3 - phpBB3.PL
phpBB SEO