* 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.
* the bunch drawer can at most process an angular range of 180°. If this gets exceeded it can run into wraparound issues that may cause holes in the geometry.
* there was no clipping to the current field of view so it always checked the full 360°.
* moving polymost_voxdraw into polymost.cpp.
* consolidated all remaining voxel code in hw_voxels.cpp. All original Build voxel code is completely gone now, except for polymost_voxdraw, so this got moved out of the build/ folder.
* integrate Blood's voxel init code into the main function.
* some further cleanup was allowed as a result of this, so engineInit is gone now because these parts can now be done outside the games' app_init functions.
Since these do not fully get processed sequentially the contents need to be preserved until needed.
This required getting rid of the global tsprite array. Polymost still uses a static vatiable, though, but this is only accessed in polymost-exclusive code.
* Blood's automap was not drawn at all.
* SW's automap always showed all sectors
* SW's player sprite was not rendered.
* Non-automap: Forward gotsector to the game code because there's still a few places in Blood that need it.
This was by far the messiest game, there's two reasons for this.
First, the portal links do not need to be in an actual portal sector, so they cannot be used to detect portal sectors.
Second, the game moves portals in place, so all offsets are (0,0,0) so that not even these can be used for detection.
The only working method is the super-complicated original way to look up portals at run time, just being done at map start.
Having static portal links should reduce the render glitches quite significantly because the renderer knows now which sectors belong to a portal and can use this information to ensure proper processing.
Unlike the other games these are so poorly defined that the engine has to rely on the original fudging to pick the proper portal to link to. As a result they are just as limited as they always were.
In addition all the portal search code had to be reinstated.
