Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Wyniki FujiCup 2023 Wyniki konkursu FujiCup na najlepszą grę dla 8-bit Atari w 2023 roku zostały ogłoszone!
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
czy macie jakies dane dotyczace tego ile cykli to wam zajmuje?
w tej chwili niezoptymalizowana procedurka jest w stanie obrocic 64 punkty na ramke
jestem ciekaw jak daleko jestem od sredniej
do obrotow uzywam macierzy rotacji (9 mnozen/punkt) fixed point 8.8
jaka rozdzielczosc?
jesli jakas niewielka to wygeneruj sobie tablice wynikow tych mnozen i korzystaj z gotowych wymnozen.
docelowo 160x240
mnozenie mam for fri
Ostatnio edytowany przez Candle (2011-08-14 10:26:10)
for free w sensie nie robi tego 6502? to w zasadzie jesli masz 9 mnozen na punkt to chyba maks jakie sie da uzyskac bez trikow i uproszczen.
nie mam gadu teraz, siedze na przetpotopowym kompie bo mam remont ;)
;-- s1*s3
mwa S1 Mul1
mwa S3 Mul2
mwa C3 Mul1
mwa Out1+1 S1S3
;-- c1*c3 & c2*c3
mwa C1 Mul2
nop
mwa Out1+1 C1C3
mwa C2 Mul2
nop
mwa Out1+1 C2C3
itd
Hey,
po podliczeniu cykli wyszło jakieś 620 na punkt (razem z projekcją), a więc w tym wypadku jesteś daleko - do przodu (zwłaszcza że u Ciebie jest 8.8). Tutaj stary przykładzik (main.obx):
http://matlos.w.interii.pl/scena_umiera.rar
pozdrawiam
nie wiem, czy z tego korzystasz, ale na tej stronce jest opisane jak obliczyć macierz obrotu bez mnożenia
podkreslam, mnozenia mam w 1 cyklu, wiec nie ma tu o co walczyc, dluzej sie dodaje i pcha dane w rejestry
smiglo: dzieki, piszesz ze jest tam juz projekcja, ale nie widze w scenie zeby bylo widac perspektywe
tak czy owak 620 cykli/punkt to calkiem niezle
ktos da mniej? ;)
mi wychodzi na sama rotacje 8bit->16.8->16bit (8bit input, wyliczenia 16.8 i 16bit output bez projekcji) dokladnie 353/365 cykli (best/worst case) na punkt
teoretycznie da sie to jeszcze przyspieszyc i miec 8bit->16.8->16bit w jakies 250-300cykli ale jeszcze nie mialem czasu aby zaimplementowac taka rotacje (w Controlu caly czas jest "stara" lekko podrasowana rotacja z The Shrine...)
dla 8bit->8.8->8bit powinno byc w obu przypadkach jeszcze szybsze o jakies 30-50cykli...
EDIT: aha jeszcze zapomnialem dodac, ze w tych 353/365 sa 3 dzielenia przez 128, jak by dac dzielenie przez 256 to bylo by o jakies ~51cykli szybsze...
Ostatnio edytowany przez pr0be (2011-08-14 15:32:29)
Candle: użyj macierzy 0.8.
zeby wspolczynniki byly 0.8? nie zacznie sie wszystko trzasc jak galareta?
W tej rozdzielczosci nie powinno bardzo skakac. Oczywiscie obliczajac macierz uzywaj wiekszej dokladnosci i dopiero przed mnozeniem punktow obetnij.
mam 195 cykli na punkt (mnozenie i mnozenie z akumulacja w sprzecie)
oczywiscie, pod warunkiem, ze umiem te cykle liczyc
cod:
mva #0 Mode ; 2 + 3 5
mwa Xx Mul1 ; 4 + 6 10
mva PointIn_x,x Mul2+1 ; 3 + 3 6
mva #1 Mode ; 2 + 3 5
mwa Xy Mul1 ; 4 + 6 10
mva PointIn_y,x Mul2+1 ; 3 + 3 6
mwa Xz Mul1 ; 4 + 6 10
mva PointIn_z,x Mul2+1 ; 3 + 3 6
nop ; 2 2
mva Out1+2 PointOut_x,x ; 3 + 3 6
i to samo x2 dla pozostalych współrzędnychktos widzi jakies szanse na optymalizacje tego loopa?
ldx #0
ldy #Points
sty tmp
ldy #0
stx Mul2
RotateXYZ_l0:
sty Mode ; 3
iny ; 2
mwa Xx Mul1 ; 10
mva PointIn_x,x Mul2+1 ; 6
sty Mode ; 3
mwa Xy Mul1 ; 10
mva PointIn_y,x Mul2+1 ; 6
mwa Xz Mul1 ; 10
mva PointIn_z,x Mul2+1 ; 6
dey ; 2
mva Out1+2 PointOut_x,x ; 6
sty Mode
iny
mwa Yx Mul1
mva PointIn_x,x Mul2+1
sty Mode
mwa Yy Mul1
mva PointIn_y,x Mul2+1
mwa Yz Mul1
mva PointIn_z,x Mul2+1
dey
mva Out1+2 PointOut_y,x
sty Mode
iny
mwa Zx Mul1
mva PointIn_x,x Mul2+1
sty Mode
mwa Zy Mul1
mva PointIn_y,x Mul2+1
mwa Zz Mul1
mva PointIn_z,x Mul2+1
dey
mva Out1+2 PointOut_z,x
inx
dec tmp
jne RotateXYZ_l0Fragment pętli dla każdej współrzędnej zajmuje 64 cykle:
RotateXYZ_l0:
sty Mode ; 3
iny ; 2
mwa Xx Mul1 ; 10
mva PointIn_x,x Mul2+1 ; 6
sty Mode ; 3
mwa Xy Mul1 ; 10
mva PointIn_y,x Mul2+1 ; 6
mwa Xz Mul1 ; 10
mva PointIn_z,x Mul2+1 ; 6
dey ; 2
mva Out1+2 PointOut_x,x ; 6 2*2 + 2*3 + 4*6 + 3*10 = 64
W takim loopie trudno już zjechać jakoś znacząco w dół - 6 cykli da się zaoszczędzić np trzymając w rejestrze Y któryś PointIn_:
ldy #0
RotateXYZ_l0:
sty Mode ; 3
mwa Xx Mul1 ; 10
mvy PointIn_x,x Mul2+1 ; 6 <- Y
mva #1 Mode ; 5
mwa Xy Mul1 ; 10
mva PointIn_y,x Mul2+1 ; 6
mwa Xz Mul1 ; 10
mva PointIn_z,x Mul2+1 ; 6
mva #0 Mode ; 5
mva Out1+2 PointOut_x,x ; 6 3+10+24+30=67
mwa Yx Mul1 ; 10
sty Mul2+1 ; 3 <- Y
mva #1 Mode ; 5
mwa Yy Mul1 ; 10
mva PointIn_y,x Mul2+1 ; 6
mwa Yz Mul1 ; 10
mva PointIn_z,x Mul2+1 ; 6
mva #0 Mode ; 5
mva Out1+2 PointOut_y,x ; 6 3+10+18+30=61
mwa Zx Mul1 ; 10
sty Mul2+1 ; 3 <- Y
mva #1 Mode ; 5
mwa Zy Mul1 ; 10
mva PointIn_y,x Mul2+1 ; 6
mwa Zz Mul1 ; 10
mva PointIn_z,x Mul2+1 ; 6
ldy #0 ; 2
mva Out1+2 PointOut_z,x ; 6 2+3+5+18+30=58Czy tak będzie działać?
Może udałoby się więcej wykombinować gdybyś napisał dokładniej jak działają te rejestry - bo jeśli np. Mode rozróżnia jedynie zero-niezero, to zamiast:
mva #1 Modemożna - indeksując X'em od jedynki - zaoszczędzić kolejnych 6 cykli:
stx ModeCzy hardware zmienia zawartość Mul1/Mul2+1?
mode = 0 - mul
mode = 1 - mac (multiply and accumulate)
mode = 2 - div
hardware nie rusza mul1/mul2
zapis do mul2+1 powoduje rozpoczecie obliczen
ze mnie dupa wolowa, a nie koder na 6502, wiec wybacz pytanie
a jest cos takiego jak ldy abs,x?
Jest.
Plwając jeszcze bezczelniej na estetykę kodu można próbować tak:
ldx #Points ; 2
mva #0 Mode ; 5
mwa Xx Mul1 ; 10
mva PointIn_x,x Mul2+1 ; 6
mva #1 Mode ; 5
mvy #Xy_LO Mul1 ; 5 Y: #Xy_LO
mva #Xy_HI Mul1+1 ; 5
mva PointIn_y,x Mul2+1 ; 6
mwa Xz Mul1 ; 10
mva PointIn_z,x Mul2+1 ; 6
mva #0 Mode ; 5
mva Out1+2 PointOut_x,x ; 6 2+25+24+20=71
@x
; tutaj już mamy Xz w Mul1
mva PointIn_z-1,x Mul2+1 ; 6
mva #1 Mode ; 5
sty Mul1 ; 3
mva #Xy_HI Mul1+1 ; 5
mva PointIn_y-1,x Mul2+1 ; 6
mwa Xx Mul1 ; 10
mva PointIn_x-1,x Mul2+1 ; 6
mva #0 Mode ; 5
mva Out1+2 PointOut_x-1,x ; 6 3+15+24+10=52
; a tu Xx
mva PointIn_x-2,x Mul2+1 ; 6
mva #1 Mode ; 5
sty Mul1 ; 3
mva #Xy_HI Mul1+1 ; 5
mva PointIn_y-2,x Mul2+1 ; 6
mwa Xz Mul1 ; 10
mva PointIn_z-2,x Mul2+1 ; 6
mva #0 Mode ; 5
mva Out1+2 PointOut_x-2,x ; 6 3+15+24+10=52
dex ; 2
dex ; 2
bpl @x ; 4 8(Analogicznie dla składowych Y i Z).
O ile jest OK, średnio na punkt daje to ze 172 cykle (troszkę mniej, jeśli nie ma przeciwwskazań aby robić inc/dec Mode). Jakbyś chciał porządniejszego kopa, to można okroić precyzję macierzy jak Fox radzi, rozpętlić kod i zaszyć tam współrzędne punktów (powinno dać się w <6kb przy tych 64-ech vertexach, a na atari nie takie kody derolowano :) ).
To może przeprogramuj hardware, żeby zamiast jednego rejestru mode były trzy, które wystarczy "zastrobować" (jak WSYNC). Kod 6502 powinien być wtedy krótszy.
Plwając jeszcze bezczelniej na estetykę kodu
Przepiękne stwierdzenie.
Skoro możesz zrobić część obliczeń w sprzęcie, to czemu tylko mnożenie, a nie np. całe obroty?
ach, bo to karta dzwiekowa
ja rozumiem 3d surround, ale nie rotacje
ach, bo to karta dzwiekowa
ja rozumiem 3d surround, ale nie rotacje
A czemu nie?
XXL gral muzyczki na GTIA, to Ty mozesz sobie zaprogramowac grafike 3D na dzwiekowce :D
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.092 sekund, wykonano 15 zapytań ]