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.
turns out that using UINTPTR_MAX is a pain on several systems like
FreeBSD or even older Linux/glibc systems, so maybe let's not do that
anymore.
Now I check for known CPU-architectures instead.
I also added some sanity checks to make sure the detection was
correct.
