Targeting 64-bit

[Baker]

[mh]

The alias model stuff needs working over too as it stores data as offsets from the start of the header. The only real reason for this is to allow the model to be moved from hunk memory to cache memory, and to allow it to be moved around in cache memory if required. It might be simpler to just get rid of cache memory and store pointers directly. The downside is that MDLs would now need to be reloaded and converted to compatible commands each map load, but it's not 1996 any more and that shouldn't pose too much of a problem for a reasonably modern PC.

Rearchitecting cache memory to avoid the crappiness is another option that gets you the best of both but it's obviously a lot more work.

The third viable option is to say "to hell with native 64-bit support". A 64-bit CPU with a 64-bit OS on it should be able to run a 32-bit app. Of course, sooner or later 32-bit is going to go the way of 16-bit and the problem will need to be dealt with then.

[revelator]

for mingw64 you can replace the offending ints by intptr_t not sure if anything similar exists for msvc.

but as mh said atm its not a big concern as pretty much all 64 bit OS loads 32 bit quite fine.

then again its not a bad idea to try and fix 64 bit compilation allready now since some day it will come in handy. if not in quake then in whatever else you will be working on at that time.

[szo]

[Spike]

from what I remember, there are not too many issues blocking it.
mostly its just warnings.
however...

there's a bug in the sprite code, from what I remember.
and then there's the big one.

qc strings are indexes into the string table. logically a 32bit index is just fine. the catch is that quake is EVIL and gives offsets into other bits of memory, namely the sv.client[X].name strings, as well as any builtins that return a temp string.
the 'simple' solution is to just allocate those string buffers in some block on the hunk, after the progs is loaded(names persist, so you probably want to have two copies of it).
However, frik_file's strzone needs some sort of dynamic memory.
To be honest, if frik_file uses the Z_Malloc functions to allocate memory, you end up with a signed pointer to the hunk. negative strings tend to be in the dynamic zone at the start of the hunk (so dynamic<0, 0<=stringtable<tablesize, entlump>=tablesize, tempstrings>=tablesize,netnames>=tablesize).
If those strings are arranged to always only refer to a heap object, and your heap does not exceed 2gb in size, there's no unsolvable issue.
Alternatively you can do it the fte/dp way, and use the upper bits as a string classification ident. more forwards thinking, but more changes up front.

if you're targetting windows only, I wouldn't bother. sure win64 builds are a nice thing to have... but geez, what's the point? noone knows what sort of windows they have. they don't understand 32bit or 64bit systems, they just know they're running windows! If you're lucky, they might know that its called 'XP'...
And even if you do get a 64bit build, msvc doesn't have the full feature set of the 32bit build, namely lacking edit-and-continue, which is basically the sole feature that puts msvc above any other ide, which is basically the only reason I boot windows instead of linux (linux gets higher fps anyway).
Oh, and two binaries build for different archetectures might see different versions of the registry.

You should generally not need to use intptr_t (the win32 equivelent is named DWORD_PTR, by the way). In most situations, a size_t should suffice. intptr_t is really only useful if you want to cast directly from a pointer to an int, which shouldn't really be done anyway.
A size_t should be fine for the alias model code (typically its a uintptr_t anyway), and is sized correctly for any ptr-ptr result anyway.

[mh]

[Baker]

[Spike]

[daemonicky]

[Spike]

[revelator]

[daemonicky]

[revelator]

[Spike]

[mh]