home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 10: Diskmags / nf_archive_10.iso / MAGS / CHOSNECK / CHOS2.ZIP / CHOSNECK.2ND / STUFF / DATAS.ZIP / ART53B.SCR < prev    next >
Encoding:
Text File  |  2003-12-08  |  12.8 KB  |  243 lines
  1. <head>
  2. <title="...forever...">
  3. <font=monaco10.fnt>
  4. <font=newy36.fnt>
  5. <font=time24.fnt>
  6. <image=back.raw w=256 h=256 t=-1>
  7. <buf=3562>
  8. <bgcolor=-1>
  9. <background=0> 
  10. <link_color=253>
  11. <module=console.mod>
  12. <pal=back.pal>
  13. colors:
  14. 251 - black
  15. </head>
  16. <body>
  17. <frame x=0 y=0 w=640 h=3562 b=-1 c=-1>
  18.  
  19.  
  20. FRAMES OF REFERENCE
  21. -------------------
  22. Local screen and global world
  23. This  basic idea, about which many programmers in 80' never heard before. Lucky
  24. enough in our times this subject is well known. That's because it is used in 3D
  25. games. Objects in game exist even if player doesn't see them! Their coordinates
  26. are dependant to the game world, not the screen. In old times people stored all
  27. the creatures as offsets to screen and updated them while scrolling the screen.
  28. It  was not good, screen should be treated as a window which covers part of the
  29. game world. If we set view on the specified area then all the object located in
  30. given  region  will be displayed. Those outside are invisible, because they are
  31. outside of the screen. The coordinates of the world can be translated to screen
  32. coordinates  by  using  transformation  matrix.  For  platform  games it can be
  33. without  scaling  or  rotation  to  simplyfy  things like adding offset to both
  34. coordinates.
  35. Panel  objects  can  be  treated  in  another  way  and  can  depend  on screen
  36. coordinates, because they do not apply to the game world, but to our view.
  37.  
  38. Orthogonal systems - independent treatment of the coordinates
  39. Carthesian  coordinates are orthogonal. They are beautyful, because they can be
  40. treated  seperately  without  affecting each other. That means every time we do
  41. some  things (we add friction for example) in one dimension (like X), we can do
  42. everything  in  similar  way  with other axis (Y and Z), without worry how they
  43. will interact with each other.
  44.  
  45. Transformation matrix - conversion between frames of reference
  46. In  2D, there is possibility to transform frames of reference by multiplying by
  47. 2x2 matrix and adding two element vector:
  48. screenX = a*X+b*Y+e
  49. screenY = c*X+d*Y+f
  50.  
  51. Interesting   are  values  of  constants  a,b,c,d,e,f.  For  translation  (only
  52. scrolling)  a  and  c are 1, b and c are 0, d is scaling ratio (it's a identity
  53. matrix), e anf f are scrolling offsets. In case of scaling b and c are 0, a and
  54. d are scaling ratio.
  55.  
  56. For  rotation,  angle  is  an  angle of screen rotation depending on the world,
  57. scale  is  a  scale  of  screen  relative  to screen coordinates, e and f still
  58. represent  scrolling  offsets,  but they need to be adjusted to the rotation if
  59. you don't exchange X,Y coordinates before include them into the equation.
  60.  
  61. a = scale * sin(angle)
  62. b = scale * cos(angle)
  63. c = scale * cos(angle)
  64. d = scale * - sin(angle)
  65.  
  66. A cool  thing  is  that  when  using  matrices  to  coordinates transformation,
  67. different transformations  can  be used one after another by multiplying of two
  68. matrices.   In 3D 4x4 matrix can  hold  everything  you  need to know about the
  69. transformations  (viewing  fustrum  or fish-eyed  camera, method of perspective
  70. calculation (like rotation, scaling ) ) needed to render the scene.
  71.  
  72.  
  73. ITERATION
  74. ---------
  75. Computers  are  very  good at all the boring tasks like repeating over and over
  76. sets  of  instructions in FOR, WHILE etc. loops. Temporal discreetness in games
  77. forces us to writing all the code in different manner than in utility programs.
  78. Interactivity  of  game  requires  absence  of  long  pauses  during play while
  79. computer  tries  to estimate what to do next. The best solution is to split all
  80. of the calculating tasks and execute the outcoming parts one by one. When we do
  81. it,  then we have to estabilish how we force the computer to execute everything
  82. in  right  order, because in easy way we can wreak havoc in our internal memory
  83. destroying  everything.  The  main  tools  in hands of programmer are states or
  84. threads  (only available on operating systems like Magic/MiNT, they additionaly
  85. require synchronisation).
  86.  
  87. States - Controlling movement
  88. The  idea  of  Turing'a  Machine  states  that  computer consists of the state,
  89. program  and  access to given amount of variables. In original Turing's machine
  90. there was serial access to R/W location on the long tape, but we exchange it to
  91. the  random  access  to  given  amount of variables. Program is a simple set of
  92. rules,  which  tells  in  which state it must go if machine has given state and
  93. when  some  initial  variables  were found. Unstable or "virtual" states can be
  94. useful  under  several  circumstances,  but they require a little extra time of
  95. attention  to  avoid  infinite  loops. In this state, every time when change of
  96. state  occured,  program  control  is  passed  immadiately  to starting code of
  97. changed  state.  The  same  code  can decide that it once again needs to change
  98. state,  before  the  exit  from  the  routine.  It's  very important to prevent
  99. processor from "caughting in the loop", because it will be constantly switching
  100. between  the  states without passing control to the main loop. With a little of
  101. thought  is  possible  to  reduce  the amont of code required for simulating of
  102. intelligent behaviour.
  103.  
  104. List of states for simple enemy:
  105.  
  106. --------------------------------------------------------------------
  107. MARCH :
  108. Init - move in random direction
  109. Control - If player near then aim else march on
  110. Action - Hit the obstacle, reverse movement
  111. ---------------------------------------------------------------------
  112. AIM:
  113. Init - face to the player
  114. Control - If player above then jump, else charge
  115. Action - ------------------------------
  116. ----------------------------------------------------------------------
  117. JUMP:
  118. Init - Increase the initial speed
  119. Control - if landed charge, else further jump
  120. Action - fall under gravity
  121. ---------------------------------------------------------------------
  122. CHARGE:
  123. Init - move in direction of player
  124. Control - If player is too far then march else charge on
  125. Action - If Hit the obstacle, reverse movement
  126. ----------------------------------------------------------------------
  127.  
  128. In  this case AIM is unstable state which can lead to another states. It can be
  129. a  starting  point  of  changes to many states. Keeping track of states is very
  130. important  (which  variables  were stored during various function calls). If AI
  131. procedure  will return, all variables on stack will be destroyed, so pointer to
  132. variables  of  given  object is needed. Using pointers directly to functions is
  133. much  more  efficient  than  digging  throught  enumerated  states  with  giant
  134. switch (or case) instruction.
  135.  
  136. States  ( not United States ;))) ) can be implemented in code or as markers. In
  137. game  based  on  markers,  each  AI object is controlled by the list of markers
  138. representing  commands.  It  is very similar to byte codes in Java, but markers
  139. are on higher level and are more game specific.
  140.  
  141. Threads  - let the operating system do all the dirty stuff for you. Tracking of
  142. the  object  states  mustn't  be  pain  in  all  cases. There is a solution for
  143. generating  of  "anonymous states", which push all the work to game's operating
  144. system (there are rather low level task planning procedures than main operating
  145. system) instead of code for each object state.
  146.  
  147. This  method is sleep command - form of non-preemptive multitasking. You simply
  148. write  the  sleep  function, which uses as a parameter an amount of game frames
  149. you  want  to miss or handle to the state, which will wake up the function, e.g
  150. the  player will be closing in to object on given distance. When sleep function
  151. call  occurs,  the control is passed from AI function to the game planner. That
  152. means  each  object runs in it's own thread. The Round-Robin method can be used
  153. to  give enough time to the processor for all AI routines of objects or threads
  154. can  be  put in linked lists depending in which game frame they will awake. You
  155. have to decide which variables need to be stored while using sleep command. For
  156. example  we  don't  save  all of the registers, but frequently store stack (all
  157. local  variables  and  state  of  each called function). To do it we can assign
  158. local stack for each object and switch stack pointer (assembly languge required
  159. !!!)  This  method  requires  a  lot  of additional memory than the method with
  160. states,  because  it's  hard  to estimate how big stack area will be needed for
  161. each  routine.  Programmer  should  be also cautious to switch to system stack,
  162. each  time  hardware  interrupt  will occur to prevent the massacre on object's
  163. local  stack.  Another techniques can be used to more efficient use of memory -
  164. some  processors  can  detect  stack  overflow and this feature can be used for
  165. allocating  local  stacks  with  variable lenght. It is too risky option, if it
  166. comes about guaranteed time of reply, for use it in games.
  167.  
  168. Functions in background: revenge of complex calculations
  169. Using of threads let's using time consuming calculations in background, if they
  170. are preemptive of course. If we haven't preemptive threads, the use of hardware
  171. interrupts is required.
  172. For  example  game can be splitted onto 3 parts: display thread, AI main thread
  173. and  strategy  thread.  Main  AI  thread  is used once per earlier defined time
  174. period  to  make  game function at reasonable, constant pace. Display thread is
  175. called  less  frequently (ehm, maybe not if you have extremely fast machine) to
  176. update  the  screen to reflect what is going on currently in the game. Startegy
  177. threads are working on low-level in background and occasinally talk to the main
  178. AI    thread,  to  perform  some  complex  calculations  without  slowing  down
  179. everything.  Most  important  thing  in  all preemptive multi-threaded games is
  180. correct  handling  of  synchronisation  between  the processes. This subject is
  181. covered  well  in  all computer science courses. To remaind some things: double
  182. buffering    of  variables  until  "transaction"  (game  frame)  is  completed.
  183. "Transaction"  must be "atomic", unbreakable (it can be achieved in hardware by
  184. switching  off  all  interrupts  for  a  short  time  or  in  program  - banker
  185. algorythm).  Errors  in synchronisation are very hard to remove, so building of
  186. error free multithread systems is very important from the beginning.
  187.  
  188. PITFALLS
  189. - " Never assume anything what can't always be true ". False assertion can lead
  190. to  many problems. Always check everything before you will depend on something.
  191. For  example  if  you  assume  that  number  cannot  be  zero  or  negative (in
  192. simplifications connected with square roots), then if you accidentally put zero
  193. or  negative  number,  the  right  action  will  not be performed. The assert()
  194. function  is  just for that (very useful when we are launching DEBUG version of
  195. our  program). We can wipe out any possible problems, and it can be handy while
  196. beta-testing  (the  beta-tester  can tell you where and when problem occurs and
  197. possibly the name of the function which causes trouble.)
  198.  
  199. -  overflow:  numbers  too big or to small Check and watch the range of numbers
  200. you are using. If you will exceed the range, then some unpredictable things can
  201. happen. This can bring disaster:
  202.  
  203. for unsigned values:
  204. unsigned short int ourNumber = 0;
  205. ourNumber = 65535;
  206. ourNumber++;  // out of range!!!! (ourNumber = 0) !!
  207. ourNumber++;  //   (ourNumber =1)
  208.  
  209. and for signed values:
  210. signed short int ourNumber = 0;
  211. ourNumber = 32767;
  212. ourNumber++;  // out of range!!!! (ourNumber = -32768)!
  213. ourNumber++;  //   (ourNumber = -32767)
  214.  
  215. - Lack of precision: the numbers are too similar
  216. Two nubers which should be different are throwed into one sack, eg. numbers 2.1
  217. and 2.2 can be treated as 2. If the difference is important then this may cause
  218. problems.  The  difficulty of finding error increases when everything is inside
  219. complex  statement.  Especially  when  one  number is divided by second one and
  220. before  it  is  multiplied  by  another  number.  The  problem can be solved by
  221. performing  the  multiplication  before  the division. But most frequently used
  222. solution  is  changing  the scale of the number system. In this task, the fixed
  223. point math is very helpful.
  224.  
  225. The floating point numbers are another tale, they are very rarely identical, so
  226. checking  of their equality is rather risky business. So before checking we do:
  227. (abs(a-b)<c) instead of standard (a==b).
  228. The  b  variable can be earlier defined constant (0,001) when values will never
  229. be very small or proportion (like 0,01%) of chosen number.
  230.  
  231. Reference:
  232. ----------------
  233. "Math in games" by Carl Muller, Gamasutra 1st June 1997
  234. available online at www.gamasutra.com
  235.  
  236.  
  237. -- - --- -- -------------------------------------------------------------------
  238.  CHOSNECK 4th appearance                                           contact us:
  239.  done by the dream survivors                                 greymsb@poczta.fm
  240. ----------------------------------------------------------------- -- - --- ----
  241. </frame>
  242. </body>
  243.