Tracking issue for progress on getting 64 bit builds going. This primarily targets AMD64, but once done should also work on AArch64/LE and other architectures.
Possibly it can enable more performance gains. One thing worth keeping an eye on is optimisations now possible to rct_map_element, which is 8 bytes long.
As of 2016-08-01 (9cf3419) Linux can properly build 64 bit versions and a job has been added to our Travis CI to make sure we don't regress. These builds can launch properly and load objects, but have issues rendering viewport, some(?) dropdowns don't work and they crash pretty soon after launch.
Once https://github.com/OpenRCT2/OpenRCT2/issues/3365 is closed, 64 bit build should be able to render pixel-perfectly compared to 32 bit builds
With https://github.com/OpenRCT2/OpenRCT2/pull/4191 it is possible to open in-game load window, load a game, join multiplayer and host a server all without a crash for significant period of time.
64-bit builds have two kinds of -Werror lifted:
-Wno-error=pointer-to-int-cast-Wno-error=int-to-pointer-castBelow are some collected stats (count of warnings):
A little progress video based on current #4203: https://www.youtube.com/watch?v=uLY6jmHtKgg&feature=youtu.be
https://github.com/OpenRCT2/OpenRCT2/commit/f8e0d4b25b7c678bac64c53986979919f7e16b2f fixed dropdowns using string_id == 0 as a separator
STR_EMPTY imho is the wrong name for use in dropdowns. DROPDOWN_SEPARATOR or something along the lines would make more sense, as it doesn't render as an empty string.
#define DROPDOWN_SEPARATOR 0
https://github.com/OpenRCT2/OpenRCT2/pull/4228 makes 64 bit builds render correctly:

https://github.com/OpenRCT2/OpenRCT2/pull/4244 enables (a bit incomplete) 64 bit builds on OS X.

https://github.com/OpenRCT2/OpenRCT2/pull/4243 added x86-64 configuration to Visual Studio project. It can be used in similar manner as #4244, but it requires contribution of Windows version of mmap.
-liconv to the final linking step.
Am I correct in assuming at this stage we only link segment files from the original binary for data that is not integrated as of yet? The missing paint functions aren't being used at the moment, anyway — I'm assuming that's because they're for a different architecture?
We're interested in .data segment. It is getting extracted from original binary and emplaced to memory at some known, arbitrary location. Whatever is trying to use original's data, will simply get redirected to the new location, which is why https://github.com/OpenRCT2/OpenRCT2/pull/4236 is needed. All the integrated stuff comes from our own .data segment, even though there might still be a duplicate of it loaded to memory – we simply don't use it anymore.
That answers the first half of my question, thank you. The unimplemented functions cannot be used, then, I take it?
I don't use them. Whether they can be used is a whole other story… They can be used, but it would probably come at severe performance hit, work only on Linux and not really worth it, as https://github.com/OpenRCT2/OpenRCT2/issues/3365 is going forward ever so slowly.
Audio tab in options doesn't work and may crash the game, because I don't know how to fix these set_format_args: https://github.com/OpenRCT2/OpenRCT2/blob/6644902/src/windows/options.c#L1521-L1536
@AaronVanGeffen no they can't be used, they are x86 instructions expecting 32-bit addresses. It just wouldn't work.
@IntelOrca yes, there are ways you could use them. You can switch between 32 and 64 bit mode on the fly.
But you have put the data in a 64-bit address range... the .data segment would have to remain in its original range.
yes. but 0x8a4000 is both in 32 bit and 64 bit range.
@janisozaur any other crashes that you know of?
No, I don't think I know of any more crashes now – at least versus 32 bit build.
Most helpful comment
No, I don't think I know of any more crashes now – at least versus 32 bit build.