Running X4: Foundations on ARM64/Apple Silicon

[HanoverGreen]

Greetings All,

Currently, no one (I can find...) has been able to get X4: Foundations running under Codeweavers Crossover. Installs fine. Won't run.
1. Is there a fundamental reason why the game won't run under emulation? Some hard code perhaps?
2. Is there something we can try with Crossover to allow the game to run? Switches / arguments to try?
3. Is there anything that Egosoft can add that would allow the game to boot? Wishlist...

Anyway, thank you in advance to whomever contributes useful information/advice. Would dearly love to play the game with my MacStudio.

Best Regards and Best Wishes!

[Imperial Good]

Any sort of errors thrown or logged? Try starting it with debugging log enabled.

Code: Select all

-debug all -logfile logfile.log -scriptlogfile scriptlogfile.log

Knowing why it is failing to start might lead to trying to fix why.

X4 uses exclusively Vulkan, so you will need MoltenVK somewhere in the emulation chain due to Apple refusing to natively support Vulkan. Check the emulator is using the latest release of MoltenVK, and possibly try anything from nightly releases to previous releases in case some are incompatible.

If using the steam version of X4 then try the "no-steam" executables in case it is related to the complexities of steam trying to run an emulated game.

Last I checked, Windows X4 seems to use a sort of direct I/O to read the cat data files more efficiently such as by bypassing the windows file cache. I am not sure how well this feature of Windows would be emulated on Mac OS as most games I have played to do not use it.

Might be worth trying to emulate the Linux build of X4 rather than the Windows build. The Linux build uses different APIs so if it is an API compatibility issue it might be a way around it. If trying with the Linux build already, try with the Windows instead for a similar reason.

[HanoverGreen]

Greets ImperialGood! Thank You for your reply!
1. I purchased the GOG version. The Galaxy installed fine (file structure looks good) but NOT the game. So I cannot try to launch without Galaxy. Galaxy won't boot with/without your args.
2. Is there a way I can download JUST the game? I installed the Galaxy on Mac but, of course, cannot install X4 there. // See below...
3. Is there a list of supporting apps like .NET (I installed 4.6.2) that Galaxy needs?
4. Also, Crossover supports Vulkan. I ran .log files and ended up with 8 and 11GB files. Seems a lot of WINE exceptions.
5. Just to be clear. CAN X4 run on ARM64 under emulation? At all?
6. Downloading to a Parallels appliance to see how it runs. Would copying the game folder into the Crossover folder to let WINE run it work?
I may but it on Steam after 1 Jan before the price increases if my masochistic tendencies haven't been satisfied by trying to get this working
Thank You again for responding and Best Regards and Best Wishes!
===
I installed X4 in Parallels, which does not support Vulkan, and so app doesn't run. Sooo. I copied the game folder into the Games folder on GOG Galaxy in Crossover and got the following message when the app crashed as it displayed a black screen. Good progress

Command error text:
esync: up and running.
[mvk-info] MoltenVK version 1.2.3, supporting Vulkan version 1.2.243.
The following 90 Vulkan extensions are supported:
VK_KHR_16bit_storage v1
VK_KHR_8bit_storage v1
VK_KHR_bind_memory2 v1
VK_KHR_buffer_device_address v1
VK_KHR_copy_commands2 v1
VK_KHR_create_renderpass2 v1
VK_KHR_dedicated_allocation v3
VK_KHR_depth_stencil_resolve v1
VK_KHR_descriptor_update_template v1
VK_KHR_device_group v4
VK_KHR_device_group_creation v1
VK_KHR_driver_properties v1
VK_KHR_dynamic_rendering v1
VK_KHR_external_fence v1
VK_KHR_external_fence_capabilities v1
VK_KHR_external_memory v1
VK_KHR_external_memory_capabilities v1
VK_KHR_external_semaphore v1
VK_KHR_external_semaphore_capabilities v1
VK_KHR_fragment_shader_barycentric v1
VK_KHR_get_memory_requirements2 v1
VK_KHR_get_physical_device_properties2 v2
VK_KHR_get_surface_capabilities2 v1
VK_KHR_imageless_framebuffer v1
VK_KHR_image_format_list v1
VK_KHR_maintenance1 v2
VK_KHR_maintenance2 v1
VK_KHR_maintenance3 v1
VK_KHR_multiview v1
VK_KHR_portability_subset v1
VK_KHR_push_descriptor v2
VK_KHR_relaxed_block_layout v1
VK_KHR_sampler_mirror_clamp_to_edge v3
VK_KHR_sampler_ycbcr_conversion v14
VK_KHR_separate_depth_stencil_layouts v1
VK_KHR_shader_draw_parameters v1
VK_KHR_shader_float_controls v4
VK_KHR_shader_float16_int8 v1
VK_KHR_shader_subgroup_extended_types v1
VK_KHR_spirv_1_4 v1
VK_KHR_storage_buffer_storage_class v1
VK_KHR_surface v25
VK_KHR_swapchain v70
VK_KHR_swapchain_mutable_format v1
VK_KHR_timeline_semaphore v2
VK_KHR_uniform_buffer_standard_layout v1
VK_KHR_variable_pointers v1
VK_EXT_buffer_device_address v2
VK_EXT_debug_marker v4
VK_EXT_debug_report v10
VK_EXT_debug_utils v2
VK_EXT_descriptor_indexing v2
VK_EXT_external_memory_host v1
VK_EXT_fragment_shader_interlock v1
VK_EXT_hdr_metadata v2
VK_EXT_host_query_reset v1
VK_EXT_image_robustness v1
VK_EXT_inline_uniform_block v1
VK_EXT_memory_budget v1
VK_EXT_metal_objects v1
VK_EXT_metal_surface v1
VK_EXT_pipeline_creation_cache_control v3
VK_EXT_post_depth_coverage v1
VK_EXT_private_data v1
VK_EXT_robustness2 v1
VK_EXT_sample_locations v1
VK_EXT_scalar_block_layout v1
VK_EXT_separate_stencil_usage v1
VK_EXT_shader_atomic_float v1
VK_EXT_shader_stencil_export v1
VK_EXT_shader_viewport_index_layer v1
VK_EXT_subgroup_size_control v2
VK_EXT_surface_maintenance1 v1
VK_EXT_swapchain_colorspace v4
VK_EXT_swapchain_maintenance1 v1
VK_EXT_texel_buffer_alignment v1
VK_EXT_texture_compression_astc_hdr v1
VK_EXT_vertex_attribute_divisor v3
VK_EXT_transform_feedback v1
VK_AMD_gpu_shader_half_float v2
VK_AMD_negative_viewport_height v1
VK_AMD_shader_image_load_store_lod v1
VK_AMD_shader_trinary_minmax v1
VK_IMG_format_pvrtc v1
VK_INTEL_shader_integer_functions2 v1
VK_GOOGLE_display_timing v1
VK_MVK_macos_surface v3
VK_MVK_moltenvk v37
VK_NV_fragment_shader_barycentric v1
VK_NV_glsl_shader v1
[mvk-info] GPU device:
model: Apple M1 Max
type: Integrated
vendorID: 0x106b
deviceID: 0xe0003ef
pipelineCacheUUID: 11C34DCA-0E00-03EF-0000-000000000000
supports the following Metal Versions, GPU's and Feature Sets:
Metal Shading Language 3.0
GPU Family Apple 7
GPU Family Apple 6
GPU Family Apple 5
GPU Family Apple 4
GPU Family Apple 3
GPU Family Apple 2
GPU Family Apple 1
GPU Family Mac 2
GPU Family Mac 1
GPU Family Common 3
GPU Family Common 2
GPU Family Common 1
macOS GPU Family 2 v1
macOS GPU Family 1 v4
macOS GPU Family 1 v3
macOS GPU Family 1 v2
macOS GPU Family 1 v1
[mvk-info] Created VkInstance for Vulkan version 1.1.0, as requested by app, with the following 4 Vulkan extensions enabled:
VK_KHR_get_physical_device_properties2 v2
VK_KHR_get_surface_capabilities2 v1
VK_KHR_surface v25
VK_EXT_metal_surface v1
[mvk-info] Vulkan semaphores using Metal implicit guarantees within a single queue.
[mvk-info] Created VkDevice to run on GPU Apple M1 Max with the following 3 Vulkan extensions enabled:
VK_KHR_swapchain v70
VK_EXT_descriptor_indexing v2
VK_EXT_memory_budget v1
[mvk-info] Created 3 swapchain images with initial size (1920, 1080) and contents scale 1.0 for screen VG248.
wine: Unhandled page fault on execute access to 0000000000000004 at address 0000000000000004 (thread 0034), starting debugger...

[BitByte]

You can download GOG games via their website. Open it using web browser, login, open your games and look X4 Foundations -> Offline installers.
GOG offers at the moment downloads for Windows and Linux.

[Imperial Good]

Galaxy won't boot with/without your args.

Those arguments are for the X4 executable, not the launcher. They could report more information about why a crash happened.

2. Is there a way I can download JUST the game? I installed the Galaxy on Mac but, of course, cannot install X4 there. // See below...
3. Is there a list of supporting apps like .NET (I installed 4.6.2) that Galaxy needs?

I do not know. I use the steam version of X4. BitByte above mentioned you might be able to download an offline installer for X4 from the GoG site. I recommend trying to use that and possibly trying both as Windows and Linux use different APIs to emulate.

Seems a lot of WINE exceptions.

Possibly post a few unique ones that show up repeatedly in the logs? Might give an idea as to why it is failing.

5. Just to be clear. CAN X4 run on ARM64 under emulation? At all?

I do not know. I do not recall someone playing X4 saying that they were doing so on Apple Silicon.

wine: Unhandled page fault on execute access to 0000000000000004 at address 0000000000000004 (thread 0034), starting debugger...

Trying to execute that address is strange as statically compiled code should not be trying to jump or call to such an address. Could there be some sort of JIT compiler involved in X4? Apple requires JIT compilers be designed in specific ways to be compatible, specifically they need to manage their permissions and memory region access in an Apple compliant way.

[HanoverGreen]

Thank You @Imperial Good. Have passed this data on. Still no success but maybe in future WINE or Crossover will be able to get past these issues and run X4.

Best Regards and Best Wishes for 2024!

[adeine]

I suspect performance wouldn't be great even if you did get it to run. The game is fairly resource intensive, so a lower powered system with significant added overhead due to emulation is not likely to deliver a good experience.

If you have decent internet, it might be worth looking into streaming solutions like Geforce Now.

[Imperial Good]

I suspect performance wouldn't be great even if you did get it to run. The game is fairly resource intensive, so a lower powered system with significant added overhead due to emulation is not likely to deliver a good experience.

Modern M2 and M3 apple devices are not "a lower powered system". Although their CPUs are unlikely to topple the current best AMD and Intel has to offer for desktop, they can certainly run games well, if the games can be made to run. Especially given the very high performance memory they have which is something that X4 might benefit from. The emulation overhead is significant, but I could still imagine the results being well within the playable range, especially on M3 macs.

[V3N]

Any way I can contribute to this? I have crossover and I'd like to be able to get off Geforce now so I can start using mods

[maccer]

to add to the performance discussion: https://www.cpu-monkey.com/en/compare_c ... _i9_13900k

[Quirkz]

Modern M2 and M3 apple devices are not "a lower powered system".

Adding to this: The single threaded score of the apple silicon tends to be *very* good for a laptop class device: And when running certain CPU constrained games, tends to perform surprisingly well. They also have incredible memory bandwidth (especially pro/max chips). X4 loves both memory bandwidth and single threaded CPU performance.
Could bode well for a surprisingly decent experience.

The emulation overhead is significant,

To be a pendant, it's not emulation, it's translation. So none of the virtualisation overheads you'd otherwise get.
Translation overheads, yes. But not emulation.

All in all, it generally seems that the native port runs about 20 to 80% faster than the translated windows version.
Which is pretty wild, when you think about it. Usually, it means that it would be playable.

So yeah, I'd expect that if we could get it running under crossover, performance would be adequate on at least some macs. Probably not the base spec air though.

[Imperial Good]

To be a pendant, it's not emulation, it's translation. So none of the virtualisation overheads you'd otherwise get.
Translation overheads, yes. But not emulation.

To be technical...

In computing, an emulator is hardware or software that enables one computer system (called the host) to behave like another computer system (called the guest). An emulator typically enables the host system to run software or use peripheral devices designed for the guest system. Emulation refers to the ability of a computer program in an electronic device to emulate (or imitate) another program or device.

https://en.wikipedia.org/wiki/Emulator

Yes it is an emulator doing emulation. It is one computer system (ARM based Mac) behaving like another computer system (x86-64 based mac and/or Windows or Linux APIs). The process by which it is doing emulation I think is a combination of recompilation in advance and JIT compilation, both of which are standard in most modern high performance emulators. I think there may be some dedicated instructions to help improve the performance as well, but outside of early day speculation and marketing I could never find much details about them other than they help emulate the x86-64 memory model more efficiently.

Still should be fast enough from a CPU perspective to play X4, especially early game.

[Quirkz]

To be technical...

In computing, an emulator is hardware or software that enables one computer system (called the host) to behave like another computer system (called the guest). An emulator typically enables the host system to run software or use peripheral devices designed for the guest system. Emulation refers to the ability of a computer program in an electronic device to emulate (or imitate) another program or device.

https://en.wikipedia.org/wiki/Emulator

Yes it is an emulator doing emulation.

We're totally off topic here, but I'm going to continue anyway, just because the specific case of Rosetta 2 is so interesting.
In most cases, you'd be correct around emulation. Original Rosetta, for example. But in this *specific* case, it's translation, rather than emulation.
They're using both ahead of time translation, and just in time to effectively create a new version of the application that then runs directly on the silicon.
It's not doing what classic emulators do, in intercepting system calls and replacing them with new versions in real time, for example, or interpreting each CPU operation as they occur. With Rosetta 2, you get a *native binary* that executes directly on the apple silicon.

I don't normally argue about pointless things like this, but like I said: In this particular case, it's just so impressive what apple pulled off, and why it's so fast.

From https://developer.apple.com/documentati ... nvironment
"Rosetta is a translation process..."

more info
https://apple.stackexchange.com/questio ... tta-2-work
https://ffri.github.io/ProjectChampollion/part1/

[Imperial Good]

"Rosetta is a translation process..."

It works by translation as opposed to being an interpreter but it is still an emulator. Wikipedia literally has it categorised as one.

https://en.wikipedia.org/wiki/Rosetta_(software)
Categories: MacOS-only software made by Apple Inc. MacOS emulation software MacOSPowerPC emulators X86 emulators Department of Computer Science, University of Manchester Rosetta Stone in popular culture

"Emulator" is a very broad category that pretty much covers the process of any computer system behaving like another computer system to allow it to run code or logic intended for that other system. When referring to emulator overhead, this covers any loss in potential performance as a result of the emulator. Although MacOS's Rosetta for apple silicon is a very good emulator, it still has significant emulation overhead. This can be seen in games that are built for x86 MacOS vs those same games built for ARM Apple Silicon. As far as examples go, Dolphin GameCube/Wii emulator and Factorio both have benchmarked proof that a native Apple Silicon build performs significantly better than running the x86-64 build with Rosetta. The performance impact of the emulation process, despite being translated, is often given as around 30%.

This would still be more than playable for X4 if X4's Windows or Linux x86-64 binaries could run on MacOS. I think the main issue is with MacOS's emulation of the Vulkan API. Even if an ARM port was made, it would still need to use MoltenVK to emulate the Vulkan API due to Apple's continued refusal to support Vulkan natively. The developers of MoltenVK seem to be avoiding implementing some features of the API accurately or at all due to their incompatibility with how Apple Metal operates. Specifically, Metal lacks native, possibly even at a hardware level, support for some Vulkan data formats or data processing approaches which might result in extremely poor (90%+ slowdown) performance for applications that use those features if they were emulated accurately.

[Daemonjax]

I have no idea how crossover works, but arm64 is very different from amd or intel x64 preocessors... besides all the obvious stuff, there's different guarantees the cpu architecture makes regarding thread happens-befores and visibility. High performance multi-threading code designed to run just dandy on x64 will probably subtly fail on arm64 (even after accounting for the rest of the obvious differences).

[stshontikidis]

So I do not think this is an ARM issue, my take is that the game checks the VENDOR ID and DEVICE ID to see if it is in some master list of cards that are fully Vulkan compatible, when launching I get

Couldn't Sselect a compatiable vulkan device
(defualt 1):
1: Vendor 0x106b Apple M4 Max 65536MB
(0xf043f1)

0x106b is definitely the Mac vendor ID and am betting the other hex code is a device ID. I have been playing around with how to present a different vendor/device ids to the game to pass this check, mainly with trying dxvk.conf and wine registry keys but not having any luck.

Does anyone know how to override those values that Crossover presents? In the logs it looks like MoltenVK (MVK-Info) is still pulling the actual IDs instead of anything I set in those configs which is what is also shown in the error message on screen which is a game message so the game is "launching"