At least on my system floor() and log10() return double, so the other
arguments to Clamp() and ClampDn() didn't match anymore, now being float
instead of double.
I replaced the calls to log10f() and floorf() to avoid any ambiguities.
Quoting Clang:
"reference cannot be bound to dereferenced null pointer in well-defined
C++ code; comparison may be assumed to always evaluate to false"
Conflicts:
Sources/CMakeLists.txt
Also changed all "if (this==NULL) return;"s.
Fixes some -Wtautological-undefined-compare warnings.
Quoting Clang:
"'this' pointer cannot be null in well-defined C++ code; comparison may
be assumed to always evaluate to false"
Thanks @SLAwww
(The first parameter to _assert is actually the message, not the
expression to evaluate, so "false &&" doesn't belong in there.)
Conflicts:
Sources/EntitiesMP/Summoner.es
except for EntitiesMP/Fish.es which I'm not sure about, and in
Computer.cpp the weird "if (_iActiveMessage < _acmMessages.Count()==0)"
construct whichs intention I didn't fully grasp, either.
many unused functions and variables are now commented out
You'll still get tons of warnings, which should mostly fall in one of
the following categories:
1. Unnecessary variables or values generated from .es scripts
2. Pointers assigned to from functions with side-effects: DO NOT REMOVE!
Like CEntity *penNew = CreateEntity_t(...); - even if penNew isn't
used, CreateEntity() must be called there!
Fixed -Wreorder warnings (hopefully the last?), also several potentially
uninitialized variables.
In SetupPixelFormat_OGL() Assert if gap_iDepthBits ends up being 0.
Small adjustments to cmake warning settings for gcc/clang
the builtins are only used when using GCC or clang, of course, otherwise
the usual shifting is done.
Them being inline functions instead of macros increases type safety
and gets rid of problems with signed shifts.
Changed two places in the code that swapped bytes in 32bit ints to use
BYTESWAP32_unsigned() instead - in case of PrepareTexture() this has
probably even fixed issues with signed shifts
- clobber the whole x87 state for mmx (emms alone requires this)
- add all modified registers to clobber list
(in some cases use dummy output vars instead)
- use symbolic names
- use more relaxed constraints where possible
- allow gcc to allocate ebx replacement reg
OSX build was a bit broken, it needs to be linked against zlib.
Furthermore it now uses the systems libSDL2 framework, unless you use
-DUSE_SYSTEM_SDL2=FALSE
i386 ASM is now disabled by default, we have plain C fallbacks for
everything that seems to work well enough (and if not they need more
testing which is likely to happen this way)
The tags are often initially assigned from pointers and then copied
around, even from one tag type to the other.
As BSPTree::MoveSubTreeToArray() uses them to get the original pointer,
we need the pointers anyway, so just CRC-ing the pointers doesn't seem
like a good option. As the tags are assigned from other tag-types
sometimes, I probably would have needed to add Pointers for the same
values in addition to the ULONG tags, that are also copied around along
the tags, to keep the tags ULONG - that seemed like a worse alternative.
However, when writing (via BSPTree::Write_t()) the bn_ulPlaneTag tag
needs to be ULONG, so there I actually use CRC for 64bit pointers (via
IntPtrToID()) - when restoring (in Read_t()), the pointers aren't valid
anymore anyway, so that all should somehow be fine.
I assume that Write_t() is only used by the Editor, anyway, so I fear I
won't be able to test that part of the code on Linux anytime soon.
Sometimes pointers are casted to ULONG just to get an ID or tag - this
is fine for 32bit pointers, but 64bit pointers will truncate which might
result in not being so unique after all.
CRC-ing the pointer should yield a more likely to be unique 32bit value.
NULL is a special case that yields 0 instead of the CRC, so code that
handles IDs/Tags with value 0 differently will continue to work.
For 32bit builds, it just returns the pointer as ULONG.
