That only leaves the Scale function which is still being used in a few places and which would create considerably worse code without assembly on 32 bit platforms. This is also far too primitive (2 or 3 assembly instructions) to claim any copyright on it, so I think m_fixed.h can now be considered free of Build-related issues. The deficated inline headers have been removed because that sole remaining function could be easily moved into m_fixed.h.
Instead of trying to fix Simplify, which seems to be a lost cause, the ring list now gets unraveled into an array which is immune from this type of problem.
- renamed all functions in r_walldraw.cpp to give them names more in line with Doom's naming conventions. Since this is not Build code anymore it also shouldn't use Build names to avoid giving a false impression.
- cleaned out a lot the SafeDivScale stuff in m_fixed.h. The only SafeDivScale variant still in use was #16 for FixedDiv, so all the SafeDivScale stuff has been removed and the 16 variant renamed to FixedDiv because that's the only form in which it is still being used. (2x in R_DrawVoxel and 1x in ACS's FixedDiv PCode.)
- removed Build notice from m_fixed.h because aside from the inlines includes there is nothing here from Build anymore.
This was used in only 4 places, 3 of which could easily be replaced with a memset, and the fourth, in the Strife status bar, suffering from a pointless performance optimization, rendering the code unreadable - the code spent here per frame is utterly insignificant so clarity should win here.
- removed the Build license note from r_bsp.cpp.
This note was for code in R_AddLine which had been both refactored into several subfunctions and completely replaced with a floating point version. What is left is just some basic common math without any traits that resemble anything in Build.
Because every bit of Build code that can be removed is a good thing.
This was only used in two places, one of which could be done better, the other one in the voxel drawer setup now uses a local C-inline version.
Some benchmarking shows that on SSE systems it only harms performance and compared to the intrinsics version the gains are too marginal for something this infrequently called.
Doing 100000 calls of DoBlending results in a 5 ms decrease of using assembly vs intrinsics on a 3.4 GHz Core i7, meaning that even on a computer that is 10x slower you can still do 1000 or so blends per frame without a speed hit.
For most attack functions this is wrong, it's only the Hexen fighter attack needing this particular value, so it has been split up into two return values now.
This can see some heavy use in iterators where saving several hundreds of function calls can be achieved. In these cases, using a function to do the job will become a significant time waster.
On modern systems it is actually slower than the C version, only on old ones it is marginally faster - but the overall execution time for this function is so low that even in the worst case scenario the minor loss of performance on older systems is still not relevant.
