Wektory

Wiadomość

zielok · #1 Post autor: **zielok** » 03 mar 2009, 21:18

W sumie jeszcze tego nawet nie zacząłem kodować ale, że w sumie nigdy nie skończyłem swojej wektorówki (w realtimie) na c64 to stwierdziłem, że może warto nadrobić zaległości.

A więć chciałbym się dowiedzieć czy tak ja to sobie rozplanowałem ma sens czy gdzie jakiś fatalny bład popełniam lub ewentualnie można to zrobić lepiej.

Założenia - wektory na znakach (czyli 128px x 128px)
1) Robie tablice o wielkości 256 bajtow na SIN i COS - Oczywiście uwzglęniam tu 360 stopni, tablice do perspective projection (takze o wielkosci 256 bajtow)
2) wartosci punktów i kąty obroty wokół oi trzymam w jednym bajcie (oczywiście na każdą wartość)
3) wykonuje działanie czyli
punkt*cos,x - kazda z wartosci jest 8 bitowa wynik uzyskuje 16 bitowy
punkt*sin,x - tak samo jak wyzej
otrzymane wartosci 16 bitowe odejmuje (lub dodaje w zaleznosci od tego wokoł której robie osi)
4) otrzymana wartość zamieniam na 8 bitową (aby móc robić następne przekształcenia mnożacz dwie 8 bitowe wartości) - i tutaj się zastanawiam czy nie strace na dokładności
5) obracam wokól osi które potrzbuje stosujac punkt 3 i 4
6) następnie robie perspective projection stosujac tablice wykonana w punkcie 1 mnozac punkt X (czy Y). W tym przypadku znowu mnoze dwie wartosci 8 bitowe i biore tylko wyzszy bajt.

Zrobiłem sobie te obliczenia w Excelu (aby sprawdzic czy nie bedzie za duzych zaokraglen) i wynik wyglada na zadawalajacy (minimalne odchylenia)

Resumujac chcialbym wiedziec zanim zaczne to pisac na c64 czy tak jak chce to zrobic jest ok? A moze da się zrobić to lepiej?

#2 Post autor: **Nitro** » 03 mar 2009, 22:05

Teoria chyba w porządku, ale z szybkością tego może być średnio, pewnie twoje procedury mnożenia wcinają trochę czasu, jak widzę po opisie -> 16 bitowy wynik.

Wiesz, jest pewna seria artykułów, gdzie opisane jest robienie wektorów w praktycznie wszystkich aspektach(chociaż są dosyć stare, jest miejsce na optymalizację, aktualne osiągnięcia), pytanie czy chcesz sobie psuć zabawę

zielok · #3 Post autor: **zielok** » 03 mar 2009, 22:36

Nitro pisze:Teoria chyba w porządku, ale z szybkością tego może być średnio, pewnie twoje procedury mnożenia wcinają trochę czasu, jak widzę po opisie -> 16 bitowy wynik.

Hmm, tutaj to raczej bym sie nie martwil aby pomnozyc dwie 8 bitowe liczby i uzyskac 16 bitowy wynik to w skrocie - odczytanie z tablicy wartosci, nastepnie odejmowanie, zapis, odczyt z tablic, odejmowanie i zapis w komorce. I wtedy juz mamy wynik mnozenia w 16 bitach... Czyli szybko

Wiesz, jest pewna seria artykułów, gdzie opisane jest robienie wektorów w praktycznie wszystkich aspektach(chociaż są dosyć stare, jest miejsce na optymalizację, aktualne osiągnięcia), pytanie czy chcesz sobie psuć zabawę

Narazie nie chce psuc sobie zabawy. Sam algorytm moim zadaniem wydaje sie niezly (wszystko w miare optymalnie wyglada w zalozeniach). Oczywiscie jak napisze kod to on juz napewno bedzie mogl zostac mocno zooptymalizowany ale jednak 12 lat przerwy robi swoje.

ps. Chociaz daj moze linka do tej serii artykulow. Moze cos ciekawego tam zobacze....

prezes · #4 Post autor: **prezes** » 04 mar 2009, 10:34

Tablice trygonometryczne koniecznie zrob 16bitowe (a wlasciwie 17 bitowe dla sin(90') ), inaczej bedzie sieczka. A jak chcesz worldfirsta to mozesz je wygenerowac szeregiem.

śmigło .::. · #5 Post autor: **śmigło .::.** » 05 mar 2009, 10:51

Wydaje mi się że tablice 8-bit w zupełności wystarczają. Zwykle wartości sin/cos trzyma się pomnożone przez 64, ale podobno lepszą dokładność daje pomnożenie przez 127 i robienie dzielenia przez 128. Więcej przeważnie nie potrzeba, zwłaszcza że 16bit*8bit jest znacząco wolniejsze niż 8bit*8bit...

#6 Post autor: **Nitro** » 05 mar 2009, 18:11

Hmm, tutaj to raczej bym sie nie martwil aby pomnozyc dwie 8 bitowe liczby i uzyskac 16 bitowy wynik to w skrocie - odczytanie z tablicy wartosci, nastepnie odejmowanie, zapis, odczyt z tablic, odejmowanie i zapis w komorce. I wtedy juz mamy wynik mnozenia w 16 bitach... Czyli szybko Smile

Myślałem, że może mnożysz bez tablic.

Narazie nie chce psuc sobie zabawy. Sam algorytm moim zadaniem wydaje sie niezly (wszystko w miare optymalnie wyglada w zalozeniach). Oczywiscie jak napisze kod to on juz napewno bedzie mogl zostac mocno zooptymalizowany ale jednak 12 lat przerwy robi swoje.

ps. Chociaz daj moze linka do tej serii artykulow. Moze cos ciekawego tam zobacze....

Mimo wszystko jeszcze raz zapytam, czy chcesz ten art, może lepiej skoduj po prostu swój sposób, a jeśli napotkasz problemy/skończysz, to dam Ci link.

zielok · #7 Post autor: **zielok** » 05 mar 2009, 19:50

Nitro pisze: Mimo wszystko jeszcze raz zapytam, czy chcesz ten art, może lepiej skoduj po prostu swój sposób, a jeśli napotkasz problemy/skończysz, to dam Ci link.

Ok.. pobawimy się:) Jak skoduje dwie wersje to porownam.

Apropo to w c++ na PC juz napisalem (oczywiscie przyjmujac dokladnosc tak jak na c64 i stosujac te same dzialania). Dziala w pelni zadawalajaco (tj. wektory sa dokladne na 8bitowych tablicach sinusow zreszta calosc napisalem tak jak pisalem w pierwszym poscie). Teraz pozostaje napisac to na c64.

Druga wersja to bedzie zastosowanie macierzy obrotu itd, ktore to powinny przyspieszyc jeszcze sprawe.

wegi · #8 Post autor: **wegi** » 14 lip 2009, 01:40

Wszystko to robisz w stacji, transmitujesz tylko wyniki obliczeń do c64, który rysuje linie i eoruje (wypełnia). Zobacz mój post do ram 1541

zielok · #9 Post autor: **zielok** » 14 lip 2009, 12:47

Ja to wiem, że tak najlepiej tylko, że nigdy stacji nie kodowałem

zielok · #10 Post autor: **zielok** » 08 maja 2010, 20:58

zielok pisze:Ja to wiem, że tak najlepiej tylko, że nigdy stacji nie kodowałem

A jednak nie

Stacja z powodu małej ilości pamięci i braku miejsca nie pozwoli szybko przeliczyć wielu punktów. Owszem dla kilkunastu punktów da pewnie przyśpieszenie ale czym większa ilość punktów do przeliczenia tym obliczanie w stacji dysków będzie proporcjonalnie wolniejsze.

k. · #11 Post autor: k. » 08 maja 2010, 21:04

pomyśl o proporcjonalnie dłuższym czasie na narysowanie tych punktów w komciu a percepcja ci się rozjaśni.

#12 Post autor: **Nitro** » 08 maja 2010, 21:09

Nie mówiąc o opcji nie liczenia wszystkich punktów skoro aż tak słabo z pamięcią.

leming · #13 Post autor: **leming** » 08 maja 2010, 23:07

to jak to najlepiej ma byc? liczone troche na stacji a wiekszosc na komie? to cos da?

k. · #14 Post autor: k. » 08 maja 2010, 23:19

IMHO z pozycji kodera to lepiej policzyć w stacji i rysować w komciu.

zielok · #15 Post autor: **zielok** » 09 maja 2010, 00:01

kisiel pisze:IMHO z pozycji kodera to lepiej policzyć w stacji i rysować w komciu.

IHMO nie...

Policz dla DOWOLNEGO obiektu składającego się powiedzmy z 40 punktów obroty w 3 osiach w stacji lub komodorku...
Komcio to już dawno przeliczy i namaluje a stacja nie zwróci jeszcze wyniku obliczeń...
Gdyby stacja miała więcej pamięci to można zrobić lepsze tabelki dla mnożeń i wtedy byłaby szybsza.

#16 Post autor: **Nitro** » 09 maja 2010, 00:30

Jak wyżej, podzielić obliczenia i wtedy uzyskamy maksymalną wydajność.
Chociaż proponuje też poznać sposób na plotery, ponad 256 dotsów w ramce, choć bez perspektywy, to chyba jest standardem teraz, a nie żmudne mnożenia(patrz notkę do EoD).

zielok · #17 Post autor: **zielok** » 09 maja 2010, 10:36

Nitro ja spokojnie osiągam przeliczenie (bez malowania) ponad 280 punktów na ramkę a kod do przeliczania mam jeszcze nie w pełni zoptymalizowany (m.in brak "unrolled code"). Oczywiście bez perspektywy. I to spokojnie możemy użyć również do wypełnianych wektorów.

"Mnożenie" trzeba zawsze wykonać (tylko nie jest takie zwykłe matematyczne mnożenie bo byłoby za wolne tylko uzyskujemy od razu wynik - kilka cykli na mnożenie (które jest zwykłym dodawaniem wartości:))) bo inaczej raczej nie da się przeliczyć punktów.
Zresztą to "mnożenie" u mnie wygląda tak:
lda $xxxx
adc $yyyy
adc $zzzz
- tu "mnoże" trzy wartości 8bitowe ze znakiem i uzyskuje wynik 8 bitowy ze znakiem (oczywiście odpowiednio pomniejszego do przestrzeni 8 bitow)

W gwoli wyjaśnienia to inne techniki optymalizacyjne także mi są znane (np. obliczenie niektórych punktów na podstawie innych - gdzie uzyskujemy przekształcenie punktu w trzech osiach wraz z rzutowaniem w kilku cyklach)

Co do EOD to nie wiem jak to tam jest rozwiązane (nie chce mi się /nie umiem/ analizować czyjegoś kodu) ale sądzę, że jest to podobnie jak u mnie.

Oczywiście możemy na karb stacji przerzucić kilka(naście) punktów i wtedy mamy maksymalną wydajność tylko to co pisze Kisiel , że lepiej policzyć w stacji i malować komciem jest wprowadzaniem w błąd bo w stacji nie da się za dużo punktów policzyć.

Jacek31 · #18 Post autor: **Jacek31** » 09 maja 2010, 11:57

Nitro daj linka do tej serii artykułów o wektorach. Jak nie chcesz bruździć nimi tu to prosze na PW.

#19 Post autor: **Nitro** » 09 maja 2010, 13:54

Aha, czyli z matematyką jestem do tyłu jeśli chodzi o wektory, już się zamykam

Wspomniane arty, nazywają się "A Different Perspective":
http://www.ffd2.com/fridge/chacking/c=hacking8.txt
http://www.ffd2.com/fridge/chacking/c=hacking9.txt
http://www.ffd2.com/fridge/chacking/c=hacking10.txt
Choć jak widać mogą służyć tylko i wyłącznie celom edukacyjnym, wszystko się rozwinęło.

zielok · #20 Post autor: **zielok** » 15 maja 2010, 22:46

Czytałem je kiedyś.. Polecam są naprawdę przydatne...

ps. Przeliczam już 380 punktów na frame (teraz biorę się jeszcze za generacje speedcode (bo na razie to działa w pętli)