by Gez » Sat Feb 04, 2012 3:11 am
1. There's no source code. RORDoom's code would have to be reverse-engineered.
2. The "overlapping sectors" approach would cause many compatibility issues.
3. ZDoom already features many room-over-room systems, including portals, silent teleporters, 3D floors, solid midtextures, and bridge things.
4. Modern map editors such as DB2 already support the ZDoom methods of making ROR, but they automatically split sectors when you draw linedefs through them, making it impossible to create RORDoom-compatible RORs.
5. There is no map in existence for RORDoom.
In short, your suggestion would represent a tremendous amount of work (reverse engineering is a lot more difficult than reading source code), with a consequence of damaging the port's stability; and all that for an entirely nonexistent gain. There is zero reason to implement the RORDoom feature, and there are many reasons not to implement it.
1. There's no source code. RORDoom's code would have to be reverse-engineered.
2. The "overlapping sectors" approach would cause many compatibility issues.
3. ZDoom already features many room-over-room systems, including portals, silent teleporters, 3D floors, solid midtextures, and bridge things.
4. Modern map editors such as DB2 already support the ZDoom methods of making ROR, but they automatically split sectors when you draw linedefs through them, making it impossible to create RORDoom-compatible RORs.
5. There is no map in existence for RORDoom.
In short, your suggestion would represent a tremendous amount of work (reverse engineering is a lot more difficult than reading source code), with a consequence of damaging the port's stability; and all that for an entirely nonexistent gain. There is zero reason to implement the RORDoom feature, and there are many reasons not to implement it.