home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 10: Diskmags / nf_archive_10.iso / MAGS / ST_USER / 1990 / USERDC90.MSA / TEXT_STOS.TXT < prev   
Text File  |  1990-10-08  |  9KB  |  182 lines
  1.  
  2.                                STOS IN 3D
  3.  
  4.                  Phil Lawson boldy takes the STOS series
  5.                 where no freelance writer has gone before,
  6.                         into the third dimension.
  7.  
  8.  
  9. If you haven't played Dungeon Master, or its equally impressive successor Chaos
  10. Strikes Back, you haven't lived. What really makes these two games stand out
  11. from the rest is the fantastic 3D graphics and the speed at which they're
  12. drawn. However, would you believe that STOS can also be used to produce 3D maze
  13. type games and draw a larger screen faster, all without the aid of the long
  14. awaited for 3D graphics extension? If not, you'd better read on.
  15.  
  16. Drawing in three dimensions is all about working out what the world around you
  17. looks like, translating this into graphics and drawing them on the screen.
  18. Taking a look at Figure I will show all the graphics used in writing this
  19. month's program.
  20.  
  21. MAZEPIC.PI1: <<SCREENSHOT>> 
  22.  
  23. Before starting any programming, you'll need to define the maze. The data for
  24. this starts at line 700 in my program, and is read into the array maze(x,y),
  25. where 0 indicate a walkway and 1 a wall. We can now test any part of the maze
  26. just by using the correct X and Y values in the array.
  27.  
  28. Notice that around the actual maze is a series of walls three deep, since my
  29. game shows everything for three places in front of the current position.
  30. Imagine if the player was currently at the outside edge of the maze, facing the
  31. wall. It is much easier to have a dummy series of walls defined and just draw
  32. them, rather than continually having to check where the player is and how much
  33. to draw.
  34.  
  35. Using two variables, XP and YP, we can keep track of where the player is when
  36. working out what the surrounding area looks like. However, knowing the players'
  37. current location isn't enough. We must also know which direction he's facing.
  38. Take a look at the example maze below:
  39.  
  40.                         direction 1
  41.  
  42.                        1 0 1 1 1 0 1
  43.                        1 0 0 1 0 0 1
  44.           direction 4  1 1 0 0 0 1 1  direction 2
  45.                        1 0 0 X 1 0 1
  46.                        1 0 1 1 0 0 1
  47.                        1 0 0 0 0 1 1
  48.  
  49.                         direction 3
  50.  
  51. If the player at position X was facing direction 1, would see:
  52.                          P P W P P
  53.                          W P P P W
  54.                            P   W
  55. But facing direction 4 would change the view to:
  56.                          P P P W P
  57.                          P W P P W
  58.                            W   P
  59.  
  60. Where P is a path and W is a wall.
  61.  
  62. Therefore a variable, DI, is needed to store the current direction, which will
  63. be updated whenever the player turns around. We'll also need some way of
  64. reading the correct information from the MAZE array depending upon the value of
  65. DI. This is best achieved with two other arrays, one each for the X and Y
  66. coordinates, TX(DI,ROW,POS) and TY(DI,ROW,POS).
  67.  
  68. The data for these arrays, covering each of the four directions, can be found
  69. starting at line 860 in my program. Some explanation of how these values were
  70. obtained, together with how to use them, is essential. It's also quite a tricky
  71. subject to describe, so you may need to read the following sections more than
  72. once. (If you have a printer, use the PRINT option, otherwise try taking notes.
  73. You'll find them invaluable when you start playing around with the program).
  74.  
  75. To draw the screen you need to read five positions from the back row, five from
  76. the middle and three from the one the player is currently standing on, as shown
  77. in the figures above. The coordinates of these are found by adding offset
  78. values to both the X and Y coordinates. It is these offsets that are stored in
  79. the TX and TY arrays.
  80.  
  81.             1         2        3         4         5
  82.  
  83.     A    X-2,Y-2   X-1,Y-2   X,Y-2    X+1,Y-2   X+2,Y-2
  84.     B    X-2,Y-1   X-1,Y-1   X,Y-1    X+1,Y-1   X+2,Y-1
  85.     C     X-2,Y     X-1,Y     X,Y      X+1,Y     X+2,Y
  86.     D    X-2,Y+1   X-1,Y+1   X,Y+1    X+1,Y+1   X+2,Y+1
  87.     E    X-2,Y+2   X-1,Y+2   X,Y+2    X+1,Y+2   X+2,Y+2
  88.  
  89. Table I: The offset values.
  90.  
  91. For example, the offset values for direction 1 would be all of rows A and B,
  92. and the three middle bits of row C. The values for direction 4 however, would
  93. be all of columns 1 and 2, with the middle bits of column 3. Try matching the
  94. offsets given in Table I with the data in the program.
  95.  
  96. When actually drawing the screen it's best to start at the back and work
  97. forwards. This way there are no messy calculations trying to work out whether
  98. something is going to be hidden by a wall.
  99.  
  100. If all that seemed a little complicated, the following description of how the
  101. program works should help clear things up a bit. Don't be surprised if you have
  102. to read this article more than once to fully understand the techniques I've
  103. used, it gave me enough brain-ache working it out my self.
  104.  
  105. Since my game only has a perspective three places deep, it is necessary to draw
  106. a very dark strip to make up the background. Otherwise, in certain parts of the
  107. maze, it would appear that walls just ended in nothingness. Also, when you move
  108. forward, new walls would seem to appear from nowhere.
  109.  
  110. Once this has been drawn, we can start drawing the walls. Note, there is no
  111. need to draw pathways, since these are just empty spaces with nothing in them.
  112.  
  113. Because we want the new image to appear almost immediately, without appearing
  114. to draw the various sections individually, I have defined a blank screen (7),
  115. to which I copy the graphics to. When the image is complete, it is a simple
  116. matter to draw a frame around it all and copy the whole thing to the physical
  117. screen.
  118.  
  119. If you want to examine the program while it's running and see exactly what is
  120. going on, try making the following changes:
  121.  
  122. 245 GOSUB 10000
  123. 255 GOSUB 10000
  124. 305 GOSUB 10000
  125. 315 GOSUB 10000
  126. 330 GOSUB 10000 : RETURN
  127. 365 GOSUB 10000
  128. 375 GOSUB 10000
  129. 420 GOSUB 10000 : xx=xx+160 : NEXT c
  130. 465 GOSUB 10000
  131. 495 GOSUB 10000
  132. 505 GOSUB 10000
  133. 535 GOSUB 10000
  134. 10000 SCREEN COPY 7 TO PHYSIC : WAIT VBL : SCREEN COPY 7 TO BACK : WAIT VBL
  135. 10010 WAIT KEY
  136. 10020 RETURN
  137.  
  138.  
  139. After drawing the dark strip, the back row is put in place. Take a look at line
  140. 290:
  141.  
  142. 290 IF maze(xp+tx(di,3,c),yp+ty(di,3,c))=0 THEN 330
  143.  
  144. This uses the players coordinates, (XP and YP), and the two offset arrays. The
  145. variable 'di' is the direction in which the player is facing, the number 3
  146. means the third or back row, and 'c' is a number from 1 to 5. By combining this
  147. lot with the 'maze' array, we'll obtain a value of either zero or one.
  148.  
  149. If the value is zero, the position being tested is a walkway, and therefore we
  150. don't need to draw anything. On the other hand, if it's one we've found a wall.
  151. Lines 300 to 320 will copy the correct graphics from screen 5 to screen 7. The
  152. front face of a wall is done by 300 and the side pieces, used to give a feeling
  153. of depth, are drawn with 310 and 320.
  154.  
  155. Once this routine has been done five times, once for each value of 'c', the
  156. back row will be completed with the walls and pathways in the correct places.
  157.  
  158. We now do this all again for the second row with lines 340 to 460, except the
  159. value of 'c' will be two instead of three. Lines 360 and 370 are used to draw
  160. the edge pieces you'll see whenever your looking around a corner. To see
  161. exaclty what I mean, try running the program as it is and then running it with
  162. these two lines REMmed out.
  163.  
  164. Notice lines 430 to 460, which check the position directly in front of the
  165. player and draw a block if neccessary.
  166.  
  167. The last two lines concerned with the graphics are 490 and 500. These put in
  168. the side pieces immediately left and right of the player. All that is left to
  169. do now is draw the border, by copying it from screen 6. Displaying the new
  170. screen is a simple matter of copying the data from screen 7 to the physical and
  171. background screens.
  172.  
  173. The remaining part of the program, lines 580 to 690, is concerned with reading
  174. the keyboard. To actually move around use the four arrow keys, with the Insert
  175. and Clr/Home keys being used to rotate the player on the spot.
  176.  
  177. Don't worry if the graphics seem a little rough, or even out of perspective in
  178. places. The last thing I am is an artist, so it's up to you to take the
  179. techniques and ideas discussed this month and produce your own mega 3D game.
  180. I'm sure our friendly editor, (crawl crawl), will only be too happy to put the
  181. best on the cover disc for the rest of the world to marvel at.
  182.