home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 12 / BBS in a box XII-2.iso / Files II / Prog / M / MacWT 0.04.sit / WT Docs / FAQ-World next >
Encoding:
Text File  |  1994-05-18  |  7.2 KB  |  188 lines
  1.  
  2. The following is a document I wrote up on how the wt world is set up.  It
  3. took me a bit longer than expected to complete, so it doesn't look like I'm
  4. going to get wt 0.04 up tonight.  Sorry--I'll shoot for tomorrow night
  5. for 0.04.
  6.  
  7. --Chris Laurel
  8. claurel@mr.net
  9.  
  10. --------------------------------------------------------------------------
  11.  
  12. This is a quick description of the wt world file.  There's no guarantee that
  13. it will not be changing in the future, of course.
  14.  
  15.  
  16.  
  17. The world file itself may not make much sense without a discussion of the
  18. internal world structures.
  19.  
  20. The first thing to understand is that the world in wt is not truly three
  21. dimensional.  It is cannot render general polygons.  It can handle only
  22. horizontal floors or vertical walls.  This limitation is key to wt's speed.
  23.  
  24. The world structure in world.h looks like this:
  25.  
  26. typedef struct {
  27.      Table *vertices;
  28.      Table *walls;
  29.      Table *regions;
  30.      Table *textures;
  31. } World;
  32.  
  33.  
  34. Definitions:
  35.     Vertices are points on a plane.
  36.     Walls connect two vertices and separate two regions.
  37.     Regions are not necessarily connected areas that
  38.         are surrounded by walls.
  39.  
  40. Here is the vertex structure from world.h:
  41.  
  42. typedef struct {
  43.      fixed x, y;
  44.      fixed tx, ty, proj;      /* transformed coordinates */
  45. } Vertex;
  46.  
  47. The important fields for this discussion are the x and y coordinates.  The
  48. other fields are not stored in the world field, but are generated each time
  49. a frame is rendered.  I'll cover that sometime when I describe how the
  50. renderer works.
  51.  
  52. Ok . . . the vertex structure is pretty basic.  Like the definition says, it's
  53. just a point in two-space.  The wall structure is more interesting:
  54.  
  55. typedef struct {
  56.      Vertex *vertex1, *vertex2;
  57.      Texture *surface_texture;
  58.      Region *front, *back;
  59.      fixed xphase, yphase;
  60.      fixed xscale, yscale;
  61.      Boolean opaque;
  62. } Wall;
  63.  
  64. vertex1 and vertex2 are the two wall endpoints.  surface_texture is the
  65. texture which is mapped on the wall.  xphase, yphase, xscale, and yscale
  66. control how the texture is drawn on the wall.  xphase and yphase are numbers
  67. between 0 and 1.  The determine where the origin of the texture is with
  68. respect to the origin of the wall.  The wall origin lies in the plane of the
  69. wall at vertex1 and height zero.  If the x and y phase are zero, then the
  70. texture origin coincides with the wall origin.  If the x and y phase are
  71. both 0.5, then the wall origin coincides with the center of the texture.
  72. The xphase and yphase fields are critical for getting wall sections to
  73. join seamlessly (you'll notice that this is not done in my current sample
  74. world files.  Adjusting the texture phases will be a function of a
  75. world editor program.)
  76.  
  77. While the scale fields of the wall structure do indeed control how the
  78. texture map is sized, the would be more appropriately called 'frequencies'
  79. (The incorrect name persists because I've been too lazy to change it.)
  80. X and y scale factors of 0.1 would make a single tile of texture cover
  81. one hundred times as much wall area (not one-hundreth as much.)
  82.  
  83. The opaque field is something that will be used in future versions of wt.
  84.  
  85. One thing that may puzzle you is the fact that there are no heights listed
  86. in the wall structure.  That's because the height of the wall is determined
  87. by the regions in front and in back of it.
  88.  
  89.  
  90. Here's the region structure:
  91.  
  92. typedef struct {
  93.      fixed floor, ceiling;
  94.      Texture *floor_tex, *ceiling_tex;
  95. } Region;
  96.  
  97. floor is the floor height and ceiling is the ceiling height.  I know this
  98. is obvious but I'll say it anyway:  floor_tex is the texture map which will
  99. appear on the floor of the region and ceiling_tex is the one which will appear
  100. on the ceiling.
  101.  
  102. Here's a simple diagram which should help you understand how region heights
  103. interact with walls.  The diagram depicts a edge-on view of a couple walls.
  104. This exact arrangement of walls occurs with the windows of the castle.
  105.  
  106.  
  107.                      wall 1         wall 2
  108.                        |              |
  109.           ==ceiling====|              |==ceiling===
  110.                        |===ceiling====|
  111.           wall 1         wall 1 back      wall 2
  112.           front             and           front
  113.                          wall 2 back
  114.                        |====floor=====|
  115.                        |              |
  116.           ====floor====|              |====floor====
  117.  
  118. (Sorry--no spiffy PostScript figures . . .)
  119.  
  120. I hope that it's clear from this diagram how everything works, because I
  121. can't think of an explanation to accompany it.
  122.  
  123. Here's an important rule to keep in mind when thinking about walls.  If
  124. you are standing within a closed loop of walls, then:
  125.  
  126.    - You are in front of the the walls if they are oriented clockwise
  127.    - You are in back of the walls if the are oriented counterclockwise
  128.  
  129. I mentioned before that regions need not be connected.  This may seem strange
  130. at first, but it's a very useful property for regions to have.  I'll again
  131. bring up the case of the castle windows:  all four of them are the same
  132. region.  The neat thing about this is that I can modify the height of the
  133. bottom of all windows by changing just one number:  the floor height of
  134. the windows' region.
  135.  
  136.  
  137. Now that you've been briefed on the internal world structure, the world
  138. file should be pretty easy to figure out.  It maps almost directly to
  139. the internal structure.
  140.  
  141. The world file consists of four parts: a texture block, a vertex block,
  142. a region block, and a walls block.  The four blocks must appear in this
  143. order.  Each block consists of an arbitrary number of entries.  The
  144. entries in all blocks each consist of the block name followed by a list
  145. of parameters.
  146.  
  147. Here are the formats for each type of world file entry:
  148.  
  149. texture <texture name> <texture file>
  150. vertex <x> <y>
  151. region <floor height> <ceiling height> <floor texture name> <ceiling texture>
  152. wall <start vertex #> <end vertex #> <texture name>
  153.      <front region #> <back region #>
  154.      <xscale> <yscale> <xphase> <yphase>
  155.  
  156.  
  157. There are a number of restrictions which must be observed in world files.
  158.  
  159. - Textures which are to be used as floors must be either 64x64 or 128x128.
  160.   (I'll eventually add support for 256x256 textures--it's trivial to do.)
  161. - Textures which are to be used as walls must have be 64 or 128 pixels
  162.   vertically and a power of two pixels horizontally.
  163. - Walls may not intersect.
  164. - Walls should not be more than 255 units long.  This is necessary in order
  165.   to avoid fixed point overflows.
  166. - Walls should not be shorter than 1/256 units.  This limitation is due
  167.   to fixed point roundoff errors.
  168. - Regions should not have heights less than -128 or greater than 127
  169.  
  170.  
  171. This description should make it clear that we'll need a more sophisticated
  172. world designer than a text editor.
  173.  
  174. The format of wt's worldfile is independent of the rendering engine.  Once
  175. the world data has be slurped into a world structure, it doesn't matter to
  176. the renderer how it got there.  This leaves open the possibility for
  177. alternate world file formats, like Russ Nelson's (nelson@crynwr.com) 
  178. orld in Tcl changes.  This patch lets wt use a Tcl program as a world
  179. file (and more . . .) and will eventually be integrated into the wt
  180. distribution.  There will be a lot more news on Tcl and wt in the near
  181. future.  (People who don't have Tcl:  don't worry--I'll continue to support
  182. the graphics engine with the old world file format as well.  It will be
  183. a compile time option.)
  184.  
  185.  
  186.  
  187.  
  188.