- GCC is pickier than Visual C++. GCC requires that structs with constructors, etc that are
used in a union must be defined outside the union. VC++ lets you do it inline.
- When the camera texture for a player view was rendered, its psprites
would overwrite the ones stored for hardware acceleration.
* Use a temporary vissprite in R_DrawPSprite() until it's known that it
will be accelerated.
* Do not write to any of the VisPSprites*[] arrays until it's known that
the sprite will be accelerated.
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.
- Clang's optional runtime array bounds checking doesn't understand when we
intentionally "overflow" by doing this:
RGB32k[0][0][colorval]
It will warn that it was accessed at an index will past the bounds
of type 'BYTE [32]', which makes it less than useful for catching real
array bounds overflows. So now do this:
RGB32k.All[colorval]
And if you want this:
RGB32k[r][g][b]
Now do this:
RGB32k.RGB[r][g][b]
Conflicts:
src/CMakeLists.txt
src/b_think.cpp
src/g_doom/a_doomweaps.cpp
src/g_hexen/a_clericstaff.cpp
src/g_hexen/a_fighterplayer.cpp
src/namedef.h
src/p_enemy.cpp
src/p_local.h
src/p_mobj.cpp
src/p_teleport.cpp
src/sc_man_tokens.h
src/thingdef/thingdef_codeptr.cpp
src/thingdef/thingdef_function.cpp
src/thingdef/thingdef_parse.cpp
wadsrc/static/actors/actor.txt
wadsrc/static/actors/constants.txt
wadsrc/static/actors/shared/inventory.txt
- Added register reuse to VMFunctionBuilder for FxPick's code emitter.
- Note to self: Need to reimplement IsPointerEqual and CheckClass, which
were added to thingdef_function.cpp over the past year, as this file no
longer exists in this branch.
because they're kind of a pain to type when all uppercase.
- Also, make its sx1 and sx2 members shorts, so it takes less space, since
it's getting crammed into a vissprite now.
- This still doesn't use all the sprite properties correctly. It also
looks like they're going to need different code to build the clipping
arrays. But at least wall sprites are drawn at the proper angle now!
