home *** CD-ROM | disk | FTP | other *** search
/ Doom Extras / DExtras.iso / accessor / dos / deu521 / source / comments next >
Encoding:
Text File  |  1994-05-20  |  4.3 KB  |  94 lines
  1. COMMENTS
  2. ========
  3.  
  4. This file has two purposes: the first part contains a TO-DO list
  5. for all features that should be added to DEU, or things that need
  6. to be fixed, or general ideas, etc.  The second part contains
  7. some informations about the functions that are included in the
  8. source code.  Some functions have to be explained because they have
  9. some obscure features.  But if the comments take more than ten lines,
  10. it's better to put them here instead of adding them to the source
  11. files.
  12.  
  13.  
  14. TO-DO LIST, WHISH LIST, ...
  15. ===========================
  16.  
  17. The TO-DO list is not the same thing as the 'Future Plans' section in
  18. README.1ST.  The 'Future Plans' section describes some new features
  19. that will be added to DEU sooner or later, and everyone should be
  20. able to understand what each feature means.  Here, this is more
  21. technical stuff: functions that could be improved or added, better
  22. algorithms for some parts of the code, etc.  Feel free to send your
  23. suggestions to Brendon and Raphael.  They will be added to this list.
  24. And, who knows, they may be implemented one day or another...
  25.  
  26. * Reject builder.  This shouldn't be too hard to do, since Id
  27.   released their BSP code.  But I didn't have the time to take a look
  28.   at it and see how their Reject builder works.  [Raphael]
  29.  
  30. * Better BlockMap builder.  Matt Tagliaferri (author of DoomCAD) and
  31.   Matt Fell (author of the Doom Specs) have found an algorithm that
  32.   is faster (and maybe better) than mine.  [Raphael]
  33.  
  34. * Write the average path length for the BSP tree in the log file, if
  35.   in debug mode.  This will give useful info for people who want to
  36.   play with 'SplitFactor'.  This should be computed in SaveNodes.
  37.   (formula: sum of (depth * number of Segs in SSector) / total
  38.   number of Segs).  [Raphael]
  39.  
  40. * Use some of the typedef's from Brendon's code in 5.x, so that the
  41.   various versions of DEU 5.x (Borland, GCC, ...) will be more
  42.   similar to DEU 6.0.  [Raphael]
  43.  
  44. * Better TO-DO list in the COMMENTS file.  :-)
  45.  
  46.  
  47. COMMENTS ABOUT SOME FUNCTIONS
  48. =============================
  49.  
  50. If you wrote a function that is hard to understand, it's better to
  51. add your comments here.  A code without comments is hard to
  52. understand, but a code with too many comments is hard to read.  So
  53. put one or two lines of comments in the source files, and put the
  54. rest here.
  55.  
  56. ---------------------------------------------------------------------
  57. * Comments on the Nodes builder by Raphael Quinet:
  58.  
  59. Most of the algorithm is explained in NODES.C, and I won't put the
  60. text here because it was in that file since the first version.  But
  61. one thing is not explained in the file: how I choose the "best
  62. nodeline".
  63.  
  64. The BSP tree is used to tell in what order the planes should be
  65. displayed on the screen, and the program will be faster if the
  66. average path in the tree is smaller.  This average path depends on
  67. two things: the total number of Segs and the way the tree is
  68. balanced.  If we minimize the number of splits, there will be less
  69. Segs, but the tree may not be well balanced (some path will be much
  70. longer than some others).  If we try to keep the tree as balanced as
  71. possible (by having the same number of Segs on each side of the
  72. nodeline), we may have to do more splits.
  73.  
  74. The algorithm in the Nodes builder is a compromise.  In order to pick
  75. the best nodeline, I used brute force: try with all possible
  76. nodelines, that means all Segs.  For each candidate, I compute the
  77. number of Segs on each side (num1 and num2) and the number of splits
  78. (splits).  Then I try to minimize the following formula:
  79. 'max(num1, num2) + SplitFactor * splits'.  The nodeline which has the
  80. lowest result for this expression will be selected.  'SplitFactor' is
  81. a weighting factor: if it has a low value (0, 1, 2,...), then the
  82. tree will be well balanced, but there may be a lot of splits.  If it
  83. has a high value (greater than 10-20), there will be less splits, but
  84. maybe a lack of balance in the tree.  I could also use
  85. 'abs(min1 - min2)' instead of 'max(num1, num2)'.  That would roughly
  86. give the same results, since 'num1 + num2 - splits' is constant.
  87.  
  88. ---------------------------------------------------------------------
  89. * Comments for function FFF by XXX:
  90. (insert your text here)
  91.  
  92. ---------------------------------------------------------------------
  93.  
  94.