This makes it possible to just pass `-8` to ./waf configure on Windows
and it will build 64-bit binaries. Yay I guess.
However, it's completely broken conceptually -- it ends up just brute
rewriting `conf.env.DEST_CPU` from `amd64` to `x86_64` at one particular
point in wscript. Why? Because many places in build system expect
`x86_64` as 64-bit DEST_CPU, especially breaking SDL2 lib detection.
Some of these are in waifu and patching that is beyond what I can hold
in my head right now.
Why that particular point? Because it DEST_CPU gets rewritten a few
times before that and no times after it seems.
This does not address `./waf msvs` VS project generation yet -- it will
still produce only Win32 platform that needs to be manually rewritten.
There's a mechanism for msvs extras to be passed a set of platforms, but
I've yet to make it work.
Quality of this commit is questionable. I have no idea whether what I did
here makes sense or not.
But it compiles and runs (provided with hlsdk-xash3d amd64 build, which
is another story).
This omits necessary waf changes that are necessary to make a valid
64-bit build. Apparently it's not enough to just pass `-8` on Windows,
you also need to hack wscript to add `x64` target to MSVC. I'll do that
later when I figure out how.
This change is a precursor for RTX Vulkan effort --
VK_KHR_ray_tracing_pipeline and friends are only available on 64-bit
nvidia drivers (no idea about AMD, pls send GPUs onegai).
They were negative by default but they should've been positive:
> a value ranging from -32768 to 32767. Triggers, however, range from 0 to 32767 (they never return a negative value).
https://wiki.libsdl.org/SDL_GameControllerGetAxis
This fixes LTRIGGER and RTRIGGER (L2/Zl and R2/Zr on most gamepads)
