home *** CD-ROM | disk | FTP | other *** search
/ Amiga Plus Leser 16 / AmigaOS_LeserCD16_02.bin / CD_System / Warp3D / Demo / Engine / README < prev    next >
Text File  |  2001-10-30  |  6KB  |  103 lines

  1. Warp Engine V1.0 Readme
  2. -----------------------
  3.  
  4. This engine is a tiny 3D engine in the style of games like System
  5. Shock. Essentially, a level is made up of 64x64 pixel grids, with
  6. arbitrary topology cells constructed from polygons that  are  not
  7. allowed to overlap the cell boundary. This allows for easy HSE by
  8. a breadth-first traversal of the map from  the  player  position.
  9. Clipping  is  done  in camera space before the actual projection.
  10. Each cell is convex, so that each cell may  be  rendered  in  any
  11. given order (a more complex cell layout would be easy to achieve,
  12. although this would require some kind of depth sorting  like  BSP
  13. trees).
  14.  
  15. Textures are "borrowed" from  the  source  code  distribution  of
  16. Alien  Breed  3  -  Killing Ground. I have converted some of them
  17. into PNG format, which the engine can load. The "data/" directory
  18. contains  the level and font, the former being a simple text file
  19. which is also commented, just in case you are mad enough  to  try
  20. and  modify  it  a  bit,  although this is tedious work without a
  21. level editor.
  22.  
  23. Source is also included in the developer archive. I  intended  to
  24. write  a  game with this, but I now have something better in mind
  25. (more in the line of Quake), so I release this source code  as  a
  26. kind  of  tutorial  on  Warp3D programming (and perhaps also as a
  27. tutorial on 3D programming, although much of the stuff  could  be
  28. improved).  Much of this was inspired (in style and technique) by
  29. the two programs "Descent" and "QMap", the former being  a  first
  30. person  shooter  by Parallax software (and ported to the Amiga by
  31. my brother and me), the second being a Quake Level viewer by Sean
  32. Barret,   which   I  studied  while  investigating  3D  rendering
  33. techniques used by Quake.  Although  my  code  does  not  contain
  34. actual code from those, it was in places heavily inspired by them
  35. :-) If you want to use the code, go ahead, just  don't  sell  it,
  36. and  give  me  credit.  To  compile,  you will need SAS/C (StormC
  37. should also do, GNU C with minor modifications)  and  GNUMake.  I
  38. only  provide  a  GNU  makefile,  SMake is far too limited for my
  39. taste. To use the makefile you  will  also  need  a  fairly  well
  40. installed ADE/Geek Gadgets distribution, namely the fileutils and
  41. binutils.
  42.  
  43. In the demo, press the right mouse button and roll  your  rat  to
  44. move the view. The 's' and 'x' keys move forward/backwards, there
  45. are also some other keys mapped (play around a bit). No collusion
  46. detection  is  done  yet, so you can actually walk through walls.
  47. Also, the depth sorting is a bit broken, since I use a  recursive
  48. call,  and hence a stack, for traversal, which is of course utter
  49. bullshit, since it should use a queue. The  net  result  is  that
  50. there  might  be  overhanging  polygons  in certain places, but I
  51. won't fix that (try if you like). Hey, if you do a bigger  level,
  52. please  let me have it, too (although I doubt that anyone will do
  53. that!).
  54.  
  55. The FPS counter in the lower console will only update every  five
  56. or  so  seconds,  so  give it a few moments to come to live - the
  57. first FPS reading will  be  too  low,  because  the  startup  and
  58. loading  is  also  measured.  Also,  when  you  change one of the
  59. features (mapping, filtering), ignore the first  measure,  as  it
  60. will  also  be unnprecise. Moving the mouse pointer to the top of
  61. the screen reveals a menu. Click a  title  with  the  left  mouse
  62. button,  keep  it  pressed  and  release  it  over your choice to
  63. select. Finally, press ESC to quit.
  64.  
  65. Note that this is a very simple engine, yet it serves as a  small
  66. hint at what is possible with 3D hardware. The window at the cell
  67. in front of you is transparent, and the color can be  toggled  in
  68. the second menu. The red flashlight is dynamically implemented as
  69. gouraud shading, this comes almost for free on 3D  hardware  (the
  70. overhead  can  be  neglected).  On my machine, I get about 34 FPS
  71. with all features enabled, about 70 when everything  is  switched
  72. off.  This  is  on  a  Z2  machine,  an  Amiga 2000 with Blizzard
  73. 2060/50, and it shows what 3D Hardware can  do  for  a  Z2  based
  74. machine (of course, it's hard to beat such speeds on a Z3 machine
  75. too).
  76.  
  77. On the topic of speed, this demo might or might  not  run  a  bit
  78. slower  on  Picasso96.  This  is  mostly  due  to  the  fact that
  79. Picasso96 seems to sync the ScrollVPort to the Screen updates, so
  80. that  some  time  is  actually  "wasted" on waiting for the sync.
  81. While this gives a slight impact on performance,  it  also  makes
  82. the  thing look a bit cleaner. In fact, the ScrollVPort should no
  83. longer be used for Double buffering, alas, I've done it  in  this
  84. demo for a number of reasons:
  85.  
  86. -  Not  all  CyberGraphX  installations   can   really   do   V39
  87.    Multi-Buffering.
  88.  
  89. -  The Multi-Buffering code I've actually written is buggy, and I
  90.    just didn't have the time to look after it, and since it works
  91.    with the ScrollVPort, I didn't bother to look after it.
  92.    After all, we wanted to get Warp3D on the road.
  93.  
  94. I have included a screen mode requester, so that you can try  out
  95. different screen modes. I get around 34 FPS in 320x240, 13 FPS in
  96. 640x480 and around 1.9 FPS in 1024x768... If you have  a  320x400
  97. 15  bit  mode,  try  this, it's still quite usable. Note however,
  98. that the engine does not take the aspect ratio of the screen into
  99. account,  making the 320x400 mode look a bit streched. This would
  100. be easy to fix, I just didn't have the time. The whole engine was
  101. the work of about a week or so, but I knew pretty well what I was
  102. doing from the start.
  103.