destination for this 'memset' call is a pointer to dynamic class
'idRenderLightLocal'; vtable pointer will be overwritten
The constructor already initializes everything to zero, get rid
of this dangerous memset().
Detect CPU features at runtime via cpuid - code borrowed from
libavutil.
Availability of cpuid is not checked since pentium3 supports it
and that was the minimum requirement anyway.
Only features enabled at compile time will be available.
Forced MMX/SSE/SSE2/SSE3 and it passed all tests via:
./doom3.x86_64 +disconnect +set s_noSound 1 +testSIMD
Protect all SIMD implementations with the according defines and
let the compiler decide if it supports the intructions.
Linux will still use Simd_Generic because CPU feature runtime
detection is missing.
Get the idDrawVert member offsets directly instead of hardcoding
them and checking them via assert() at runtime.
Fixes compile error:
cast from pointer to smaller type 'int' loses information
This kills the funky GL logging stubs, which unnecessarily
complicates the build process (think future cmake).
As for logging GL calls: Use apitrace for that
https://github.com/apitrace/apitrace
idlib/containers/VectorSet.h:151:2: error: use of undeclared
identifier 'Append'
note: must qualify identifier to find this declaration in dependent
base class
int Append( const type & obj);
int Append( const idList<type> &other );
Thread return types are different between platforms, and its
probably not a good idea to return something of a different size,
cast the callback and expect it to not crash.
Alot of stack and event variables are pointers. Align the size of
all script and event variable types to sizeof(intptr_t) so that
the CPU needs only one fetch insn on 64bit archs.
Tested on x86 and x86_64 and found no different script behaviours
compared to the binary from id.
Savegames on x86_64 do work, but are not compatible to x86 and vice
versa (among other issues, the stack is written to file as-is).
x86 builds can still load savegames from the official binary and
vice versa.
