All this is needed to make the back door to the cinema in Duke E1L1 render properly without making the clipper break on complex overlapping sector setups, like some of the ducts in Duke E2L7.
The handling for this was from the first draft of the clipper that made very different assumptions than the final version.
This cannot simply delete the old range - it has to explicitly alter it and recursively insert the outer sub-ranges separately.
* must do proper checks for merged ranges when inserting new ones. The checking code assumes that closed ranges are contiguous.
* when discarding parts of overlapping ranges this may not use merged clip values for its checks.
* ranges that have their clip values altered must be released and reinserted to ensure everything is correct.
Content was reordered so that the file can contain the inlines belonging to the map data types that previously had to be stored elsewhere.
Also moved out of the Build folder because virtually everything in here can be traced to content available in Duke Nukem 3D's and Shadow Warrior's source releases.
This is now a separate type from spritetype which contains an actor pointer instead so that sprite display can be handled without requiring a static sprite array.
The case being checked here may decide not to add the wall to the clipper but it must still be rendered.
Information for determining visibility is not sufficient in case of sector overlaps which can happen with rotating doors or poorly set up sector objects.
# Conflicts:
# source/core/rendering/scene/hw_bunchdrawer.cpp
This is a lot easier to manage than having them in the code.
For now it piggybacks on the map hack feature, later this should use the same scripted approach as GZDoom.
This is by no means a permanent solution but having it buys some time to find something more universal that won't affect performance too badly and investigate the need for a more robust solution.
The idea here is to define pairs of walls where when the first element of the pair is seen, it will treat the second one as view blocking.
This is used as the two offending windows (sectors 151 and 152) to cope with the lack of a height sensitive clipper.
* let the clipper work on relative angles to simplify the math.
* properly initialize the initial visible range and preserve it for multiple invocations.
* track the maximum visible angular range per sector. While possibly not sufficient to handle every edge case imaginable it has low overhead and is still useful to eliminate obvious cases that do not need more complex checks. It is enough to fix the blue door in Duke E3L4.
* removed unused elements of the clipper.
