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.
Due to dependencies on initializing some data in app_init it was not possible to cleanly set up the fonts.
This adds a game-side function for loading the entire palettes before starting with the texture data and another one for loading game-side texture data.
This now allows fully setting up the palettes before starting with the textures and to fully set up the textures before reading the .def files.
All this is needed because to properly initialize, the fonts need to be able to access the fully initialized texture state, including replacements and hires substitutions from the .def files.
This was causing issues with the master switch sprites in Duke that have to be kept for sound purposes.
Unfortunately, both hitscan and neartag are far too dumb to analyze sprites they may hit in any way and needed some help skipping such sprites.
* 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.
The main problem here is that there's two data arrays representing an actor - sprite and hittype and the engine only uses indices for reference.
By setting up hittype to contain a sprite reference, the function and iterator interface can be rewritten to use a single pointer instead to represent an actor.
The main objective is to reduce the number of accesses to the global arrays which constitute the biggest refactoring blocker.
The sprite lists may still need optimization. Due to different handling between Blood and the core engine they need to be written out completely which is quite wasteful.
* Blood had this right. It makes sense that the horizon be based around as it's easier to work with.
* Removed all associated game math to deduct default horizon of 100 when doing weapon zvel etc, meaning actual horizon can just be used.
* Re-did return to center function to work on the already converted pitch. Return speed should be 1:1 with previous code.
This is needed to extend a few fields that are too narrow - e.g. the texture offset fields have no room for interpolating scrolling textures.
Blood not done yet, will also need to be changed to get rid of the limits.
