Skrypt forum został zaktualizowany
Wszelakie błędy, pytania oraz prośby o nową funkcjonalność zgłaszajcie w tym wątku

Wektory

Szukasz drobnej pomocy przy kodowaniu, albo chcesz przedstawić światu swoją gotową lub w trakcie realizacji produkcję? To właściwy dział.
Wiadomość
Autor
zielok
Posty: 438
Rejestracja: pt lis 07, 2008 9:23 pm
Kontaktowanie:

Wektory

#1 Postautor: zielok » wt mar 03, 2009 9:18 pm

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?

Awatar użytkownika
Nitro
Posty: 1182
Rejestracja: śr wrz 03, 2008 8:23 pm
Grupa: Black Sun

#2 Postautor: Nitro » wt mar 03, 2009 10:05 pm

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ę :wink:

zielok
Posty: 438
Rejestracja: pt lis 07, 2008 9:23 pm
Kontaktowanie:

#3 Postautor: zielok » wt mar 03, 2009 10:36 pm

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ę :wink:


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....

Awatar użytkownika
prezes
Posty: 213
Rejestracja: pn wrz 15, 2008 5:40 pm

#4 Postautor: prezes » śr mar 04, 2009 10:34 am

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

śmigło .::.
Posty: 7
Rejestracja: pn wrz 15, 2008 9:22 pm
Grupa: blowjobb

#5 Postautor: śmigło .::. » czw mar 05, 2009 10:51 am

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...

Awatar użytkownika
Nitro
Posty: 1182
Rejestracja: śr wrz 03, 2008 8:23 pm
Grupa: Black Sun

#6 Postautor: Nitro » czw mar 05, 2009 6:11 pm

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
Posty: 438
Rejestracja: pt lis 07, 2008 9:23 pm
Kontaktowanie:

#7 Postautor: zielok » czw mar 05, 2009 7:50 pm

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.

Awatar użytkownika
wegi
Posty: 380
Rejestracja: wt lip 14, 2009 1:17 am
Grupa: ESM
Kontaktowanie:

#8 Postautor: wegi » wt lip 14, 2009 1:40 am

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
Posty: 438
Rejestracja: pt lis 07, 2008 9:23 pm
Kontaktowanie:

#9 Postautor: zielok » wt lip 14, 2009 12:47 pm

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

zielok
Posty: 438
Rejestracja: pt lis 07, 2008 9:23 pm
Kontaktowanie:

#10 Postautor: zielok » sob maja 08, 2010 8:58 pm

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 Postautor: k. » sob maja 08, 2010 9:04 pm

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

Awatar użytkownika
Nitro
Posty: 1182
Rejestracja: śr wrz 03, 2008 8:23 pm
Grupa: Black Sun

#12 Postautor: Nitro » sob maja 08, 2010 9:09 pm

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

Awatar użytkownika
leming
Posty: 524
Rejestracja: pn wrz 15, 2008 10:15 am
Grupa: Onslaught, Fatum

#13 Postautor: leming » sob maja 08, 2010 11:07 pm

to jak to najlepiej ma byc? liczone troche na stacji a wiekszosc na komie? to cos da?
Ten post wyraża moją opinię w dniu dzisiejszym.Nie może on służyć przeciwko mnie w dniu jutrzejszym,ani każdym innym następującym po tym terminie.Ponadto zastrzegam sobie prawo zmiany poglądów bez podania przyczyny.

k.

#14 Postautor: k. » sob maja 08, 2010 11:19 pm

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

zielok
Posty: 438
Rejestracja: pt lis 07, 2008 9:23 pm
Kontaktowanie:

#15 Postautor: zielok » ndz maja 09, 2010 12:01 am

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.

Awatar użytkownika
Nitro
Posty: 1182
Rejestracja: śr wrz 03, 2008 8:23 pm
Grupa: Black Sun

#16 Postautor: Nitro » ndz maja 09, 2010 12:30 am

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
Posty: 438
Rejestracja: pt lis 07, 2008 9:23 pm
Kontaktowanie:

#17 Postautor: zielok » ndz maja 09, 2010 10:36 am

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
Posty: 230
Rejestracja: sob maja 02, 2009 9:33 pm

#18 Postautor: Jacek31 » ndz maja 09, 2010 11:57 am

Nitro daj linka do tej serii artykułów o wektorach. Jak nie chcesz bruździć nimi tu to prosze na PW.
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.

Awatar użytkownika
Nitro
Posty: 1182
Rejestracja: śr wrz 03, 2008 8:23 pm
Grupa: Black Sun

#19 Postautor: Nitro » ndz maja 09, 2010 1:54 pm

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
Posty: 438
Rejestracja: pt lis 07, 2008 9:23 pm
Kontaktowanie:

#20 Postautor: zielok » sob maja 15, 2010 10:46 pm

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)


Wróć do „Programowanie & Produkcje”

Kto jest online

Użytkownicy przeglądający to forum: Google [Bot] i 3 gości