home *** CD-ROM | disk | FTP | other *** search
/ Amiga MA Magazine 1997 #3 / amigamamagazinepolishissue03-1 / ma_1995 / 04 / ami038.txt < prev    next >
Text File  |  1997-04-06  |  10KB  |  209 lines
  1.  
  2.  
  3. Jak ulepszyê procedurë? (odc. 6.)
  4. ---------------------------------
  5.  
  6. TEXTURED VECTORS
  7.  
  8. <lead>Ostatnio w kaûdym dobrym demie moûemy ujrzeê tzw.
  9. wektorówki teksturowane, czyli majâce naîoûonâ na ôciany grafikë.
  10. Jak stworzyê takie "cudo"?
  11.  
  12. <a>Miklesz/Damage
  13.  
  14. <txt>Sâ w zasadzie dwie metody. Pierwsza polega na odpowiednim
  15. rysowaniu ôcian i specjalnym nanoszeniu na nie grafiki. Trzeba
  16. jednak mieê na uwadze, ûe metoda ta wymaga trochë wiëkszego
  17. wkîadu pracy, a omówië jâ w póúniejszych odcinkach, przy okazji
  18. przedstawiania cieniowania ôcian (Gouraud). Natomiast drugi
  19. sposób polega na obracaniu wszystkich punktów obrazka i rysowaniu
  20. ich po kolei. Jest to sposób stosunkowo prosty, lecz niezbyt
  21. szybki. Z uwagi na jego prostotë zajmë sië nim dzisiaj i
  22. postaram sië dokîadnie go omówiê...
  23.  
  24. Wyobraúmy sobie, ûe chcemy obróciê "obrazek" o rozmiarach 16 x 16
  25. pikseli (dla uproszczenia). Normalnie mamy 16 x 16 = 256 punktów
  26. do przeliczenia. Nieprzyzwoicie duûo. Przy wiëkszych rozmiarach
  27. to i Silicon nie da sobie rady. Ale jest na to rada, podam Wam
  28. sposób, jak obliczajâc JEDEN punkt, moûemy poznaê pozycje
  29. wszystkich punktów kwadratowego obrazka! Ale zacznijmy od
  30. poczâtku...
  31.  
  32. Najpierw taka umowa: wszystkie punkty ponumerowane sâ od (0,0) do
  33. (F,F). Da nam to klarowny obraz, który "dot" mam akurat na myôli.
  34. Jak juû wspominaîem, rotujemy jeden punkt, ten o symbolu (0,0).
  35. To juû 1/256 sukcesu! Zaraz bëdziemy juû znali dwa punkty.
  36. Zauwaûmy, ûe punkt (F,0) moûemy otrzymaê, zamieniajâc wspóîrzëdne
  37. (X,Y) punktu (0,0) ze sobâ, a nastëpnie negujâc Y. Radzë to sobie
  38. przeanalizowaê na ukîadzie wspóîrzëdnych (jest to tzw. mirror
  39. cheating). Nastëpnym krokiem bëdzie wyliczenie punktów na caîej
  40. krawëdzi pomiëdzy (0,0) i (F,0). Poniewaû tak sië zîoûyîo, ûe
  41. znamy liczbë punktów wchodzâcych w jej skîad i w naszym wypadku
  42. wynosi ona 16, moûemy brakujâce wspóîrzëdne wyliczyê, korzystajâc
  43. z proporcjonalnoôci. Wiëkszoôê z Was zrozumiaîa juû zapewne, o co
  44. chodzi. Dla tych, którzy sië jeszcze z takim dziwadîem nie
  45. spotkali, podajë wzór ogólny:
  46.  
  47. <r>
  48. I -- indeks
  49.  
  50. N -- liczba punktów;
  51.  
  52. X0 -- wspóîrzëdna X punktu (0,0);
  53.  
  54. Xn -- wspóîrzëdna X punktu (N,0);
  55.  
  56. Xi -- wspóîrzëdna X punktu (I,0);
  57.  
  58. Y0 -- wspóîrzëdna Y punktu (0,0);
  59.  
  60. Yn -- wspóîrzëdna Y punktu (N,0);
  61.  
  62. Yi -- wspóîrzëdna Y punktu (I,0);
  63.  
  64. Xi=(Xn-X0)/N*I+X0
  65.  
  66. Yi=(Yn-Y0)/N*I+Y0
  67.  
  68. <txt>Nooo.... Teraz juû chyba wszystko jest jasne. Jak zapewne
  69. zauwaûyliôcie, osiâgnëliômy juû 16 punktów i gwarantujë Wam, ûe
  70. teraz pozostaje jedynie kilka dodawaï i odejmowaï, aby otrzymaê
  71. wszystkie 256 punktów obrazka!
  72.  
  73. Zauwaûmy, ûe nasza krawëdú to 1/16 obrazka. Gdybyômy potraktowali
  74. jâ jako linië i nastëpnie odpowiednio 15 razy skopiowali,
  75. przesuwajâc za kaûdym razem o odpowiedni wektor, to
  76. otrzymalibyômy peîny obrazek! No dobrze, ale skâd wiedzieê, o
  77. jaki wektor przesuwamy? Nic trudnego... Wektor pomiëdzy punktem
  78. (0,0) a (0,1) jest równy wektorowi pomiëdzy (0,0) i (1,0),
  79. obróconemu w prawo o 90 stopni. Jak obróciê wektor o kât prosty,
  80. juû wiecie (wykorzystamy do tego mirror cheating). Czynnoôê
  81. kopiowania wspóîrzëdnych z translacjâ powtarzamy 15 razy i mamy
  82. obrócone wszystkie punkty obrazka! Teraz wystarczy tylko nanieôê
  83. to wszystko na ekran.
  84.  
  85. Na razie jedynie chwaliîem ten sposobik. Teraz coô o jego wadach.
  86. Po pierwsze obojëtnie jak maîy obszar zajmowaîaby ôcianka na
  87. ekranie, to i tak obliczamy wszystkie punkty obrazka úródîowego,
  88. mimo ûe duûa ich czëôê sië pokryje. Po drugie kiedy z kolei
  89. zaczniemy powiëkszaê ôcianë, zacznâ powstawaê "dziury". Dlatego
  90. najlepiej wykorzystaê sposób podany przeze mnie do wszelkiego
  91. rodzaju teksturowanych obiektów punktowych, majâcych wyraúne
  92. oddzielone od siebie punkty. Trzeciâ wadâ jest sprawa
  93. perspektywy, która musi byê, niestety, staîa dla caîej ôciany lub
  94. czasami nawet dla caîego obiektu. Bywa, ûe wpîywa to ujemnie na
  95. koïcowy efekt. Tak czy siak metoda jednak dziaîa, a przykîadem
  96. jej wykorzystania mogâ byê, zrobione przeze mnie, trzy
  97. teksturowane szeôciany, obracajâce sië w demie "Noxzema"/Damage.
  98.  
  99. Po tej dawce teorii na temat rotowania punktów, parë praktycznych
  100. uwag. Jak zapewne zauwaûyliôcie, wektory, np. pomiëdzy (0,0) i
  101. (1,0) oraz pomiëdzy (1,0) i (2,0), sâ sobie równe. Dlaczego wiëc
  102. nie wyliczyê ich raz, a póúniej tylko powielaê? Moûna, ale
  103. zauwaûcie, ûe najczëôciej nie majâ one wartoôci caîkowitej. W
  104. zwiâzku z tym caîy obrazek przeskakiwaîby wyraúnie i trudno by
  105. byîo uznaê jego drgawki za rotacjë. Oczywiôcie jeûeli mamy
  106. koprocesor matematyczny, to problem z gîowy, lecz co wtedy, gdy
  107. nie jesteômy wîaôcicielami FPU? Pozostaje nam jedynie symulacja
  108. liczb zmiennoprzecinkowych na liczbach staîoprzecinkowych.
  109. Zacznë od przykîadu, którego bezpoôrednio nie moûna by byîo
  110. wykorzystaê w asemblerze, z uwagi na mnoûenie przez potëgi liczby
  111. 10, a nie 2. My jednak procesorami nie jesteômy, wiëc 10 wyglâda
  112. dla nas trochë przyjaúniej. Ale moûe po kolei...
  113.  
  114. Przypuôêmy, ûe chcemy pomnoûyê liczbë 12,34 przez 56,78.
  115. Normalnie procesor gîówny obciâîby wszystko to, co po przecinku,
  116. i otrzymalibyômy 12 x 56 = 672. Jest to oczywiôcie niezgodne z
  117. prawdziwym wynikiem wynoszâcym 12,34 x 56,78 = 700,6652.
  118. Przypuôêmy, ûe jeszcze bîâd rzëdu +1/-1 byîby dopuszczalny, ale
  119. pomyîka o prawie 1/10 wyniku to juû powaûna sprawa. A caîoôê
  120. wyglâda jeszcze groúniej, kiedy musimy póúniej zsumowaê kilka
  121. bîëdnie wyliczonych wartoôci! Ale jest sposób na otrzymywanie
  122. dokîadniejszych wyników. Najpierw nasze dwie wartoôci pomnóûmy
  123. przez 100 (czyli przesuïmy przecinek na koniec cyfry). Otrzymamy
  124. 1234 i 5678. Teraz spokojnie mnoûymy obie liczby przez siebie,
  125. otrzymujâc w wyniku 7 006 652. Nastëpnie caîoôê dzielimy przez
  126. 100 000 (liczba zer jest oczywiôcie sumâ miejsc, o które
  127. przesunëliômy wczeôniej przecinek, zresztâ chyba wszyscy
  128. pamiëtamy to z podstawówki :-). Wynik: 7 006 652, czyli po
  129. odjëciu zer, równe 700. Bîâd wyniósî 0,6652, jest to znacznie
  130. mniej niû jeden procent caîoôci, a to chyba dokîadnoôê
  131. wystarczajâca, aby nasza wektorówka wyglâdaîa estetycznie.
  132.  
  133. Pozostaje pytanie, jak to wszystko mnoûyê w asemblerze? To
  134. proste, wszelkie operacje wykonujemy przy liczbach juû wczeôniej
  135. przemnoûonych przez jakâô potëgë dwójki, czego dokonujemy
  136. oczywiôcie nie przez MULa.b, lecz przez przesuniëcia bitowe. Tu
  137. warto zwróciê uwagë, ûe im bardziej wczeôniej przeskalujemy
  138. wartoôci poczâtkowe, tym dokîadniejszych wyników moûemy póúniej
  139. oczekiwaê. Oczywiôcie tak îatwo nie da sië uzyskaê samych liczb z
  140. wartoôciami po przecinku. Majâc jedynie CPU, moûemy uzyskaê takie
  141. wartoôci jedynie w wyniku dzielenia przez siebie liczb juû
  142. przeskalowanych. Obecnie na 68EC020++ moûemy juû operowaê na
  143. QuadWordach, tak wiëc zakresów nam raczej nie zabraknie. Jeûeli
  144. zaô chodzi o przesuwanie bitowe, to polecam szybkâ instrukcjë
  145. SWAP.W, która w "ekspresowy" sposób z kaûdej liczby $0000abcd,
  146. zrobi nam przeskalowanâ $abcd0000. Naleûy oczywiôcie pamiëtaê, ûe
  147. wszelkie operacje na przeskalowanych wartoôciach muszâ mieê
  148. rozmiar dîugiego sîowa (.L), gdyû mniejsze rozmiary bëdâ
  149. dotyczyîy jedynie cyfr "po przecinku". Kiedy juû wyliczymy sobie
  150. to, co potrzebujemy, jednym SWAP-em sprowadzamy liczbë "na
  151. ziemië", czyli obcinamy zera (w zasadzie to wysyîamy je "do
  152. góry", lecz przy dalszych operacjach na samym sîowie (.W) nie ma
  153. to juû znaczenia, choê czasami moûe warto i o tym pamiëtaê), a
  154. czëôê caîkowitâ otrzymujemy w dolnych szesnastu bitach rejestru.
  155. Proste?
  156.  
  157. Jeûeli na razie nie mieliôcie zbyt dîugiego kontaktu z
  158. teksturowanymi wektorówkami, to muszë uprzedziê, ûe ten typ
  159. efektów naleûy do "raczej" czasochîonnych, i to zarówno w sensie
  160. czasu poôwiëconego na napisanie procedury, jak i czasu
  161. ekranowego, potrzebnego do narysowania wszystkich ôcian.  One
  162. Frame naleûy tu do rzadkoôci, a co bardziej skomplikowane obiekty
  163. na wolniejszych maszynach poruszajâ sië niebywale wolno, mimo ûe
  164. koder naprawdë wycisnâî z Amigi, co sië tylko daîo. Dla tych,
  165. którzy jeszcze nie widzieli lub nie sîyszeli, podajë, ûe ostatnio
  166. w demach zachodnich pojawiajâ sië obiekty teksturowane i przy
  167. okazji na przykîad deformowane, cieniowane.
  168.  
  169. Przy okazji pragnë wyjaôniê, ûe wszelkiego rodzaju WolfSteiny i
  170. Doomy sâ zazwyczaj (choê nie zawsze) wektorówkami. Te wszystkie
  171. prostsze sâ zbliûone bardziej do tzw. Comanche'y (wszystkie te
  172. nazwy pochodzâ oczywiôcie od gier pecetycznych, w których dany
  173. efekt pojawiî sië po raz pierwszy). Zastanawiaê moûe fakt,
  174. dlaczego to kompatybilni pierwsi zaczëli tworzyê takie rzeczy.
  175. Jest to skutkiem nieposiadania przez koôci OCS, ECS i AGA trybu
  176. chunky pixel. Operacje na bitplane'ach, jak wiadomo, choê
  177. upraszczajâ tworzenie na przykîad "Glenz Vectorów", to
  178. spowalniajâ stawianie pojedynczych punktów w duûej liczbie
  179. kolorów. Teoretycznie nawet do oômiu razy. W tej sytuacji dopiero
  180. pojawienie sië trybu chunky, czëôciowo emulowanego na Copperze,
  181. oraz szybkich konwerterów "Chunky To Plannar" przyôpieszyîo
  182. rozwój wszelkiej grafiki teksturowanej i cieniowanej.
  183.  
  184. Nim zakoïczë dzisiejszy odcinek, zabiorë jeszcze gîos w takiej
  185. pewnej sprawie... Doszîy mnie sîuchy, ûe Szanowni Czytelnicy
  186. zareagowali na mój cykl dotyczâcy asemblera. Z jednej strony
  187. cieszë sië, gdyû znaczy to, ûe ktoô czyta, to co ja tam bazgrzë,
  188. a to juû jest sukces. Z drugiej strony jednak okazaîo sië, ûe
  189. Szanowni Czytelnicy zareagowali negatywnie... A to juû mniej
  190. cieszy. A wîaôciwie, to wcale. Jednak nikt z Was nie zaproponuje
  191. nic konstruktywnego, tylko mówicie (najczëôciej do sîuchawki), ûe
  192. Wam sië nie podoba i juû. Jeûeli macie jakiô pomysî, to
  193. powiedzcie, a nie tylko krytykujcie. Jeûeli chcecie, bym napisaî
  194. np. o tunelach, to napiszë. Jeûeli jednak po prostu nie podoba
  195. Wam sië cykl sam w sobie (lub moja osoba, co teû jest
  196. prawdopodobne), to po prostu dam sobie spokój i po mnie ktoô inny
  197. zacznie n-ty cykl pt. "Jak otworzyê okienko i napisaê w nim: Tu
  198. byîem, Tony Halik" ;-) Czy jednak komuô sië to naprawdë przyda
  199. przy kodowaniu dema?
  200.  
  201. Oglâdajâc najnowsze dema, dochodzi sië do wniosku, ûe
  202. teksturowane wektory sâ domenâ nie tylko pecetów. Amiga, mimo
  203. braku chunky pixel, radzi sobie nieúle z generowaniem takich
  204. obiektów. Wam równieû ûyczë wspaniaîych "teksturowaïców". Juû
  205. dziô zapowiadam, ûe w nastëpnym odcinku dogonimy niebieskiego w
  206. kolejnej branûy... Wykonamy lot nad fraktalowymi górami,
  207. rysowanymi, oczywiôcie, w czasie rzeczywistym!
  208.  
  209.