To make sure that setting the slope flags is always done properly. (Why are the flags even needed?)
As a nice side effect, this, plus use of other inlines made the align*slope functions implode into virtually nothing.
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 reverts commit c074b0995648a4057c516e5646f5fe7a11719317.
* The commit notes talk about `updatesectorneighborz()`, but the change is applied to `nextsectorneighborz()`. Further to this, `nextsectorneighborz()` is only called from some ptr wrappers in `build.h` and they both test against `-1` return values.
```
inline sectortype* nextsectorneighborzptr(int16_t sectnum, int32_t refz, int16_t topbottom, int16_t direction)
{
auto sect = nextsectorneighborz(sectnum, refz, topbottom, direction);
return sect == -1? nullptr : §or[sect];
}
inline sectortype* nextsectorneighborzptr(sectortype* sectp, int32_t refz, int16_t topbottom, int16_t direction)
{
auto sect = nextsectorneighborz(sector.IndexOf(sectp), refz, topbottom, direction);
return sect == -1? nullptr : §or[sect];
}
```
* Also fixes broken Duke elevators and possibly a whole raft of issues.
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 initial distance check in updatesectorneighbor had a far too low threshold which would skip the breadth-first search for relatively small distances already.
Exhumed's LEV1 and Duke's Lunatic Fringe were the most obvious candidates where this could cause problems.
Changed to use a mixture of the original updatesector with the revised algorithm so that all immediate neighbors of the start sector will get visited unconditionally.
updatesectorz was still the original function from Shadow Warrior, this also was changed to use the same algorithm as uodatesector.
This old variant is only useful for demo compatibility, its main difference is that it does not handle slopes, which even for Exhumed is wrong with some custom maps.
This still contained some code for EDuke32's TROR and used a shared static global array.
It now uses the BFSSearch class to manage its bit array to unlimit the size of its working set and to avoid reallocation.
This reverts commit c034c2a299.
While the function works, it is subtly different for points exactly on a line - enough to cause problems with Shadow Warrior's waypoint implementation.
This is based on external information and does not use any of the original Build code.
Despite being a lot clearer than Build's bit masking voodoo and using 64 bit math to avoid overflows it is roughly 10% faster. :)
Code was moved to gamefuncs.cpp because this no longer falls under the Build license.
The one from EDuke32 is ambiguous - it considers any point on a wall to be part of both sectors touching that wall. This wasn't used anyway with the current engine compatibility settings.
I was not able to get different values out of the 'ps' version - this seems to only be important for demo playback concerns, for regular playback the differences appear to be totally irrelevant.
Ultimately this should be replaced anyway with a license-unencumbered variant of the same basic common algorithm.
