- 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!
about this now. I spent three days trying to figure out why the VC++ debug version was so slow.
It turns out I had a conditional breakpoint set in a high-traffic area. D'oh!
The rest of this stuff should get merged into trunk:
- Fixed: Writing to debugfile uses the standard fprintf, which does not understand %td on VC++.
- Fixed: Instead of crashing when a sprite has been scaled to 0, just don't draw it.
SVN r3896 (scripting)
