They didn't do anything anyway, and can clash with other compilers since they
may be used internally (macros and keywords starting with __ are for compiler
use).
- For most cvars, this is equivalent to calling GetGenericRep() to get a
string.
- For float cvars, it uses %g instead of %H, because %H is generally more
information than is needed.
- 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.
ZDoom defaulted to Boom's (buggy) angle adjustment.
Changed it so that
* Mode 0 is like Hexen, performing no adjustment at all. This still should match all known maps using this special.
* Mode 1 remains unchanged.
* Mode 2 replicates Boom's broken angle adjustment and is used in the xlat file.
* Mode 3 implements the correct angle adjustment that Boom originally intended.
(Note: Should some map require something different it should be handled with compatibility.txt instead of reverting this back to the broken way it was before.)
- fixed: Visplane checks should only compare the plane flags that are relevant for rendering and mask out the rest.
- floatified FTransform and made the visplane checks a bit less verbose by moving the comparison as an operator into FTransform.
Note that this operator needs forceinline on Visual Studio so that it won't get called as a function.
In some places, P_UndoPlayerMorph was called with the 'force' argument placed in the 'unmorphflag' parameter, so that 'forced' unmorphs would be not completely forceful.
I hope no mod relied on this weirdness...
Note that this required splitting P_SerializeWorld, because sector_t and FSectorPortal contain some actor pointers, for which the same rule applies: Portal linking can only be done after all sectors have been read, meaning it cannot be done along with the rest of the data in these structures.
Obviously such a change breaks savegame compatibility so the min. savegame version had to be increased again.
- This reverts commit 06216d733e.
- I don't know what I was thinking. Since stateowner is always available
to the wrapper function, and this code is only generated for the wrapper
function, it's a nonissue. The state is already located before calling
any function that uses it.
