Openrct2: 64 bit builds should be working

Created on 1 Aug 2016  Â·  21Comments  Â·  Source: OpenRCT2/OpenRCT2

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

information

Most helpful comment

No, I don't think I know of any more crashes now – at least versus 32 bit build.

All 21 comments

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-cast

Below are some collected stats (count of warnings):

  • 2016-08-02 (63c74b4): 234
  • 2016-08-02 (e80bc86): 190
  • 2016-08-04 (0be54fb): 161
  • 2016-08-05 (801c7f2): 98
  • 2016-08-07 (bb822e3): 91
  • 2016-08-12 (38b5bba): 24 – although this is first check after #4244 got merged, which may have hid some warnings.
  • 2016-08-28 (51137b1): 11
  • 2016-09-04 (d9274ff): 0 all warnings were fixed and warnings-as-errors were reinstated on both appveyor and Travis

A little progress video based on current #4203: https://www.youtube.com/watch?v=uLY6jmHtKgg&feature=youtu.be

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.

https://github.com/OpenRCT2/OpenRCT2/pull/4228 makes 64 bit builds render correctly:

openrct2_141

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

screen-shot-2016-08-06-at-5 42 02-pm

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.

4244 now includes code which can produce 64 bit version for Windows using mingw64 toolchain. There's a small issue, where I had to manually add -liconv to the final linking step.

openrct2_win64

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.

Was this page helpful?
0 / 5 - 0 ratings