• Blake [he/him]@feddit.uk
    link
    fedilink
    arrow-up
    7
    ·
    1 year ago

    I’d have thought the pain point would have been the processor architecture (ARM64) rather than operating system - MacOS still supports AMD64 using a compatibility layer but it would probably be quite a drawback to game performance.

    • OfficialThunderbolt@beehaw.org
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      Not really, unless the game code was written in X86-64 assembly language, does low-level VM allocation for some reason, or otherwise has special dependencies on Intel CPU-isms. With a few exceptions, C/C++/Objective-C code written for X86-64 can be easily recompiled for ARM64.

      The PowerPC to X86 transition was much rougher, because of the byte order change + PPC allowing integer division by zero while X86 disallowed it.

      • Blake [he/him]@feddit.uk
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        1 year ago

        What’s your experience here? I’m interested to hear about projects that you have done this for.

        The source engine has code that’s over 20 years old. A monolithic project like a game engine, which is statically and dynamically linked with god knows how many libraries they don’t even have code for, let alone permission, to compile in a different architecture, is not gonna be an easy thing to do.

        • OfficialThunderbolt@beehaw.org
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          I've brought various apps, bundles, and frameworks from PowerPC to Intel to 64-bit to ARM ever since macOS 10.0 first launched. Usually the most difficult parts were:

          1. During the PPC to Intel transition, converting code that expected all data to be big-endian over to handling little-endian data, and catching integer division by zero before sending such operations to the CPU
          2. During the 64-bit transition, switching from all the APIs Apple removed over to newer APIs, if not already done, and converting all code that expected integers and pointers to be 32-bit over to 64-bit
          3. During the ARM transition, converting code that abused variadic functions to code that used them properly, and converting all code that expected long doubles to be 128-bit over to 64-bit (I know some developers were burned by the VM page size change, but that didn't affect anything I did)

          But yeah, usually the most difficult part of the transition is managing the dependencies. Whenever Apple transitions CPU architectures, if your app depends on a closed-source third-party library or kernel extension made by developers that went out of business years ago, you're more or less screwed unless you can find or build a replacement.