Wektory

Szukasz drobnej pomocy przy kodowaniu, albo chcesz przedstawić światu swoją gotową lub w trakcie realizacji produkcję? To właściwy dział.
Wiadomość
Autor
fenek
Posty: 95
Rejestracja: 15 wrz 2008, 20:43
Grupa: Arise

#21 Post autor: fenek »

zielok pisze: 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)
Ja tylko pytam z czystej ciekawości, rozumiem że wcześniej liczysz macierz 9 elementow ? Ja cos takiego robilem do obracania prostych obiektow, wektory "cartoon/crayon" w sweet infection.
Na mala ilosc wierzcholkow u mnie dodawanie wygladalo tak samo tylko
parametry odwolywaly sie tylko do strony zerowej.
Czy mozesz miec dowolne wspolrzedne punktow obiektu w 3d czy obiekt wyglada jak we wszystkich demach jakby byl "przyciagniety" do "siatki 3d".
Pytalem o macierz, bo jak sie ma obliczona 9 elementowa macierz to mozna za pomoca tablic skalowania przeskalowac jedna macierz na
X macierzy (max. 27) i umiescic 28 macierzy 9 elementowych na stronie zerowej. Wtedy wszystkie obroty mozna zrobic na dodawaniach 8 bitowych 3 cyklowych adc $xx a nie adc $xxxx ale obiekt musi byc "przyciagniety" do siatki 3d okreslonej przez przeskalowane macierze.

offtop:
Serio mnie to interesuje, ja bardziej sie zastanawiam nad pojsciem w to co pokazal Graham w jednym dentrze zeby tego nieszczesnego sinusa rozszerzyc do 512 bajtow i 16 bitow lub wiecej.

Osobiscie uwazam ze ploty ktore zapierdalaja w jedna ramke powinny miec wartosci delt na katach mniejsze niz 1,4 stopnia.
:D

fenek
Posty: 95
Rejestracja: 15 wrz 2008, 20:43
Grupa: Arise

#22 Post autor: fenek »

Nitro pisze: ... proponuje też poznać sposób na plotery, ponad 256 dotsów w ramce, choć bez perspektywy, to chyba jest standardem teraz
Jeszcze sie odniose do tego choc moglem wyzej. Takie plotery kojarze z pierwszego ich wydania Oneder/Oxyron. Czy ja juz nie dowidze czy obiekty sa nadal "kwadratowe" przylegajace "do siatki" ?!?
Faktem jest ze robiac obiekty z odbijaniem mozna wtedy siatke wykorzystac na pol lub 1/4 obiektu "zwiekszajac" efektywnie dokladnosc całego tak utworzonego obiektu.

zielok
Posty: 438
Rejestracja: 07 lis 2008, 21:23
Kontakt:

#23 Post autor: zielok »

fenek pisze: Ja tylko pytam z czystej ciekawości, rozumiem że wcześniej liczysz macierz 9 elementow ? Ja cos takiego robilem do obracania prostych obiektow, wektory "cartoon/crayon" w sweet infection.
Na mala ilosc wierzcholkow u mnie dodawanie wygladalo tak samo tylko
parametry odwolywaly sie tylko do strony zerowej.
Optymalizacja w moim kodzie poszła już oczywiście dużo dalej tj także korzystam ze strony zerowej. Aktualnie mam osiągnięte przeliczenie 260 punktów na ramkę z malowaniem, czyszczeniem, double bufferem na fullscreenie. Oczywiście zostaję jeszcze spory zapas cykli (na muzykę i jeszcze trochę).

Macierz z racji rezygnacji z perspektywy ma 6 elementów (nie ma więcej potrzeby). Zrezygnowałem z wyliczania "Z" i obliczania perspektywy czyli wygląda to tak (pseudokod)

x'=x*matrix[0][0] +y*matrix[0][1] +z*matrix[0][2]
y'=x*matrix[1][0] +y*matrix[1][1] +z*matrix[1][2]

x' i y' zawierają już współrzędne do namalowania punktu 2d
fenek pisze:Czy mozesz miec dowolne wspolrzedne punktow obiektu w 3d czy obiekt wyglada jak we wszystkich demach jakby byl "przyciagniety" do "siatki 3d".
Hmm tego nie rozumie.
Z mojego rozumowania wychodzi, że mogę mieć dowolne (oczywiście w odpowiedniej skali).
Tylko, że w EOD czy OneDer także te obiekty wyglądają dla mnie normalnie.
fenek pisze:Pytalem o macierz, bo jak sie ma obliczona 9 elementowa macierz to mozna za pomoca tablic skalowania przeskalowac jedna macierz na
X macierzy (max. 27) i umiescic 28 macierzy 9 elementowych na stronie zerowej. Wtedy wszystkie obroty mozna zrobic na dodawaniach 8 bitowych 3 cyklowych adc $xx a nie adc $xxxx ale obiekt musi byc "przyciagniety" do siatki 3d okreslonej przez przeskalowane macierze.
A teraz chyba zrozumiałem to wcześniejsze:) Ja poszedłem w innym kierunku i u mnie wygląda to tak
Mam obliczoną macierz i "mnożę" z każdym elementem macierzy wszystkie możliwe wartości x,y lub z (w zależności z którym elementem "mnożę"). Tutaj są dodatkowe optymalizacje czyli liczę tylko wartości x,y i z dodatnie bo ujemne uzyskuje przy wyliczniu zamieniając adc na sbc
Reasumując, to obiekty mam tak samo jak we wszystkich demach przyciągnięte do siatki 3d. (no chyba, że nie zrozumiałem)
Twoje rozwiązanie wygląda ciekawie i dla testów chyba je zrobię (może będzie szybsze).
fenek pisze:offtop:
Serio mnie to interesuje, ja bardziej sie zastanawiam nad pojsciem w to co pokazal Graham w jednym dentrze zeby tego nieszczesnego sinusa rozszerzyc do 512 bajtow i 16 bitow lub wiecej.

Osobiscie uwazam ze ploty ktore zapierdalaja w jedna ramke powinny miec wartosci delt na katach mniejsze niz 1,4 stopnia.
:D
Ano zapierdzielają :) Ja jestem po testowej analizie (i o ile nie popełniłem gdzieś błędu) to takie rozwiązanie nie spowoduje znacznego spowolnienia (ale będzie wolniej :))

Ja popełniłem parę błędów przy projektowaniu... Najpierw zrobiłem przeliczanie bez macierzy (osiągnąłem bodajże 16 punktów - ale z perspektywą) potem użyłem macierzy, rezygnacja z perspektywy (i tak nie widać, że jej nie ma), zamiast lda $xxxx użyłem strony zerowej i mnóstwo innych optymalizacji. Mogłem to skodować zdecydowanie szybciej gdybym na początku dokładnie to przemyślał :)

fenek
Posty: 95
Rejestracja: 15 wrz 2008, 20:43
Grupa: Arise

#24 Post autor: fenek »

>Mam obliczoną macierz i "mnożę" z każdym elementem macierzy >wszystkie możliwe wartości x,y lub z (w zależności z którym elementem >"mnożę"). Tutaj są dodatkowe optymalizacje czyli liczę tylko wartości x,y i >z dodatnie bo ujemne uzyskuje przy wyliczniu zamieniając adc na sbc
>
Czyli robisz to sensowniej bo wyliczasz wartości dla współrzednych obiektu tak jak został zdefiniowany a mi chodzi oto ze mam wrażenie że obiekty
są najpierw zdefiniowane w 3D a potem ogranicza się "wszystkie możliwe wartośći" x,y,z tak żeby było ich jak najmniej i zmienia sie wartosci zdefiniowanego obiektu.
Moze to tylko moje wrazenie, chyba sie blizej temu przyjrze.

edit: oka już sie przyjrzałem już kumam, że jednak w EoD jest opisane że współrzędne dotow sa od siebie niezależne

Awatar użytkownika
Klax
Posty: 57
Rejestracja: 19 wrz 2010, 22:24

#25 Post autor: Klax »

zielok pisze:
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.
Zawsze można dołożyć 32kB ramu według mojego pomysłu ;)
Veni, Vidi, Vici :)

Awatar użytkownika
booker
Posty: 1272
Rejestracja: 08 paź 2008, 17:54
Grupa: MultiSyte Labz

#26 Post autor: booker »

No, i burstem ją, burstem! 8)
Takibardzodługipodpissetuszczelecobyśmiałchwilkęoddechuaizadumymożeewentualniewkurtegozestraciłeśpółminutyżycianaczytanietekstuoniczym.

k.

#27 Post autor: k. »

stacja szybciej punkty przeliczy niż c64 zdąży je narysować (wypełnianie itp)
Podkręć procka podkręć procka ;)

Jacek31
Posty: 230
Rejestracja: 02 maja 2009, 21:33

#28 Post autor: Jacek31 »

Nie wiem czy dobrze kombinuję, ale skoro macie stacje dysków i C64, to tak naprawdę jak spojrzycie na to od strony Hardweru to dysponujecie systemem 2 jajowym. Czyli należało by sięgnąć raczej po metody programowania równoległego (asynchronicznego, bo 2 różne zegary CPU), ewentualnie przetwarzanie potokowe.
Skoro stacja ma za mało RAMu ale jest za to szybka to może dobrym rozwiązaniem było by stworzenie do niej biblioteki czasochłonnych operacji graficznych, i wykorzystywać ja jako kooprocesor graficzny, który nie liczył by całości tylko "równolegle" do C64 bardziej wymagające elementy.
Oczywiście wymaga to stworzenia nowej koncepcji, i pewnie wykorzystanie przerwań oraz synchronizacji, ale powinno być wykonalne.
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.

fenek
Posty: 95
Rejestracja: 15 wrz 2008, 20:43
Grupa: Arise

#29 Post autor: fenek »

Przy odrobinie dobrych chęci można by się nawet pokusić
o zbudowanie macierzy z np. 3 stacji dyskow 1541 i c-64.
Wykorzystać to do wykonywania obliczeń 3d np. punktu.
Z c-64 wysyła się wierzchołek w 3d (wsp.X, Y, Z) do stacji rX.
W stacji rX wykonywane są procedury obrotu wierzchołka wokół
osi X. Po wykonaniu obliczeń nowe współrzędne przesyłane są do stacji rY.
W stacji rY wykonywane są procedury obrotu wierzchołka wokół osi Y.
( w tym samym czasie z c-64 przekazywane są współrzędne x,y,z kolejnego
wierzchołka do stacji rX).
Kolejno nowe współrzędne ze stacji rY wędrują do stacji rZ gdzie wykonywane
są procedury obrotu wierzchołka wokół osi Z. W tym czasie następuje przesłanie
danych ze stacji rX do stacji rZ i danych z c-64 do stacji rX.
Po obliczeniach ze stacji rZ wedruja dane do c64 i ten rysuje dota.
czyli: rZ->c64, rY->rZ, rX->rY
To tak mniej-więcej.

k.

#30 Post autor: k. »

niestety to będzie "zrzut kompo"... bo kto ma 3 stacje, trzeba by się zrzucić ;) Może lepiej zamiast 1541, użyć czegoś innego ?

Jacek31
Posty: 230
Rejestracja: 02 maja 2009, 21:33

#31 Post autor: Jacek31 »

Tzn. ja akurat nie jestem żadnym szpecem od robienia grafiki na C64, ale tak na logikę biorąc problem, to tak:
Najpierw należało by rozebrać silnik graficzny pod kątem pamięciożerności i nakładów obliczeniowych poszczególnych jego elementów. Jeżeli teraz weźmiemy pod lupę ten ulubiony teksturowany na drewnianą skrzynię sześcian, zbudowany z trójkątów, to mamy 12 poligonów składających się z 3 współrzędnych, czyli 36 wektorów do obliczenia/ przeliczenia. Tekstura żeby miała jakiś sens musi mieć rozmiar 64x64 pixele czyli 4096 punktów do przeliczenia/ścianę (maksymalnie), z korektą perspektywy dochodzą do tego dodatkowe operacje dzielenia/pixel (ale tu można sprytnie oszukiwać akurat). już tu widać żę obliczenia na wektorach, czyli cała geometria w przestrzeni 3D to zasadniczo mały ułamek obliczeń, natomiast teksturowanie jest strasznie czasochłonne, nie dla tego że jest skomplikowane, ale że trzeba przeliczyć masę elementów.
Ja bym więc z C64 zrobił Vertrx Shader, a z stacji dysków Pixel Shader.
No dobra ale jak w stacji zmieścić teksturę i program? wystarczy tylko program, który policzy na podstawie przesłanych współrzędnych 3D po transformacjach (np. obrót, skalowanie itd.) co trzeba wyśle do C64, adres pixela w teksturze który trzeba skopiować i adres pamięci obrazu gdzie go trzeba skopiować.
Oczywiście ja to uprościłem, ale powinno się to tak dać.
A szóstego dnia Bóg stworzył człowieka ... Aby mógł się napić.

Awatar użytkownika
Klax
Posty: 57
Rejestracja: 19 wrz 2010, 22:24

#32 Post autor: Klax »

kisiel pisze:niestety to będzie "zrzut kompo"... bo kto ma 3 stacje, trzeba by się zrzucić ;) Może lepiej zamiast 1541, użyć czegoś innego ?
Niektórzy mają 3 stacje 8) A czy dodatkowa pamięć (o której wcześniej wspomniałem) w stacji nie byłaby pomocna? Tu są chyba wektorki na stacji liczone http://noname.c64.org/csdb/release/?id=820 :)
Veni, Vidi, Vici :)

k.

#33 Post autor: k. »

Klax tak jak wszystko, najpierw to trzeba mieć...;)

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#34 Post autor: skull »

sorry ale dla mnie te wykorzystanie mocy drive-a, aby podnieść znacząco wydajność to mżonki (shadery heheheh). Na początku roku Wegi się w to bawił http://noname.c64.org/csdb/release/?id=87341,
warto uruchomić i poczytać komentarze. Niezbyt wysublimowania wektorówka, a nawet nie osiąga pełnej płynności - gdzie tu mowa o środowisku 3D.
Oczywiście jako ciekawostka to jest to ok, ale głównie cała rzecz "przepada" przy synchronizacji komunikacji, obsługa tego, to właśnie wąskie gardło - które w rezultacie daje gorsze efekty niż dobra kalkulacja wektorów na samym c64 (Andropolis). :cry:
Bo pecet to zwykły banan...

fenek
Posty: 95
Rejestracja: 15 wrz 2008, 20:43
Grupa: Arise

#35 Post autor: fenek »

Hmm, nie pamiętam już jak to dokładnie było, ale jako ciekawostka
stację można wykorzystać do generowania adresu jmp $xxxx.
Bity 7 i 6 $dd00 to chyba był stan ze stacji.
W c64 był kod rozdzielony na adresy $000x, $400x, $800x, $c00x
(jak się korzysta z $000x to dwa banki VICa w plecy 0 i 1) i wykonuje
się w krótkich liniach po 2 rastry (generuje tez te linie)i kończy instrukcją jmp ($ddff).
Młodszy bajt pobierany jest z $ddff (chyba to nie było stabilne)
a starszy z $dd00. Stacja generuje adresy procedur które mają być
wywołane przez c64 modyfikujac bity 7 i 6 $dd00 i generuje ten starszy bajt kodu.
Coś podobnego do jmp ($d011) z synchronizacją do lini rastra,
młodszy bajt z $d011 i starszy z $d012.

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#36 Post autor: skull »

Oczywiście ciekawe "kruczki", ja bym tam się nawet nie bawił w jmp ($ddff) tylko właśnie jmp($dd00) - czyli starszy bajt byłby w $dd01 [ Data Port B (User Port, RS232)] co by za bardzo nie komplikowało, za to jmp już byłby bezproblemowy -> każdy $xx00,$xx40,$xx80,$xxc0.
Ale co masz na myśli :
fenek pisze:) i wykonuje
się w krótkich liniach po 2 rastry (generuje tez te linie)...
Teoretycznie też jest w CIA, Serial Port Interrupt.
Bo pecet to zwykły banan...

k.

#37 Post autor: k. »

skull pisze:sorry ale dla mnie te wykorzystanie mocy drive-a, aby podnieść znacząco wydajność to mżonki (shadery heheheh). Na początku roku Wegi się w to bawił http://noname.c64.org/csdb/release/?id=87341,
warto uruchomić i poczytać komentarze. Niezbyt wysublimowania wektorówka, a nawet nie osiąga pełnej płynności - gdzie tu mowa o środowisku 3D.
Oczywiście jako ciekawostka to jest to ok, ale głównie cała rzecz "przepada" przy synchronizacji komunikacji, obsługa tego, to właśnie wąskie gardło - które w rezultacie daje gorsze efekty niż dobra kalkulacja wektorów na samym c64 (Andropolis). :cry:
Co do możliwości stacja-c64 warto zaznajomić się z realtime demko by Victor/ESM, na którymś northcie to było.
Co do wąskiego gardła, istnieje coś takiego w komciu jak USERPORT i sprzęcik CIA 6526 który umożliwia sprzętowe potwierdzenie odbioru. Teoretycznie można przesyłać tym portem 80kB/s, nie uważam to za wąskie gardło. Ja w moim komciu mam wersje bursta na 10 kabli, jedyny program co używał ten patent to bodaj burstnibbler oraz jakiś system load (nie pamiętam). Standard 8 kabelków, jest dziwny bo trzeba jeszcze potwierdzać softwarowo odbiór / nadanie... lub robić to synchronicznie.

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#38 Post autor: skull »

kisiel pisze:
skull pisze:sorry ale dla mnie te wykorzystanie mocy drive-a, aby podnieść znacząco wydajność to mżonki (shadery heheheh). Na początku roku Wegi się w to bawił http://noname.c64.org/csdb/release/?id=87341,
warto uruchomić i poczytać komentarze. Niezbyt wysublimowania wektorówka, a nawet nie osiąga pełnej płynności - gdzie tu mowa o środowisku 3D.
Oczywiście jako ciekawostka to jest to ok, ale głównie cała rzecz "przepada" przy synchronizacji komunikacji, obsługa tego, to właśnie wąskie gardło - które w rezultacie daje gorsze efekty niż dobra kalkulacja wektorów na samym c64 (Andropolis). :cry:
Co do możliwości stacja-c64 warto zaznajomić się z realtime demko by Victor/ESM, na którymś northcie to było.
Co do wąskiego gardła, istnieje coś takiego w komciu jak USERPORT i sprzęcik CIA 6526 który umożliwia sprzętowe potwierdzenie odbioru. Teoretycznie można przesyłać tym portem 80kB/s, nie uważam to za wąskie gardło. Ja w moim komciu mam wersje bursta na 10 kabli, jedyny program co używał ten patent to bodaj burstnibbler oraz jakiś system load (nie pamiętam). Standard 8 kabelków, jest dziwny bo trzeba jeszcze potwierdzać softwarowo odbiór / nadanie... lub robić to synchronicznie.
Kisiel mówisz o szybkości transmisji - co w tym przypadku pełni rolę drugorzędną: może być i 1MBajt/s, najważniejsza jest obsługa wyślij-odbierz, a to się wiąże albo z opóźnieniami (czekaniem) i po jednej i po drugiej stronie (a im test częstszy tym właśnie zabiera wiecej mocy proca im żadszy tym większe są czasy oczekiwania)- właśnie wtedy "cała para w gwizdek idzie".
Nie mówię też że taki układ nie przyspiesza obliczeń - niestety jest to niedużo więcej.

Brakuje sprzętowego bufora danych.
Bo pecet to zwykły banan...

k.

#39 Post autor: k. »

hmm a wiesz jak działa realtime victora? c64 rysuje ramkę i nie czeka na stację bo stacja i tak szybciej przeliczy transformacje niż komcio wyrysuje ją na ekranie. Szybkość portu nie ma znaczenia, bo to przekazywanie danych dla kilku punktów. Burst ma jedną zasadniczą zaletę nie trzeba go cyklować więc można mieć procki o różnych prędkościach i będą one działać bez błędów.

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#40 Post autor: skull »

kisiel pisze:... c64 rysuje ramkę i nie czeka na stację ...
i to jest cały problem - NIE CZEKAĆ
Bo pecet to zwykły banan...

ODPOWIEDZ