* linked portals may never have a z-offset so the parameter for that needs to be ignored.
* for interactive portals, handling z-displacements when some distance calculation reaches through a portal is way too extensive and problematic to ever have a chance of really working. If such a portal gets defined it will be changed to a teleport-only portal and a message printed.
- store portal data in a separate structure.
- store portal data in savegames because some of this will be changeable later.
- run a cleanup pass after all portals have been created to weed out broken ones.
- add a definition type that's compatible with Eternity Engine's line portal types.
- swapped arg[2] and arg[3] of Line_SetPortal, because the type is more significant than the alignment.
- This might have been added in an effort to fix problems caused by mixing inclusive
and exclusive right edges. It might not be needed anymore. Let's find out...
- 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.
This is to keep some people from jumping the gun on this and preventing the implementation of a proper toggling mechanism.
The feature itself will come back, but differently.
- removed portal setup from Build maps
they don't define it anyway so it makes no sense to have it there. Once this code gets refactored this will be in a different place that's identical for all map types.
- With multiple A_Jump calls possible in a single action now, it is now
possible for DoJump() to be called with a callingstate that does not
match self->state because the state had been changed by a prior A_Jump
in the same action function.
- replace all implicit conversions from FString to const char * in the header files (so that it can be test compiled with the implicit type conversion turned off without throwing thousands of identical errors.)
The function 'PClassActor::InitializeNativeDefault' is the only one which didn't allocate the 'Defaults' member variable with M_Malloc. Reported by the Address Sanitizer.
Latency placement is no longer fixed:
* If time is visible, it is placed on top of the screen and latency is placed below
* If time is not visible, latency is placed on top of the screen
Both are displayed on alternative HUD only
- Somebody might want to set a midtexture's Y scale negative to flip it
vertically. I'm pretty sure this would mess up 3D mid textures if we
don't make it positive again for those.
The reason for this is that on my system, the static or delay loaded method always picks the (obsolete) system-installed OpenAL version (needed for some old games) which is not wanted here if there's another one in the local ZDoom directory.
This also removes the dependency on the broken import library that comes with OpenAL Soft which causes compile errors with more modern MSVC compilers on default settings.
These objects are supposed to be bright, but the standard translations for player do not take this into account, creating dark and/or invisible projectiles depending on the color being used.
The new translation uses hue and saturation from the player color, but combines brightness from the original color with the one for the player in an 8:2 ratio, so that no matter for the player color, these always remain bright and visible.
- 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?
Independently from OS version the game will enter fullscreen mode when zoom button is clicked
Window zooming behavior introduced in Yosemite is available on all supported versions of OS X
- 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.
- The flags use TELF_ since DECORATE has an A_Teleport with its
own set of TF_ flags.
- TELF_KEEPVELOCITY is used instead of TELF_HALTVELOCITY, because
there was only one call that ever set bHaltVelocity to false.
According to Blzut3:
The issue happens when the fullscreen resolution is the same as the desktop resolution. In this case WM_DISPLAYCHANGE doesn't occur so the editor never appears. This appears to be fixable by also catching WM_STYLECHANGED since at the very least the window caption will appear/disappear.
- having a value of 5000 as the default for autoaim makes no sense, since this is an angle value that will always be clamped to [0..35]. So now 35 is both the default and the maximum.
- Renamed the 'noabsolute' parameter in side_t::GetLightLevel to 'is3dlight', what it actually is, to avoid the confusion that caused the abovementioned error.
- fixed: The Down2Up render path for sides of 3D floors had the 'is3dlight' check inverted.
