ACE COMBAT 8: WINGS OF THEVE (2288340)

[RinCat]

Compatibility Report

• Name of the game with compatibility issues: ACE COMBAT 8: WINGS OF THEVE
• Steam AppID of the game: 2288340

System Information

• GPU: NVIDIA GeForce RTX 5090 32GB
• Video driver version: NVIDIA 615.71.09
• Kernel version: Linux 7.2
• Proton version: Proton Experimental / 11

I confirm:

• that I haven't found an existing compatibility report for this game.
• that I have checked whether there are updates for my system available.

Symptoms

Volumetric clouds are present and gameplay collision/inside-cloud effects work, but the visual cloud volume is clipped by a sharp horizontal plane below the aircraft/view. Cloud geometry below that plane disappears completely while the same cloud remains visible above it.

The issue persists with all graphics settings set to Low.

Mission 1

Mission 2

Clouds render correctly against the sky, but disappear wherever terrain is behind them. The clipping follows the terrain silhouette exactly.

The cloud rendering issue is unchanged with:

• Proton Experimental
• GE-Proton 11-7
• DW-Proton latest
• locally built current vkd3d-proton
• NVIDIA 615.71.09
• NVIDIA 610.x
• all graphics settings set to Low
• VKD3D_SHADER_MODEL=6_6
• VKD3D_CONFIG=force_static_cbv
• VKD3D_CONFIG=single_queue
• VKD3D_CONFIG=nodxr
• VKD3D_CONFIG=no_upload_hvv
• VKD3D_CONFIG=no_invariant_position
• VKD3D_CONFIG=force_host_cached
• VKD3D_CONFIG=skip_application_workarounds
• custom Engine.ini overrides disabling Lumen hardware RT, RT shadows, virtual shadows, dynamic GI, reflections, and forcing TAA

For comparison, an Intel Arc Pro B70 on the same system renders the clouds, although it has different lighting/reflection/upscaling artifacts.

The Proton log also contains repeated compute pipeline failures such as:

Required WaveSize range [64, 64], but supported range is [32, 32].

with similar failures for wave sizes 4, 8, 16 and 128, followed by:

Failed to create Vulkan compute pipeline, hr 0x80070057.

The RTX 5090 Vulkan driver reports:

minSubgroupSize = 32
maxSubgroupSize = 32

It is NOT yet confirmed whether these WaveSize failures are responsible for the missing-cloud rendering.

Reproduction

1. Launch ACE COMBAT 8 using Proton 11 / Experimental on an NVIDIA RTX 5090.
2. Start the first mission.
3. Observe that large portions of the cloud field are not visually rendered.
4. Fly into the location of one of the invisible clouds.
5. The game correctly triggers the in-cloud effects despite the cloud itself not being visible.
6. Fly out of the cloud volume; the in-cloud effects stop normally.
7. Lower all graphics settings to Low; the issue remains.

[Parmethyst]

Additionally would like to also mention that people found out multiplayer doesn't work as starting a multiplayer sortie gets you kicked out with error code ST-3200003, although the multiplayer hub itself works. The assumption as of now is that this is pretty much anticheat issue though (EAC).

[ac1dn0ise]

Reproduced on an RTX 3090 with the closed driver (NVIDIA 615.71.9) running GE-Proton11-7, so I started digging for a fix.

Original findings

I dumped all shaders the in-game warmer could generate with 'VKD3D_SHADER_DUMP_PATH'. Driver-side, the hardware subgroup size is fixed at 32 (minSubgroupSize = maxSubgroupSize = 32).

Correction to my earlier claim: I originally said the entire shader library assumes 64-wide waves. That was overstated! Of the 8.1k compute shaders in the dump, 4,602 have "LocalSize 64", but that's workgroup size, not wave size. Only 1,086 use wave ops, and 456 use ballot ops. Those are the ones where the hardware wave width could actually matter.

Update: testing a wave-size fallback

The log shows 28 compute pipelines failing with Required WaveSize range [N, N], but supported range is [32, 32] (hr 0x80070057), for N = 4, 8, 16, 64 and 128. Each of the 28 is a different shader hash with a single fixed size, and none asks for 32.

To test whether those rejections cause the missing clouds, I patched vkd3d-proton (d3d12_device_validate_shader_meta in device.c, and the subgroup-size selection in vkd3d_setup_shader_stage in state.c) so that an unsatisfiable WaveSize request is ignored, with a warning, and the driver picks its native size instead of failing pipeline creation.

Result, confirmed with the patched DLLs loaded (And only running the first game mission!):

• 28 "Ignoring unsatisfiable WaveSize" warnings
• 0 "Required WaveSize range" errors, 0 failed compute pipelines
• Didn't crash
• clouds still missing, no visible change on earlier cutscenes from the intro portion either.

So the WaveSize rejection of these 28 pipelines is not, by itself, what breaks the clouds. Either the cloud pass isn't among them, or those shaders run at wave32 but produce wrong output because they assume more lanes. I can't distinguish the two yet. For what it's worth, an Intel Arc reporter above also lacks wave64 and renders the clouds, which points the same way.

Next

• Map the 28 hashes to the dumped .dxil/.spv and see what they do.
• RenderDoc capture of a frame with the clouds missing, to find the pass where the horizontal cut first appears.
• Cross-reference that against the ballot/wave-op shaders.

Happy to share the patch or any logs/dumps that would help. If anyone (@HansKristian-Work?) knows whether D3D12 on Windows rejects or clamps fixed WaveSize requests on NVIDIA, that would help me narrow this down. I'm also considering vibe coding my way out of this one lmao.

The 28 shader hashes that requested an unsupported WaveSize

WaveSize 4:    6f2f52846716bf22 dffa883987ef26eb
WaveSize 8:    27ad2127b028b6b3 4a759e3ea0a23cee
WaveSize 16:   099336d8dd5b8a97 0e168a852cedefbc 28da48ab25891370 6665dfb0a2723da6
               87b221357c8ec2d9 8cd68471d54a75c0 a1db84d1f0c9e700 a31e7bbeabf5d245
               a34099de668ff7b0 b748e3fd4bbdf09a df945678402547a3
WaveSize 64:   13b48314821f8e28 1d0a6c7003601c7d 27591fcfef2d52ce 41c698c83f8285c8
               5e3aaef8ea12d041 60277b0b38298815 b46c15ec0f923f0e c31cc10042568960
               da2607306b9ea2a8 e2c908af44581bcd e6706734cc90c248
WaveSize 128:  37ff68e29f673cfc e96468baa58d4f75

[neur0mancer746]

Additionally would like to also mention that people found out multiplayer doesn't work as starting a multiplayer sortie gets you kicked out with error code ST-3200003, although the multiplayer hub itself works. The assumption as of now is that this is pretty much anticheat issue though (EAC).

The same, old issue of devs doesn't want to activate EAC for linux with a click of the mouse?

[empty-quiver]

Using NVIDIA Nsight, with help from GPT-6-Astra in Codex, I traced this to a cloud ray-march stall in SkyTraceCS and have a targeted workaround. I'm looking into a way to make some sort of script that maybe someone else could run to do the same shader patches until a proper fix is sorted.

The shader initializes invalid cloud/cirrus ranges to (-1, -1), then packs them into half precision after dividing by 131072. The generated SPIR-V applies OpQuantizeToF16 to -1/131072, a half-precision subnormal, which becomes negative zero. The invalid cirrus range consequently becomes (-0, -0): a ray at distance zero passes the inclusive range check, gets a zero-length step, and exhausts its 128-iteration budget without rendering clouds.

Relevant HLSL source excerpts

These excerpts come from the embedded HLSL debug source. Unrelated code is omitted, formatting is adjusted, and comments are mine.

// Invalid cirrus-range sentinel:
Pack(ret1.packing_cirrus_range, float2(-1, -1));

// Range packing:
void Pack(inout Packing_float2_TO_uint_Remap1e5 pack, float2 first)
{
    pack.first_packed = Pack_16_16(first * (1.0f / 131072.f));
}

// Inclusive range test:
bool IsInsideRange(float2 range, float t)
{
    return (range.x <= t) && (t <= range.y);
}

// Cirrus membership uses that test:
Pack_Bitmask(
    trace_state.bitmask,
    IsInsideRange(Unpack(ret1.packing_cirrus_range), trace_state.t),
    2
);

// Later, the cirrus range limits the step:
if (IsInsideCirrus(trace_state))
{
    const float cirrus_trace_range_length =
        Unpack_Y(ret1.packing_cirrus_range) -
        Unpack_X(ret1.packing_cirrus_range);

    step_length = min(step_length, cirrus_trace_range_length / (3 + 1));
}
float next_stop = trace_state.t + step_length;

With the intended (-1, -1) sentinel, t = 0 is outside the range. After conversion to (-0, -0), it is inside, and the range-length clamp forces the step to zero.

For shader e2ace7e3e8dbf87b, my patch is:

-%498 = OpQuantizeToF16 %float %float_n7_62939453en06
+%498 = OpCopyObject   %float %float_n7_62939453en06

The patch keeps the half-precision packing. It removes a separate OpQuantizeToF16 immediately before it, which turns the small negative sentinel into negative zero. With OpCopyObject, the original value reaches the packing instruction unchanged; in the Nvidia Nsight replay, it survives packing and unpacks back to -1.
The original HLSL packing helper already expresses a direct f32tof16(v) conversion. This workaround changes the generated SPIR-V; I haven’t established which part of the shader compilation path should receive the upstream fix.

The patch changes one byte in the 249,084-byte SPIR-V file, at offset 24096 (0x5E20):

74 00 04 00 → 53 00 04 00

Original SHA-256 of the shader:
6b6eda17573f21c74c2fe6466cb784d64c1c9b6227e7bd39fe5c64ddbce5c469

I apply it using VKD3D_SHADER_OVERRIDE, placing the replacement at <override directory>/e2ace7e3e8dbf87b.spv. vkd3d-proton substitutes the hash-matched shader when creating the pipeline. No modified Proton build or game file edits are required.

On an RTX 4090 with Proton Experimental, this restored clouds below the horizon in both the same Nsight replay and live gameplay. Instrumented replay confirmed that the sentinel remained -1 and the ray advanced normally. Depth tests, iteration limits, density evaluation, and compositing remain intact; the workaround does not disable ray tracing.

After another mission showed the symptom, I found 16 SkyTraceCS variants with identical cloud-range setup source and extended the same one-byte correction to each. All original and patched modules pass spirv-val --target-env vulkan1.3. I verified the original variant in replay and gameplay; the additional variants still need gameplay verification.

These are the 16 SkyTraceCS shader hashes found with the faulty sentinel conversion:

22fdcb556e490841
38f591d7629df2b6
43b1f2ca42fb23c0
59582be9428f0c60
713ad0f307870d6c
76d3b0fd2325587f
80f225e283cc4d72
87b42e91ceafed10
88ad084f83cf8ef9
aaf93c80eebd46d5
aff49440c4c76f41
c652fabba323d136
e2ace7e3e8dbf87b
e6afff4a21f36ae7
f00552bae8b97a19
fcef06642b47c3cd

Instruction IDs and byte offsets for the patch differ between variants.
This covers the variants of this shader I've found.

This establishes the failure mechanism in the captured shader, and a workaround, but not a real upstream fix. I am at least able to play the game with the clouds working correctly though! I haven't tested this for every single mission yet but I think this should cover most/all(?) of them now that the patch is applied to those 16 shaders. That is still pending testing as I replay the game for the second time.

Component	Version
GPU	NVIDIA GeForce RTX 4090
NVIDIA driver	580.159.03
Proton	Experimental 11.0-20260924 (experimental-11.0-20260924-x86_64)
Game	ACE COMBAT 8, Steam build 25201480, AppID 2288340
Vulkan API supported by NVIDIA driver	1.4.312
Host Vulkan loader	1.3.204
vkd3d-proton	3.1.0, build 7f0c30ad3c8f28d

AI use disclosure:
I used GPT-6-Astra in Codex to debug this with Nvidia Nsight frame captures. Getting Nvidia Nsight to capture a frame without incompatibility issues and then have it actually replayable on the GPU required a lot of iterating. I also do computer things for a living :3

[IsaacVaughn]

Would you mind posting the offsets you used for the other variants?

[ac1dn0ise]

Heeey guyss!! I've built a small script that automates the SkyTraceCS fix described by @empty-quiver !!

It scans the shader dump for the sentinel pattern, patches the 16 affected shaders via spirv-dis -> spirv-as, validates the output with spirv-val, and drops the results in an override directory ready for VKD3D_SHADER_OVERRIDE.

Repo: https://github.com/ac1dn0ise/ace8-cloudfix-linux/

Tested on RTX 3090 with GE-Proton11-7. Full run end to end: 16 discovered, 16 patched, 16 validated. Clouds render correctly in Mission 1. No game files or Proton builds were modified.

Thank you very much @empty-quiver for the original analysis and manual fix. This is was just the automation!

[empty-quiver]

@IsaacVaughn Sure, but keep in mind that these are from the shaders I dumped from my game, so if your proton version is different they might not be the same, I haven't checked different versions:

Shader hash	Offset (decimal)	Offset (hex)	Instruction result ID
22fdcb556e490841	63,252	0xF714	%502
38f591d7629df2b6	23,836	0x5D1C	%482
43b1f2ca42fb23c0	62,940	0xF5DC	%511
59582be9428f0c60	25,120	0x6220	%504
713ad0f307870d6c	24,860	0x611C	%488
76d3b0fd2325587f	62,392	0xF3B8	%496
80f225e283cc4d72	24,116	0x5E34	%498
87b42e91ceafed10	61,832	0xF188	%511
88ad084f83cf8ef9	62,692	0xF4E4	%517
aaf93c80eebd46d5	25,116	0x621C	%504
aff49440c4c76f41	63,800	0xF938	%517
c652fabba323d136	23,856	0x5D30	%482
e2ace7e3e8dbf87b	24,096	0x5E20	%498
e6afff4a21f36ae7	62,144	0xF2C0	%502
f00552bae8b97a19	61,284	0xEF64	%497
fcef06642b47c3cd	24,856	0x6118	%489

@ac1dn0ise Nice you beat me to it lol, I have a script here that people can also use and compare :)
https://github.com/empty-quiver/ac8-cloud-patcher

[ac1dn0ise]

Now I want to use yours XD.

[kisak-valve]

ACE COMBAT 8 (2288340)

Issue transferred from #10203.
@Itranar posted on 2026-10-01T12:37:23:

Compatibility Report

• ACE COMBAT 8 (2288340)

System Information

• GPU: RTX 5080
• Video driver version: nvidia-open 615.71.09, ( also on 610.57.04 )
• Kernel version: Arch Linux, kernel 7.2.7-arch1-1
• Steam Information and Runtime Report in Gist
• Proton version: Experimental (experimental-11.0-20260924), GE-Proton10-34, GE-Proton11-7 - all of them behave the same

I confirm:

• that I haven't found an existing compatibility report for this game. (of this nature)
• that I have checked whether there are updates for my system available.

Latest logs with PROTON_LOG=1 VKD3D_CONFIG=breadcrumbs %command%

Symptoms

During the third loading screen ( The Prologue | Wings of Theve | ), whilst loading the whole system freezes for few seconds, (yet the audio from other apps are playing fine), after which the game becomes unresponsive and stops doing anything until 2 minutes when UE5 error-01 displays and shuts the game. After the freeze GPU hangs on 100% use for few seconds after which returns to normal behavior.
Also Journalctl reports Xid 109

Reproduction

Turn on the game, start a new campaign, skip or watch the first 2 cutscenes, after which - during the loading screen - the problem happens.

[runar-work]

I also reproduced the GPU hangs on RTX 5070 with 615.71.09. It seems to be an Nvidia compiler bug, as I could work around it with the following Pyroveil config:

{
	"version": 2,
	"type": "pyroveil",
	"matches": [
		{ "opStringSearch": "87b42e91ceafed10", "action": { "glsl-roundtrip": true } }
	],
	"disabledExtensions": [ "VK_NV_raw_access_chains" ]
}