From the mailing list,
The following patch adds support for builds on mingw-w64 for x86_64
windows targets.
VM compilation, Interpretation and DLLs are supported (VM compilation
was the main one taking time).
baseq3 and q3ut4 are tested in all vm modes on devmap.
- Makefile edits are slightly a mess (mostly done to get it going
quick) though it does attempt to be proper; main 'mess' is that
COMPILE_ARCH is hardcoded since uname -m | sed -e s/i.86/i386/ returns
i386 on mingw-w64; most probably an msys issue.
- Some minimal 'beaurocratic' edits in 2 jpeg headers are included
that let it compile
- q_platform is edited for the __WIN64__ platform
- vm_86_64.c and assembler are the most heavily modified:
- longs are replaced with int64_t and unsigned longs with uint64_t
- other similar C99 compatible modifications are included
- functions such as strtol are converted to their long
long output equivalent (this was required to avoid 3D rendering going
berserk)
- (predominant difference between w64 and unix64 on a
high level is that long is 32bit on w64)
- CROSSCALL is used to call functions used in the
assembly; this is __attribute__ ((sysv_abi)); it effect, it 'fools'
the vm that we're UNIX, and since the vm doesn't violate the win abi
on its own (called via advanced inline asm with its registers
protected) it doesn't mind. With this, assembly generation doesn't
require rewrite and there isn't theoretically any slowdown.
- sys_win32.c includes Sys_SnapVector() in the case of __WIN64__
similarly to sys_unix.
- code/libs/win64 needs the SDL libs compiled for w64, I include them
after the patch, along with the DLL (all are non-debug versions) (SDL
is very straightforward to be compiled (for w64) on its upstream,
however, for some reason I couldn't get a functional DLL lately, at least
on the latest gcc used; .a libs were fine though; DLL included here is
an earlier working one),
patch: http://www0.org/vm/diff-w64.bz2
code/libs/win64 libs: http://www0.org/vm/libs.win64.tar.bz2
SDL.dll w64: http://www0.org/vm/SDL.dll-w64.bz2
This is smooth on online play; I went through several maps in online games and there was no issue.
I got a report that it doesn't go beyond ui and another that it works fine.
I get choppy sound on openal only and I suspect a compilation of OpenAL-soft in 64bit may be a good idea.
From the mailing list, The following patch adds support for builds on mingw-w64 for x86_64 windows targets. VM compilation, Interpretation and DLLs are supported (VM compilation was the main one taking time). baseq3 and q3ut4 are tested in all vm modes on devmap. - Makefile edits are slightly a mess (mostly done to get it going quick) though it does attempt to be proper; main 'mess' is that COMPILE_ARCH is hardcoded since uname -m | sed -e s/i.86/i386/ returns i386 on mingw-w64; most probably an msys issue. - Some minimal 'beaurocratic' edits in 2 jpeg headers are included that let it compile - q_platform is edited for the __WIN64__ platform - vm_86_64.c and assembler are the most heavily modified: - longs are replaced with int64_t and unsigned longs with uint64_t - other similar C99 compatible modifications are included - functions such as strtol are converted to their long long output equivalent (this was required to avoid 3D rendering going berserk) - (predominant difference between w64 and unix64 on a high level is that long is 32bit on w64) - CROSSCALL is used to call functions used in the assembly; this is __attribute__ ((sysv_abi)); it effect, it 'fools' the vm that we're UNIX, and since the vm doesn't violate the win abi on its own (called via advanced inline asm with its registers protected) it doesn't mind. With this, assembly generation doesn't require rewrite and there isn't theoretically any slowdown. - sys_win32.c includes Sys_SnapVector() in the case of __WIN64__ similarly to sys_unix. - code/libs/win64 needs the SDL libs compiled for w64, I include them after the patch, along with the DLL (all are non-debug versions) (SDL is very straightforward to be compiled (for w64) on its upstream, however, for some reason I couldn't get a functional DLL lately, at least on the latest gcc used; .a libs were fine though; DLL included here is an earlier working one), patch: http://www0.org/vm/diff-w64.bz2 code/libs/win64 libs: http://www0.org/vm/libs.win64.tar.bz2 SDL.dll w64: http://www0.org/vm/SDL.dll-w64.bz2