c64scene.pl

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.

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.

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.

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ł

>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

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

No, i burstem ją, burstem!

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

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.

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.

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

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

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

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

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

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.

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.

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

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

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.

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.

kisiel pisze:... c64 rysuje ramkę i nie czeka na stację ...

i to jest cały problem - NIE CZEKAĆ