doc-overview.txt 5.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119
  1. reflex2q3
  2. A tool to convert Reflex Arena maps to idTech .maps for use in map editors.
  3. Forked from chronokun's ReflexToQ3.
  4. Features, and Responsibilities of the Program: For Mappers
  5. The converter is equipped with the following features:
  6. - Converts map geometry from Reflex
  7. - Converts entities such as, but not limited to
  8. - player spawn points
  9. - item pickups
  10. - teleporters and respective targets
  11. - race checkpoints
  12. During the conversion process, face related data (texture & color) are
  13. preserved. This is both because of the differences between engines and the
  14. numerous games built in idTech engines. That is, the map converter does not
  15. attempt to retexture the map with generic idTech engine equivalents or
  16. per-game equivalents. It is the individual mappers' responsibility to
  17. appropriately adapt the map for the target game. Some of the following
  18. tasks for mappers remain:
  19. - Redesigning specific map geometry so meta/gameplay tricks work.
  20. - Sealing leaks allowed by Reflex Arena, but illegal in idTech.
  21. - Texturing the map.
  22. * Extends to applying lava and slime effects to brushes.
  23. - Providing light to the map.
  24. * The converter handles Point Lights; however some entities and
  25. textures in Reflex emit light while target game equivalents
  26. do not.
  27. Program Design: For Programmers
  28. The program can be summarized as two distinct phases:
  29. 1. Converting worldspawn (map geometry).
  30. 2. Converting entities.
  31. These are split into two distinct phases because of the difference between
  32. engines. While it is acceptable for worldspawn brushes and game entites to
  33. be in which ever order in Reflex, worldspawn in IdTech engines must not have
  34. entities with in it. Entities must be handled separately after worldspawn.
  35. Both phases will write to the output file, the format determined by a
  36. function pointer to the outputting function- the function to call being a
  37. "variable" determined in main. Both phases convert and write to file single
  38. instance of a game object (brush or entity) at a time.
  39. Converting Worldspawn
  40. This is the phase that passes through the input file, parses Reflex's
  41. .map format, and converts brushes for the idTech format.
  42. Functions pertaining to this phase are written to be easily changed to
  43. deal with either from-memory or from-file operations. For example,
  44. functions for parsing brushes for the first phase will deal with input
  45. and output file streams, but later in the next phase they are used to
  46. deal with stringstream. If for any reason, the entire contents of the
  47. input file should be stored in memory, no major rewrites are needed.
  48. The parsing functions for each game object (brush, faces, vertices)
  49. expect and operate on the contents underneath the respective keywords.
  50. As the two engines are very different, entities must be converted and
  51. written to file at a different phase. The converter will store the
  52. strings of an entity to a vector of vector of strings (STL). A vector
  53. was chosen because the entity converter needs to prescan the container
  54. for teleporters and targets. The vector permitting multiple passes FIFO
  55. and pass by reference; where instead STL queue is either destructive or
  56. requires copying the queue.
  57. Converting Entities
  58. This is the phase that operates on the container of entity strings,
  59. converts, and writes them to file. Entity names for pick up items will
  60. vary per target game; to easily adapt to multiple games, a plain text
  61. file is used, containing Reflex map entity id's corresponding to the
  62. target game entity names.
  63. In order to determine the teleporters and the corresponding target
  64. locations, the entity container is prescanned.
  65. Major Code Changes in Forking
  66. - Can be compiled for g++ and by extension mingw, and Linux systems.
  67. The original project was for Microsoft Visual Studio; however even
  68. manually compiling the source resulted in errors from syntax acceptable
  69. by Visual Studio, but rejected by g++.
  70. - Removal of ckmath, original author's custom C++ library for linear
  71. algebra
  72. This was because the attempt to compile ckmath results in several
  73. warnings and errors. Addressing the compilation errors would have
  74. warranted its own tests to see if the output is unchanged.
  75. This was scrapped for Eigen.
  76. - Addition of Reflex version 8 map parsing
  77. The original code had a reported Issue where it did not parse V8, the
  78. current format of map files for the game.
  79. - Addition of output to Net Radiant's brush definition
  80. The original code's output was the legacy brush definition used by GTK
  81. Radiant or older map editors.
  82. - Addition of converting map entities.
  83. - Addition of translating texture definitions.
  84. Previously these were kept as placeholder values.
  85. - Severe bug fixes
  86. The old converter crashed on converting Pocket Infinity, and had
  87. distorted geometry for certain maps e.g Sky Temples. The main cause
  88. for such issues have been addressed and will not occur on maps
  89. featuring similar cases.
  90. Minor Code Changes
  91. - Improved memory usage
  92. - Added new command line arguments and robust handling of.
  93. -h, --help, displays help
  94. -gtk switch to output to GTK's map format
  95. -e <FILE> entity conversion
  96. - Added test cases to verify correctness of operations pre-commit.