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 / ART49.SCR < prev    next >
Encoding:
Text File  |  2003-12-09  |  7.5 KB  |  195 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=2805>
  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=2805 b=-1 c=-1>
  18.  
  19.            
  20. - --- - -----------------------------------------------------------------------
  21. <f1><c000>      Some hints for 3D coding <f0>
  22. --------------------------------------------------------------------- - --- --- 
  23.  
  24. This shouldn't be a complex tutorial  or  anything,  simply I've got an idea to
  25. write some of my  experiences  I  got  in  my  beginnings.  In other words, the
  26. lamers' area starts here =)
  27.  
  28. Structures
  29. ==========
  30. Believe or not, but the  amount  of  time  you'll  spend with improving your 3D
  31. engine directly depends on structuring your data.  A typical example is a cube;
  32. you wont write 4 points for every face  (24  points) but only 8 points and your
  33. basic structure will look:
  34.  
  35. face1: dc.l p1,p2,p3,p4
  36. face2: dc.l p2,p5,p6,p3 ... etc This lead us to
  37.  
  38. Pointers
  39. ========
  40. I've seen a lot of C sources where  structures are used, but only as parameters
  41. by calling a poly routine for  example  and then using "direct" values. Sorting
  42. by y-coordinates was done by simple 3-compares swapping. This is no problem for
  43. flat-shaded poly for example, but if you're  coding a texture mapper, your face
  44. looks like:
  45.  
  46. face1: dc.l p1,p2,p3,p4,t_p1,t_p2,t_p3,t_p4
  47.  
  48. Yeah ppl, I've even seen source which swaps x, y, tx, ty values for every point
  49. ! Best solution is to load  only  y-values  into registers and swap pointers to
  50. texture coordinates. As  I  wrote:  better  structure  =  less complications in
  51. future (no one says this is that structure :-))
  52.  
  53. Clipping
  54. ========
  55. You know that - you have working rotation  of 3D object, but you aren't free to
  56. set any parameters you want, you have to be careful about the size of projected
  57. picture becoz of videoram  limits.  But  hey,  we  aren't  owners  of stupid PC
  58. machines! Imagine the meaning of "clipping": you  have some big scene and small
  59. window (our screen) you are  looking  through.  Clipping  algorithms do in most
  60. cases two things:
  61.  
  62. 1) if a whole polygon is in/out of screen - skip it
  63. 2) if some part of a polygon is on boundary, clip it
  64.  
  65. And this clipping is done  using  brutal  methods  (if  you  ever tried to code
  66. simple line clipper, you know what I'm talking about)
  67.  
  68. Please note that word "window" in my explanation: it's similar to the human eye
  69. - if you see something, you see it. If  not, you don't see it (logical :-)) And
  70. why we can't do it on our Falcon, too?  Hey,  we  can do it ! Simply if a whole
  71. polygon is out of screen, you don't draw  it.  And if it lies on a boundary, we
  72. leave it as it is ! More  concretely  -  if you reserve some space "around" the
  73. screen ram area,  you  can  drop  any  clipping  and  start  to  show this cool
  74. advantage to PC coders :)) Top  and  bottom areas aren't problem. In horizontal
  75. direction you need  to  increase  number  of  words  per  line (using $ffff820e
  76. register) and here you are - clipped picture without any clipping :)
  77.  
  78. Sorting
  79. =======
  80. Another big mystery in 3D coding. We are in need of sorting faces if you rotate
  81. inconvex objects, here face killing by dot product isn't enough. Most simple is
  82. the bubble sort. It's nice,  small  and  slow.  Then comes sort-algorithms like
  83. insert, merge or quicksort.  I  can  code  none  of  these algorithms :))) Some
  84. months ago I found very nice  sort-algorithm  called  Radix sort. It's based on
  85. the idea numbers aren't sorted  but  they  are  used  as indexes. Ofcourse your
  86. number should be positive and  <256  (in  the  simplest  case).  So you have to
  87. allocate 256*n words in memory, where  n  is  number  of entries. Here you are,
  88. some C lame code:
  89.  
  90. int radix (int *array, int entries) {
  91.  
  92. int *low_radix_stack[256];
  93. int hash_entry [256];
  94. int i, j, k;
  95.  
  96. /* init part */
  97. for (i=0; i<256; i++) {
  98.         hash_entry [i] = 0;
  99.         low_radix_stack[i] = (int *)malloc (entries*sizeof(int));
  100.         if (low_radix_stack[i] == NULL) {
  101.                 printf ("\nNo memory");
  102.                 return (1);
  103.                 }
  104.         }
  105.  
  106. /* "sorting" */
  107. for (i=0; i<entries; i++) {
  108.         j = array [i];
  109.         k = hash_entry [j];
  110.         low_radix_stack [j][k] = j;
  111.         hash_entry [j] ++;
  112.         }
  113.  
  114. k = 0;
  115.  
  116. /* save sorted values */
  117. for (i=0; i<256; i++) {
  118.         for (j=0; j<hash_entry[i]; j++, k++) {
  119.                 array[k] = low_radix_stack [i][j];
  120.                 }
  121.         }
  122.  
  123. return (0); }
  124.  
  125. Please note this code is  totally  unoptimized.  This algorithm has a fantastic
  126. Advantage in that the speed  needed  for  "sorting"  is increased LINEARLY. And
  127. memory needed for stacks is again  increased  linearly  (512*n words for 16 bit
  128. radix etc) Of course, you can code  "true"  16 bit radix with stacks of 65536*n
  129. size, but this is very much even for PCs  :-) It's very easy to rewrite it into
  130. 030 asm, it can be optimized to the fantastic speed.
  131.  
  132. Favourite errors
  133. ===============
  134. Here I give you some of examples how  to  find  not so visible bugs (esp if you
  135. haven't seen anything similar before)
  136.  
  137. divs.w dy,dx
  138. ~~~~~~~~~~~~
  139. this instruction divides 32/16 numbers and saves a 16 bit result, right? One of
  140. my errors was dividing in 8.8  arithmetic: some number*256/another number. This
  141. works nicely if you're using  "normal"  numbers.  But  what about 199*256/1 for
  142. example? Result = $c700? NO :) It's a  word? Yes. So what's wrong? I forgot I'm
  143. dividing SIGNED numbers => result can be max $7fff ! It's very hard to discover
  144. since CPU continues to the next instruction without any problem (numbers aren't
  145. divided), only V flag is set.. be careful !
  146.  
  147. segments
  148. ~~~~~~~~
  149. be very careful if you're using source includes (famous include 'code.s')
  150.  
  151. file1.s:
  152.                 text
  153.                 nop
  154.  
  155.                 data
  156.                 dc.l    -1
  157.  
  158.                 include 'file2.s'
  159.  
  160. file2.s:
  161.                 lea     label,a0                ;a0 = label
  162.                 nop
  163.                 moveq   #0,d0
  164.                 lea     (label,pc,d0.w),a1      ;a0 != a1 ???
  165.                 nop
  166.  
  167.                 bss
  168. label           ds.l    1
  169.  
  170. This bug made me crazy :-) What's  wrong?  I  forgot to write 'section text' in
  171. the begin of the file2.s So, the file  is included into data segment and all PC
  172. relative modes work strange ! Devpac ignores  this  in case of data segment, it
  173. only writes an error with the bss.
  174.  
  175. memory
  176. ~~~~~~
  177. Devpac is a very strange program :-)  Its strange and not-so-system GUI doesn't
  178. care about memory limits. In better case, you type one more line to your source
  179. code and during assembling you will see TENS of errors without any reason... in
  180. the worst case scenario, you wont see  any  errors and your binary file will be
  181. corrupted (tos error #35) And my favourite:  no  errors, no tos error, but your
  182. data will be corrupted ! Double-click  on  foo.prg, code is running..... bang !
  183. strange gfx data or even worse, bombs,  system halted etc... I really love this
  184. tool :-)
  185.  
  186. OK, this is about all I can  remember...  I  know, not such cool article as you
  187. expected (???), but I promised Grey this one, so here you are :)
  188.  
  189. -------------------------------------------------------------------------------
  190.    MiKRO              XE/XL/MegaSTE/Falcon/CT60              mikro.atari.org
  191. -------------------------------------------------------------------------------
  192. </frame>
  193. </body>
  194.  
  195.