README.gl 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150
  1. README: glDOOM
  2. I never got around to do anything with respect to
  3. a Linux glDOOM port except for assembling a Linux3Dfx
  4. HOWTO (which, at that time, was a prerequisite
  5. to get permission to publicly distribute the
  6. already finished LinuxGlide port by Daryll Strauss).
  7. Linux q2test (and soon LinuxQuake2) demonstrate that
  8. Mesa with the MesaVoodoo driver is quite up to the
  9. requirements for a glDOOM port. If anybody wants to
  10. get into Linux glDOOM, please drop me a line.
  11. There is a Win32 GLDOOM port in the works, by Jim Dose.
  12. Quoting a recent posting by him:
  13. "I haven't had as much time lately to really work on
  14. the conversion. I currently have the renderer drawing
  15. the walls and floors as texture spans as the are in
  16. the software renderer. There's lighting on the walls,
  17. but not the floors, and sprites are being drawn, but
  18. not with the right texture. I figure that this is one
  19. nights work to get the game looking "normal". I haven't
  20. tested the game on less than a p200, so I'm not sure
  21. how it will perform under the average machine, but I
  22. don't expect it to be blindingly fast because of the
  23. number of spans that have to be drawn each frame.
  24. Rendering as polys is definitely the way to go.
  25. The reason I chose to do spans first was because it
  26. left the base renderer intact and I could concentrate
  27. on ironing out any Windows compatibility problems.
  28. Actually, the first version I had running was simply
  29. a blit of the 320x200 game screen through Open GL.
  30. Surprisingly, this actually was very playable, but
  31. certainly wasn't taking any advantage of 3D acceleration.
  32. Once the game was running, I started converting all
  33. the span routines over."
  34. Comment: for merging Linuxdoom with Win32, this is
  35. probably the best source for getting the Win32
  36. environment done - before more significant changes
  37. occur.
  38. "One problem with drawing spans is that the engine
  39. doesn't calculate the texture coordinates with
  40. fractional accuracy, so the bilinear filtering works
  41. vertically, but not horizontally on the walls. I may
  42. try to fix this, but since I plan to use polys for
  43. the final version, it's not really high priority.
  44. Also, spans don't really allow for looking up and
  45. down."
  46. Comment: true looking up/down vs. Heretic-style
  47. y-shearing seems to require either a strange kind
  48. of transofrmation matrix (he probably does not use
  49. the OpenGL transformation at all), or rendering
  50. all the spans as textured rectangular slices
  51. instead of using glDrawBitmap. No, polys are the
  52. way to go.
  53. "When I tackle the conversion to polys, one big problem
  54. I'll encounter is drawing floors. Since the world is
  55. stored in a 2D bsp tree, there is no information on
  56. the shape of the floors. In fact the floors can be
  57. concave and may include holes (typically, most renderers
  58. break concave polys down into a collection of convex
  59. polys or triangles). In software, the floors are actually
  60. drawn using an algorithm that's similar to a flood fill
  61. (except that a list of open spans is kept instead of a
  62. buffer of pixels). This makes drawing the floors as
  63. polys fairly difficult."
  64. A polygon based approach will require significant changes
  65. to the data structures used in the refresh module. I
  66. recommend either separating a libref_soft.so first (a
  67. Quake2 like approach), and creating libref_gl afterwards,
  68. or abandoning the software rendering entirely.
  69. John Carmack wrote once upon a time:
  70. "... the U64 DOOM engine is much more what I would consider
  71. The Right Thing now -- it turns the subsector boundaries
  72. into polygons for the floors and ceilings ahead of time,
  73. then for rendering it walks the BSP front to back, doing
  74. visibility determination of subsectors by the one dimensional
  75. occlusion buffer and clipping sprites into subsectors, then
  76. it goes backwards through the visible subsectors, drawing
  77. floors, ceilings, walls, then sorted internal sprite fragments.
  78. It's a ton simpler and a ton faster, although it does suffer
  79. some overdraw when a high subsector overlooks a low one (but
  80. that is more than made up for by the simplicity of everything
  81. else)."
  82. Well, IMO compiling a separate list of floor/ceiling polygons
  83. after having read the WAD file, and thus introducing this as
  84. a completely separate data structure to the current code base
  85. might be the easiest thing to do. Jim Dose writes:
  86. "One method I may use to draw the floors as polys was suggested
  87. by Billy Zelsnack of Rebel Boat Rocker when we were working
  88. at 3D Realms together a few years ago. Basically, Billy was
  89. designing an engine that dealt with the world in a 2D portal
  90. format similar to the one that Build used, except that it had
  91. true looking up and down (no shearing). Since floors were
  92. basically implicit and could be concave, Billy drew them as
  93. if the walls extended downwards to infinity, but fixed the
  94. texture coordinates to appear that they were on the plane of
  95. the floor. The effect was that you could look up and down and
  96. there were no gaps or overdraw. It's a fairly clever method
  97. and allows you to store the world in a simpler data format.
  98. Had perspective texture mapping been fast enough back then,
  99. both Build and Doom could have done this in software."
  100. Perhaps the above is sufficient to get you started.
  101. Other Issues:
  102. 1. Occlusion
  103. DOOM uses a per-column lookup (top/bottom index) to do HLHSR.
  104. This works fine with span based rendering (well, getting
  105. horizontal spans of floors/ceilings into the picture is a
  106. separate story). It isn't really mindboggling with polygon
  107. based rendering. GLDOOM should abandon that.
  108. 2. Precalculated Visibility
  109. DOOM has the data used by Quake's PVS - in REJECT.
  110. During Quake development, lots of replacements for the
  111. occlusion buffer were tried, and PVS turned out to be best.
  112. I suggest usind the REJECT as PVS.
  113. There have been special effects using a utility named RMB.
  114. REJECT is a lump meant for enemy AI LoS calculation - a
  115. nonstandard REJECT will not work as a PVS, and introduce
  116. rendering errors. I suggest looking for a PVS lump in the
  117. WAD, and using REJECT if none is found. That way, it might
  118. be feasible to eat the cake and keep it.
  119. 3. Mipmaps
  120. DOOM does not have mipmapping. As we have 8bit palettized
  121. textures, OpenGL mipmapping might not give the desired
  122. results. Plus, composing textures from patches at runtime
  123. would require runtime mipmapping. Precalculated mipmaps
  124. in the WAD?
  125. 4. Sprites
  126. Partly transparent textures and sprites impose another
  127. problem related to mipmapping. Without alpha channel,
  128. this could give strange results. Precalculated, valid
  129. sprite mipmaps (w/o alpha)?