This isn't necessary. When rendering no actors from other groups may ever come into view directly - only when the respective part of the level is rendered through a portal. But at that point the camera is in a position where it's already correctly placed with relation to that actor.
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
This is the last bit of play code that needed to be altered, what's left is the underlying data representations of vertices, linedefs and sectors.
# Conflicts:
# src/p_setup.cpp
# src/r_things.cpp
- replaced some uses of FRACUNIT with OPAQUE when it was about translucency.
- simplified some overly complicated translucency multiplications in the SBARINFO code.
- Converted P_MovePlayer and all associated variables to floating point because this wasn't working well with a mixture between float and fixed.
Like the angle commit this has just been patched up to compile, the bulk of work is yet to be done.
Patched up everything so that it compiles without errors again. This only addresses code related to some compile error. A large portion of the angle code still uses angle_t and converts back and forth.
The function to do the work scanned the full list of drawsegs to find portals, which with a large amount of masked geometry and/or drawsegs could become extremely slow.
Changed it so that R_DrawMasked collects all portal related drawsegs up front so that the actual clipping code can
a) scan a far shorter list and
b) can skip half of the validation.
Also using P_PointOnLinePrecise to shave off a small bit of additional time.
This was to resolve some circular dependencies with the portal code.
The most notable changees:
* FTextureID was moved from textures.h to doomtype.h because it is frequently needed in files that don't want to do anything with actual textures.
* split off the parts from p_maputl into a separate header.
* consolidated all blockmap related data into p_blockmap.h
* split off the polyobject parts into po_man.h
Converting a floating point value that is out of range for a signed integer will result in 0x80000000 with SSE math, which is used exclusively for this purpose on modern Visual C++ compilers, so this cannot be used anywhere.
On ARM there's problems with float to unsigned int conversions.
xs_Float does not depend on these
- did some cleanup on the portal interface on linedefs: All checks should go through isLinePortal (gameplay related) and isVisualPortal (renderer related) which then can decide on the actual data what to return.
- removed portal_passive because it won't survive the upcoming refactoring.
- removed all direct access to portal members of line_t.
- always use the precise (and fast) version of P_PointOnLineSide inside the renderer.
- Since voxels can have their origin behind the viewer and still have a
portion visible in front of the viewer, they aren't clipped to MINZ like
face sprites are. The 3D floor handling in R_DrawSprite() neglected to
clamp it when recalculating the diminished light colormap.
- Aside, but R_DrawSprite() probably shouldn't be messing with these
properties at all. Why isn't this done in R_ProjectSprite() before it
ever gets to the drawing part?
- The original Doom renderer was inclusive for all right edges. This was
fine for the wonky projection it did. This was not fine for a standard
perspective divide, so I had to change walls to be right-edge exclusive
when I changed the projection. I only touched what was needed. Until
now. The right edge is always exclusive now, which should prevent any
more bugs related to mixing the two clusivities incorrectly.
