Cannot create a trace file as the games are unable to start when those files are present with the game exe.

I have tried the latest master, no change. Tried everything on my end, including running on a different PC. The issue persists.

I'm having this issue with every AC game before Black Flag. The wrapper works great with other older DX9 games. Works fine without it, so there must be some issue with the wrapper, since it wouldn't conflict otherwise.

Should be in the log file, but I am on Windows.

Damn. I can't generate one as the games refuse to start with it :/

Managed to get apitrace to run with the game, but how do I use DXVK alongside it, since they both have the same dll name ?

Done :) I let it go into the gameplay for a few seconds

Compressed and uploaded to MediaFire. Hope that is fine. I do not have access to more premium cloud storage services.

https://www.mediafire.com/file/6do6yvodfb0mo9c/ACRSP.7z/file

Any idea what I should be looking at to try and find the cause of the problem ?

Tried all that, except booting the machine without my mouse, which I will try now.

No good. That's on two different PC's with every single input device and USB device disconnected, other than a keyboard.

Input device can be ruled out.

I don't know what your system config is, but I tested AC Brotherhood on my Ryzen + Vega with latest drivers and default DXVK conf file. The game works fine on both Win10 and Win7, I just noted some odd shadow banding here and there.

My system config is I5 2400 / GTX 960 / Win10. And the other computer is a Ryzen 3700x / RTX 3070 / Win 10.

The issue happens with both computers, and considering they are completely different set-ups, the issue can't be isolated to just myself.

Just noticed something in your video.

If you look closely at your minimap in the lower right, you can clearly see the map spinning back and forth. It's not a video buffer bug, the camera is actually moving. Somehow it looks more like an input issue. Some driver or software could conflict with the games, even if the device is unplugged.

Same bug happening with me, both in Windows 10 (only when using DXVK) as well as Manjaro Linux 21.1.3. I'm using the Ubisoft Connect version of the game (Assassin's Creed 2).
@doitsujin can we please reopen this issue, because it seems to be happening with DXVK even on Windows 10?
I'm using a Geforce 940MX which does support Vulkan, using DXVK 1.9.2

@K0bin added the dx9 api trace for the windows version. couldn't add the dxvk trace because the trace d3d9.dll replaces the dxvk d3d9.dll, but i've added before and after dxvk traces for a fresh installation of the game.
also added a dxdiag for my system if thats also required.
link : https://github.com/netizener/ac2_trace/releases/tag/1
please ping me if you need any other requirements for this issue to be fixed.

Has there been any progress on this ? - I have put together a whole new PC since I first opened this issue, and I get the same exact issue on my latest build.

Has there been any progress on this ?

No, the issue is still unique to your systems.

Unique to a low number of people and their setups, but still an issue nonetheless.
There is a conflict between some hardware/software and dxvk.

Ignoring it just because it doesn't affect everyone isn't good. Just leads to other issues that get ignored down the line before people move on completely.

fwiw this issue seems to also happen for some windows users without dxvk. Try to see if the workaround the devs have posted helps. https://steamcommunity.com/app/201870/discussions/1/3114770913767276898/

But i'm still gonna try and see if i can reproduce dxvk being a trigger of it on my two setups.

No issue on my PC builds without DXVK. Only happens once I start using it, which is essential for me since the early AC games are very CPU intensive. Even a 3700x can't hold 60fps in heavily crowded areas. DXVK takes away that CPU overhead massively, by the looks of things.

There is a compatibility issue somewhere that is triggered by DXVK. Sadly, with the issue getting closed, it doesn't look like we will find out the cause anytime soon.

I did indeed. Renaming or deleting the system detection dll doesn't help. Also, Revelations is the only one that uses this dll file. AC1,2, BH do not use it.

I have tried all the common solutions that have been posted in steam and Ubi forum threads. Nothing has worked outside removing DXVK itself, which is obviously not what I want to do as I need it to relieve CPU overhead, which is a major issue in these games.

Okay. Another new AMD PC build for home, and my Intel/Nvidia based system at work still have the same issue. All computers I have tested since originally opening this issue have been using different hardware, peripherals, and different versions of Windows, and drivers. Same result every time.

This not an isolated problem, and affects anyone trying to run DXVK with Assassin's Creed II,BH,REV (and maybe later titles. I haven't tried them) on Windows.

Linux works fine.

Any progress on this ?

#3546 I have found out what the bug was.

#3546 I have found out what the bug was.

This is NOT the issue. It is still a relevant bug to many people.

The issue is still there sadly there is a conflict between dxvk and the early AC games for some reason...

Tried Direct3D9On12 wrapper for Direct3D 9, game bouncing same.
https://github.com/elishacloud/dxwrapper

Well, I'm facing the Same Issue. The Screen is shaking as shown in the video. For me, it was on Assassin's Creed II. Notes to be taken that I am using Community Edition Remastered Mod. As soon as I remove the dxvk file, the game works perfectly fine. I am using dxvk for the 1st time on this game. The Game is installed in the SSD Windows Drive if that helps

Same is happening on my end for ACII, ACB and ACR on Windows 11. I tried pretty much every combination of setting/fixes but nothing seems to affect this.

Hello there.

I'm not going to rule out some window message or cursor nonsense going on (although according to the trace, the game doesn't use the cursor APIs), but unless we can reproduce this on our end, we will not be able to fix this.

I have tried again to reproduce in assassins creed 1 again both on linux and windows, but i have been unable to.
Setup and repro details:
Nvidia 960, 516.59 driver, no GeForce experience installed on windows 10 (so no overlay), dxvk 1.9.1, launched both through steam and direct through exe, both dx10 & dx9, two monitors connected and main one i tried switching between 165hz and 60, tested ingame at various resolutions and with vsync on and off, only a mouse connected.

Mr. Blisto91 previously tried to launch AS1 and everything works for him. On my device, versions dx9 and dx10 also work without problems. But AS2 works like for the author of this thread.

And also considering the words of doitsujin, I intend to try different launch parameters via dxwnd. Since for others, the game still launches on Vulkan without problems. I tried disabling the software for my X7 mouse - it did not help. Disabled all input devices in the device manager - it did not help. Now I am trying different input parameters and parameters for the mouse. I am also trying windowed mode.

I think I will not find anything sensible. But the desire to play AS2 without freezes outweighs common sense.

Sup gamer fellows.

Today I did a recording in apitrace in native d3d9 (link to google drive). And also spent the whole day recording the Vulcan version via GFXReconstruct and RenderDoc. But apparently it's useless...

I'm attaching an image with GFXReconstruct parameters. RenderDoc refused to launch the game, possibly because it's 32-bit.

Do these actions make sense in the context that this error is not reproducible?

Regards,
Andrew

With dgvoodoo2 a strange thing happens on my device. After reinstalling the game and wrap to d3d12 - the camera does not bounce (but the fps is reduced by 2 times). But after switching to d3d11 and again to d3d12 bounces begin.

I can reproduce this (reinstall and wrap to d3d12) if you are interested.

PS. How did you managed to trace dxvk version via apitrace?

It doesn't matter if the authors manage to solve the camera problem in the PC Ezio trilogy, in any case DXVK is a huge and incredibly amazing project.

I wish all the best to the authors involved in the project, as well as those who leave bug reports.

Happy New Year.

Sorry for being off topic in this thread.

It doesn't matter if the authors manage to solve the camera problem in the PC Ezio trilogy, in any case DXVK is a huge and incredibly amazing project.

I wish all the best to the authors involved in the project, as well as those who leave bug reports.

Happy New Year.

Sorry for being off topic in this thread.

Indeed. Although if they did manage to fix this issue, it would single-handedly transform the experience of playing the Ezio trilogy on PC. The DX9 rendered implementation in all of these games is poor and stuttery.

Indeed. Although if they did manage to fix this issue, it would single-handedly transform the experience of playing the Ezio trilogy on PC. The DX9 rendered implementation in all of these games is poor and stuttery.

This is Ubi's problem and they need to solve it. Maybe they'll make a remaster for the 20th anniversary or maybe not. All we can do is endure the freezes.

Well something unexpected happened. I tried the x64 version dll for Assassin's Creed 2 and the screen flicker is gone. But don't know if the dxvk is working or not.

Indeed. Although if they did manage to fix this issue, it would single-handedly transform the experience of playing the Ezio trilogy on PC. The DX9 rendered implementation in all of these games is poor and stuttery.

This is Ubi's problem and they need to solve it. Maybe they'll make a remaster for the 20th anniversary or maybe not. All we can do is endure the freezes.

Does it work under Linux though? Yes, yes it does.

As such, it should work under Windows too.

More evidence that AC: Brotherhood also works under Linux.

As a matter of fact, I installed Linux to try it out myself and there is 0 issues there running either game. I'm sure Revelations is no different.

I am convinced that this is an issue with the camera vectors being scrambled as when you try punch an NPC in DX9 the camera shakes, but it naturally shakes MUCH more intensely under DXVK.

I also noticed that AC: Brotherhood has less input options under Linux than it does under Windows. Might be a biproduct of Wine emulation, but it could also point to a bug with inputs on Windows.

Could you share your config file for AC2 after launching on liunx?
It shoud store here: C:\Users%USERNAME%\AppData\Roaming\Ubisoft\Assassin's Creed 2

PS. I also going to install linux as I get a hard drive

Could you share your config file for AC2 after launching on liunx? It shoud store here: C:\Users%USERNAME%\AppData\Roaming\Ubisoft\Assassin's Creed 2

PS. I also going to install linux as I get a hard drive

ACII ACB Linux config.zip

Going to try running the games with these.

Changing the configs did nothing. I also tied forcing various "d3d9.customDeviceId =" and "d3d9.customVendorId =" in dxvk.conf, to no avail.

I also noticed that AC: Brotherhood has less input options under Linux than it does under Windows. Might be a biproduct of Wine emulation, but it could also point to a bug with inputs on Windows.

What you mean? Are you talking about selecting a control type? In your config file I see that the number of input types is the same as mine.

Today I tried to completely remove all input types except keyboard + mouse (2 buttons) and Bluetooth gamepad, but this did not help solve the issue with camera shaking. The fields with the key value for the removed types were equal to "undefiend". I could not completely remove other input types.

I also noticed that AC: Brotherhood has less input options under Linux than it does under Windows. Might be a biproduct of Wine emulation, but it could also point to a bug with inputs on Windows.

What you mean? Are you talking about selecting a control type? In your config file I see that the number of input types is the same as mine.

Today I tried to completely remove all input types except keyboard + mouse (2 buttons) and Bluetooth gamepad, but this did not help solve the issue with camera shaking. The fields with the key value for the removed types were equal to "undefiend". I could not completely remove other input types.

I noticed that ACB had 3 input option under Linux, while it had 5 under Windows (extra mouse and keyboard options).

I am testing some other things atm to see if it helps

For me, camera shaking is not related to input. I noticed that when using DXVK the boat seems to reset its position. If it was just the camera, the boat would remain motionless. I'm not a game developer of course, if I'm wrong correct me. It seems like the problem is in the graphics driver.
AC2 gameplay with DXVK
AC2 native gameplay

Edit: Well, found the Cause. I had d3d9.asi file in the scripts folder. It was for reshade.

I don't know why The Game does not open now. It closes after showing the Black Full Screen Window. I am using the Intro Skip trick.

Maybe the title should be changed a bit (if it can be, idk if GitHub allows that), because this shaky-camera issue is also present with Assassin's Creed 3 when using DXVK on my PC. My specs are i5-13600K, RTX 3060 12GB, 32GB of DDR5 5200 MT/s RAM, and I thought I should also mention that I'm using a 75 Hz 1080p Dell S2421HN display, if that's helpful in any way. I should also mention that I'm using Nvidia's legacy DSR 4x mode to downsample the game from 1080p to 4K.

Edit: I should also include the fact that I had seen the PCGamingWiki page of the original AC3 say that the game has some camera bugs when using DX11, so forcing DX10 is recommended but it provides no way to actually force DX10 in the game, nor can I find any way to do it anywhere else so maybe just finding a way to force DX10, and then translating that to VULKAN would maybe help fix this issue?

Yes, I am sure (and yes, I am of course talking about the original version of the game and not the "Remastered" version). Revelations also suffered from this same issue on my PC, but that was fixed by just deleting or renaming the systemdetection.dll file, although I didn't test DXVK on Revelations. I tested it out with this game in particular because PCGamingWiki suggested it and went down a rabbit hole to try and figure out what is causing this with this game in particular. I have looked around the web trying to find ways to force DX10 in this game since that should technically be supported according to the minimum requirements specs, and PCGamingWiki recomended it. I should mention that this issue starts right as you boot up the game, that is to say that it is present even in the main menu before you even start the game. I don't know if I should post external links here, but I have also tried some Windows 10 SDK thing which had a program called dxcpl.exe to try and force DX10 but that didn't help either, at least not according to RTSS since it still shows D3D11 alongside the FPS.

Edit: One thing I should definitely add, which might be unique to my experience in AC3 or maybe not, is that every time I install DXVK in this game, it will crash the first time when I launch it without any error message, but the second time around, it will run and have that shaky-camera problem.

I don't know how, but I forgot to mention that I'm using a fairly rare edition of Windows 10 with which I'm playing AC3, it is Windows 10 Enterprise IoT LTSC 2021 (v21H2, build 19044.xxxx). That being said though, I don't think even that should be causing this issue, as in this video, the guy is also using the same version that I'm using and his game seems to be running just fine.

Edit: I will try out the most recent version that was available at the time this video was published, and see if that makes a difference.

Edit 2: I tried out the most recent version that was available at the time when the video was published, and I have a lot of thoughts, but firstly, I want to say that the screen shaking/flickering problem, during the gameplay, seems to have resolved somehow independent of the dxvk version change, and I don't exactly know why. But there's still some excessive flickering going on while in the game, which looks to be more like some giant texture flickering than the entire screen shaking. I'll make a separate comment to note out and maybe record all my observations.

I can't upload my video on this issue/thread. It is telling me:-
Failed to upload "dxvk v2_2.mp4"
What could be the issue here?

Please check out the following links for attached videos:-

Here's the game with DXVK v2.2 (which is the most recent version that was available at the time when the aforementioned video was published: https://drive.google.com/file/d/1NbHvISr1lsaAe0jVKIf9Z0vsh0BBc-fC/view?usp=sharing

Here's the game with latest version of DXVK v2.5.3: https://drive.google.com/file/d/1ViRI13-Sp_ecIDBNYwDdfx3I3kCBS1V-/view?usp=sharing

As you can see, while this problem still persisted in the older version of DXVK, at least on my system, it is much worse in the latest version.

Assassin's Creed 2.

Observing the problem individually when the camera starts bouncing--Yes, it is some kind of input issue with DXVK vs this game. But the funniest thing about this is--completely getting the game rid of inputs doesn't work, at all.
I managed(if only briefly since this game is finicky to get working with dxvk) to get Special K working with dxvk x dxgi interop, and used the Input Management to test this out.
Videos down below.
https://drive.google.com/file/d/1tgyq2Pg0o2fQAiV0l0OgUTqVbv-sBVJM/view?usp=sharing
https://drive.google.com/file/d/19pWPCrQZxLbonoPK0qZHUaua_AqS8Cv_/view?usp=sharing

EDIT:
...Might not actually be a input bug. I don't know. It's very confusing so far.

@Dhruv-cli That water problem has nothing to do with this issue here. Please open a separate issue.

I'm sorry about that, but this is actually more of a problem with my video showcase. I didn't showcase it correctly, it would start shaking the screen heavily when I go in a close-corner area or do any of the naval missions in the game. I did however showcase that, in the earlier version 2.2, the main menu wasn't shaking but in the newer version, even the main menu is shaking heavily.

I played around with this again. I tried Assassin's Creed 2 in particular (because I still had that installed).

It still works perfectly fine with DXVK and despite experimenting with a few things, I simply do not have this bug.

does the version of installed directx 9 matter? and does its installation matter?

I played around with this again. I tried Assassin's Creed 2 in particular (because I still had that installed).

It still works perfectly fine with DXVK and despite experimenting with a few things, I simply do not have this bug.

What's your Windows version? Also, it might be useful to look at what other software is installed on your system as it might be causing this glitch on other people's systems, including mine. Since Wine in Linux emulates a barebones version of Windows, it really does raise the question of what component is causing this. Perhaps a VS redistributable package?

I didn't use Windows. I tried it on Linux.

Lmao. It obviously doesn't have that issue on Linux!

We are talking about Windows. This issue has only crept up on Windows afaik.

If it is useful at all in any way, I did check out AC3 Remastered, and that game doesn't seem to have any of these screen shaking problems, at least on my PC.

@Dhruv-cli That water problem has nothing to do with this issue here. Please open a separate issue.

I'm sorry about that, but this is actually more of a problem with my video showcase. I didn't showcase it correctly, it would start shaking the screen heavily when I go in a close-corner area or do any of the naval missions in the game. I did however showcase that, in the earlier version 2.2, the main menu wasn't shaking but in the newer version, even the main menu is shaking heavily.

What makes this even more crazy is that it also happens with Assassin's Creed 3 which unlike AC2 - Revelations uses D3D11, so there's a lot of code that's different compared to whats executed when you run the earlier games with DXVK. It just shares the lower levels of DXVK and bugs there wouldn't lead to problems like this one.

So, after reading this topic, I have reproduced the issue in "Revelations" addon and also even in Assassin's Creed 3 (and I guess that "Brotherhood" addon could be in this list too, did not tried it).
Obviously, this bug caused by Ubisoft engine (at least on Windows and in several their games), independent of the render type or DXVK version.

BTW, I noticed several funny features of the bug: when Ezio beats peaceful people with fists, the camera gets INSANE shaking for a moment! It is as if a shake multiplier is being triggered. Thereby, I guess, it's something related to camera effects.
One more notice it's the interface of AC2 with DXVK enabled. All its elements stay flat, but only radar icons are trembling. WTF!?
At last, I'm also using ReShade addon that is running and working well in all of these games, without any similar problems. It also runs with DXVK altogether and shows almost all depth buffers with the same trembling.

So, If my guess is true, the solution of this issue could be disabling/adjusting camera effects in the game engine. But how we can do it? Maybe somewhere exists a mod with useful tweaks for AC series...

What makes this even more crazy is that it also happens with Assassin's Creed 3 which unlike AC2 - Revelations uses D3D11, so there's a lot of code that's different compared to whats executed when you run the earlier games with DXVK. It just shares the lower levels of DXVK and bugs there wouldn't lead to problems like this one.

So, after reading this topic, I have reproduced the issue in "Revelations" addon and also even in Assassin's Creed 3 (and I guess that "Brotherhood" addon could be in this list too, did not tried it). Obviously, this bug caused by Ubisoft engine (at least on Windows and in several their games), independent of the render type or DXVK version.

BTW, I noticed several funny features of the bug: when Ezio beats peaceful people with fists, the camera gets INSANE shaking for a moment! It is as if a shake multiplier is being triggered. Thereby, I guess, it's something related to camera effects. One more notice it's the interface of AC2 with DXVK enabled. All its elements stay flat, but only radar icons are trembling. WTF!? At last, I'm also using ReShade addon that is running and working well in all of these games, without any similar problems. It also runs with DXVK altogether and shows almost all depth buffers with the same trembling.

So, If my guess is true, the solution of this issue could be disabling/adjusting camera effects in the game engine. But how we can do it? Maybe somewhere exists a mod with useful tweaks for AC series...

Good to know that its Games Engine problem and not any other issue hopefully.
Would you like to try some renowned forks of DXVk to see of those works properly. On the other hand they are based on the dxvk so don't know for sure.

• https://gitlab.com/Ph42oN/dxvk-gplasync/-/releases (Use case when Official dxvk stutters)

Lagacy DXVK (For old Gpu's)

• https://github.com/pythonlover02/DXVK-Sarek/releases
• https://github.com/doitsujin/dxvk/tree/v1.10.3
• https://github.com/Sporif/dxvk-async/tree/1.10.3

DXVK.conf lines
d3d9.maxFrameLatency = 1
d3d9.presentInterval = 1
d3d9.numBackBuffers = 3

DXVK.conf lines (if using DXVK gplasnyc or async)
dxvk.enableAsync = true
dxvk.gplAsyncCache = true

DXVK.conf lines (Might speed up shader compilation)
dxvk.numAsyncThreads = 4
dxvk.numCompilerThreads = 4

I can confirm the issue still persists on AC Brotherhood I installed yesterday. Even the main Title Screen shakes where you have to press enter. Would be nice if it gets fixed.

Is it confirmed ? I think its something else as it happens on the title screen where you see AC Brotherhood. So it has to be some other bug.

Is it confirmed ? I think its something else as it happens on the title screen where you see AC Brotherhood. So it has to be some other bug.

Mate, don't bother dxvk developers. Better ask ubi what happens with camera.

I guess better play with dx9 as game is old and ubi is not the same we used to know

Hmm. Was this always a bug ? I mean are there any older dxvk versions that work with this game without this bug ?

Hey guys, I'm just adding to this thread. I also tried using DXVK for AC Brotherhood and I also have the exact same camera flickering issue. And it's already visible in the main menu as someone mentioned.

I think I found the root cause of this one, at least for Assassin's Creed 2 on Windows + Nvidia.

TL;DR: IDirect3D9::CreateDevice returns to the application thread with MXCSR changed from 0x1F80 to 0x7FA0 (SSE rounding mode switched to round-toward-zero). It is leaked by the Vulkan driver during device creation. DXVK preserves only the x87 control word (D3DCREATE_FPU_PRESERVE / SetupFPU), never MXCSR, and native D3D9 never touches MXCSR. The game's engine keeps computing camera/physics/HUD math with truncation on that thread, which gives the shake. Saving/restoring MXCSR around CreateDeviceEx, Reset and ResetEx fixes it for me.

Environment

• Assassin's Creed II (AssassinsCreedIIGame.exe, 32-bit D3D9), exclusive fullscreen 2560x1440@165, VSync on
• RTX 5080, Nvidia driver 595.71, Windows 11 26200 (AMD iGPU ICD also present — excluding it via VK_LOADER_DRIVERS_SELECT changed nothing)
• DXVK 2.6.2, 2.7.1 and 3.1.1 all affected; native D3D9 is fine

Symptoms: constant camera micro-shake with zero input, distant minimap markers trembling while near ones don't (small angular error in CPU-side math), and occasional single frames rendered from a completely different viewpoint.

Evidence

A d3d9 proxy that wraps every method of the device, textures, surfaces, buffers, queries, swapchain and state blocks, comparing MXCSR/x87 CW before and after each call, logged exactly one change in the whole session:

CreateDevice hr=0x00000000 flags=0x46 MXCSR 1f80->7fa0 CW 0e7f->0e7f

(0x46 = FPU_PRESERVE | MULTITHREADED | HARDWARE_VERTEXPROCESSING, so SetupFPU doesn't run; x87 CW is untouched, only MXCSR rounding bits go 00 → 11. Direct3DCreate9 itself doesn't change it.)

Per-thread snapshots (suspend + Wow64GetThreadContext, 150 samples 30 ms apart, game threads only):

The game creates the device on one of its job-system workers (the same thread it pinned to CPU 0 via SetThreadAffinityMask(…, 0x1)), so that worker keeps round-toward-zero forever. Jobs land on whichever worker is free, so the same camera/physics job is sometimes computed with truncation and sometimes not — frame-to-frame back-and-forth. (That last part is inferred from the data, I didn't trace individual jobs.)

This also explains why it's Windows-only (Linux drivers don't leak the mode), why apitraces captured on Windows "bake in" the bug (the game computes wrong matrices on the CPU), and why it's hard to reproduce (depends on the thread doing device creation and on job scheduling).

Fix

An RAII guard saves MXCSR on entry and restores its control bits on exit (keeping sticky flags); it also restores the x87 CW, but only under D3DCREATE_FPU_PRESERVE. It's placed around D3D9InterfaceEx::CreateDeviceEx, D3D9DeviceEx::Reset and D3D9DeviceEx::ResetEx, and logs a warning when it has to restore. With it, the log shows warn: D3D9: Restoring MXCSR changed by the driver: 7fa0 -> 1fa0 once at startup, all game threads are back to 1Fxx (matching native), and the shake is gone.

Separate game bug (crash on minimize)

Unrelated to the shake: minimizing the fullscreen game crashes it because it sizes render targets from GetWindowRect, which returns the parking rect (-32000,-32000,-31763,-31961) → Cannot create texture ... Extent: 4294935533x4294935335. deviceLossOnFocusLoss = False doesn't help. My patch also adds an opt-in d3d9.fixMinimizedWindowRect (IAT hook of user32!GetWindowRect returning the last real rect for parked/iconic windows), enabled via app profile for AssassinsCreedIIGame.exe and AC(B|R)SP.exe. That part is a game workaround and can be dropped/split if an import hook isn't wanted in DXVK.

Open questions

• Which exact Vulkan call leaks — createDevice() (vkCreateDevice) or swapchain/surface creation in InitialReset. Bisecting would allow a precise report to Nvidia.
• Only tested Nvidia 595.71; there are AMD reports in this thread too, so the AMD Windows driver may do the same.
• AC3 (D3D11) is mentioned here as well — the same guard around D3D11 device / DXGI swapchain creation is probably needed (this patch covers D3D9 only). Guarding in DxvkAdapter::createDevice itself might be more robust.

Investigation and patch were done with the help of an AI assistant (Claude); I tested the result on my machine.

diff --git a/src/d3d9/d3d9_device.cpp b/src/d3d9/d3d9_device.cpp
index 9b72bb2..99ef7b2 100644
--- a/src/d3d9/d3d9_device.cpp
+++ b/src/d3d9/d3d9_device.cpp
@@ -447,6 +447,7 @@ namespace dxvk {
 
   HRESULT STDMETHODCALLTYPE D3D9DeviceEx::Reset(D3DPRESENT_PARAMETERS* pPresentationParameters) {
     D3D9DeviceLock lock = LockDevice();
+    D3D9FpuStateGuard fpuGuard(m_behaviorFlags & D3DCREATE_FPU_PRESERVE);
 
     Logger::info("Device reset");
     m_deviceLostState = D3D9DeviceLostState::Ok;
@@ -4486,6 +4487,7 @@ namespace dxvk {
           D3DPRESENT_PARAMETERS* pPresentationParameters,
           D3DDISPLAYMODEEX*      pFullscreenDisplayMode) {
     D3D9DeviceLock lock = LockDevice();
+    D3D9FpuStateGuard fpuGuard(m_behaviorFlags & D3DCREATE_FPU_PRESERVE);
 
     HRESULT hr;
     if (likely(m_deviceType != D3DDEVTYPE_NULLREF)) {
diff --git a/src/d3d9/d3d9_interface.cpp b/src/d3d9/d3d9_interface.cpp
index 119dfa4..aeb80da 100644
--- a/src/d3d9/d3d9_interface.cpp
+++ b/src/d3d9/d3d9_interface.cpp
@@ -73,6 +73,9 @@ namespace dxvk {
     }
 #endif
 
+    if (m_d3d9Options.fixMinimizedWindowRect)
+      HookMinimizedWindowRect();
+
     if (bExtended) {
       m_d3dCompatibility.set(D3DCompatibility::D3D9Ex);
       Logger::info("The D3D9 interface is operating in D3D9Ex mode.");
@@ -368,6 +371,8 @@ namespace dxvk {
           D3DPRESENT_PARAMETERS* pPresentationParameters,
           D3DDISPLAYMODEEX*      pFullscreenDisplayMode,
           IDirect3DDevice9Ex**   ppReturnedDeviceInterface) {
+    D3D9FpuStateGuard fpuGuard(BehaviorFlags & D3DCREATE_FPU_PRESERVE);
+
     InitReturnPtr(ppReturnedDeviceInterface);
 
     if (unlikely(ppReturnedDeviceInterface  == nullptr
diff --git a/src/d3d9/d3d9_options.cpp b/src/d3d9/d3d9_options.cpp
index e46864e..ac99ae5 100644
--- a/src/d3d9/d3d9_options.cpp
+++ b/src/d3d9/d3d9_options.cpp
@@ -72,6 +72,7 @@ namespace dxvk {
     this->seamlessCubes                 = config.getOption<bool>        ("d3d9.seamlessCubes",                 false);
     this->textureMemory                 = config.getOption<int32_t>     ("d3d9.textureMemory",                 100) << 20;
     this->deviceLossOnFocusLoss         = config.getOption<bool>        ("d3d9.deviceLossOnFocusLoss",         false);
+    this->fixMinimizedWindowRect        = config.getOption<bool>        ("d3d9.fixMinimizedWindowRect",        false);
     this->samplerLodBias                = config.getOption<float>       ("d3d9.samplerLodBias",                0.0f);
     this->clampNegativeLodBias          = config.getOption<bool>        ("d3d9.clampNegativeLodBias",          false);
     this->countLosableResources         = config.getOption<bool>        ("d3d9.countLosableResources",         true);
diff --git a/src/d3d9/d3d9_options.h b/src/d3d9/d3d9_options.h
index e69a39a..708b2c7 100644
--- a/src/d3d9/d3d9_options.h
+++ b/src/d3d9/d3d9_options.h
@@ -159,6 +159,9 @@ namespace dxvk {
     /// Enable emulation of device loss when a fullscreen app loses focus
     bool deviceLossOnFocusLoss;
 
+    /// Report the last real window rect instead of the minimized parking rect
+    bool fixMinimizedWindowRect;
+
     /// Disable counting losable resources and rejecting calls to Reset() if any are still alive
     bool countLosableResources;
 
diff --git a/src/d3d9/d3d9_util.cpp b/src/d3d9/d3d9_util.cpp
index 037b9d4..9e900ee 100644
--- a/src/d3d9/d3d9_util.cpp
+++ b/src/d3d9/d3d9_util.cpp
@@ -2,8 +2,121 @@
 
 #include "../util/util_win32_compat.h"
 
+#if (defined(__i386__) || (defined(__x86_64__) && !defined(__arm64ec__)) || defined(_M_IX86) || (defined(_M_X64) && !defined(_M_ARM64EC)))
+#define DXVK_D3D9_X86_FPU_STATE
+#include <xmmintrin.h>
+#endif
+
 namespace dxvk {
 
+  D3D9FpuStateGuard::D3D9FpuStateGuard(bool preserveX87)
+  : m_preserveX87(preserveX87) {
+#ifdef DXVK_D3D9_X86_FPU_STATE
+    m_mxcsr = _mm_getcsr();
+#if defined(__GNUC__)
+    if (m_preserveX87)
+      __asm__ __volatile__("fnstcw %0" : "=m" (m_x87Control));
+#endif
+#endif
+  }
+
+
+  D3D9FpuStateGuard::~D3D9FpuStateGuard() {
+#ifdef DXVK_D3D9_X86_FPU_STATE
+    uint32_t mxcsr = _mm_getcsr();
+
+    // Only compare and restore the control bits, keep the sticky exception flags
+    constexpr uint32_t MxcsrControlMask = ~0x3Fu;
+
+    if ((mxcsr ^ m_mxcsr) & MxcsrControlMask) {
+      Logger::warn(str::format("D3D9: Restoring MXCSR changed by the driver: ",
+        std::hex, mxcsr, " -> ", m_mxcsr));
+      _mm_setcsr((m_mxcsr & MxcsrControlMask) | (mxcsr & ~MxcsrControlMask));
+    }
+
+#if defined(__GNUC__)
+    if (m_preserveX87) {
+      uint16_t control;
+      __asm__ __volatile__("fnstcw %0" : "=m" (control));
+
+      if (control != m_x87Control)
+        __asm__ __volatile__("fldcw %0" : : "m" (m_x87Control));
+    }
+#endif
+#endif
+  }
+
+
+#ifdef _WIN32
+  static BOOL (WINAPI* g_origGetWindowRect)(HWND, LPRECT) = nullptr;
+  static HWND g_lastRectWindow = nullptr;
+  static RECT g_lastRect = { };
+
+  static BOOL WINAPI HookedGetWindowRect(HWND hWnd, LPRECT pRect) {
+    BOOL result = g_origGetWindowRect(hWnd, pRect);
+
+    if (!result || !pRect)
+      return result;
+
+    // Minimized windows are parked around (-32000, -32000). This also
+    // catches the transition while the window is being restored.
+    if (::IsIconic(hWnd) || pRect->left <= -30000 || pRect->top <= -30000) {
+      if (hWnd == g_lastRectWindow)
+        *pRect = g_lastRect;
+      else
+        ::SetRect(pRect, 0, 0, ::GetSystemMetrics(SM_CXSCREEN), ::GetSystemMetrics(SM_CYSCREEN));
+      return TRUE;
+    }
+
+    g_lastRectWindow = hWnd;
+    g_lastRect = *pRect;
+    return result;
+  }
+#endif
+
+
+  void HookMinimizedWindowRect() {
+#ifdef _WIN32
+    if (g_origGetWindowRect)
+      return;
+
+    auto* base = reinterpret_cast<uint8_t*>(::GetModuleHandleW(nullptr));
+    auto* dos  = reinterpret_cast<const IMAGE_DOS_HEADER*>(base);
+    auto* nt   = reinterpret_cast<const IMAGE_NT_HEADERS*>(base + dos->e_lfanew);
+    auto& dir  = nt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT];
+
+    if (!dir.VirtualAddress)
+      return;
+
+    for (auto* imp = reinterpret_cast<const IMAGE_IMPORT_DESCRIPTOR*>(base + dir.VirtualAddress); imp->Name; imp++) {
+      if (_stricmp(reinterpret_cast<const char*>(base + imp->Name), "user32.dll"))
+        continue;
+
+      auto* names = reinterpret_cast<const IMAGE_THUNK_DATA*>(base + imp->OriginalFirstThunk);
+      auto* addrs = reinterpret_cast<IMAGE_THUNK_DATA*>(base + imp->FirstThunk);
+
+      for (; imp->OriginalFirstThunk && names->u1.AddressOfData; names++, addrs++) {
+        if (IMAGE_SNAP_BY_ORDINAL(names->u1.Ordinal))
+          continue;
+
+        auto* name = reinterpret_cast<const IMAGE_IMPORT_BY_NAME*>(base + names->u1.AddressOfData);
+
+        if (strcmp(reinterpret_cast<const char*>(name->Name), "GetWindowRect"))
+          continue;
+
+        DWORD oldProtect;
+        ::VirtualProtect(&addrs->u1.Function, sizeof(addrs->u1.Function), PAGE_READWRITE, &oldProtect);
+        g_origGetWindowRect = reinterpret_cast<decltype(g_origGetWindowRect)>(addrs->u1.Function);
+        addrs->u1.Function = reinterpret_cast<decltype(addrs->u1.Function)>(&HookedGetWindowRect);
+        ::VirtualProtect(&addrs->u1.Function, sizeof(addrs->u1.Function), oldProtect, &oldProtect);
+
+        Logger::info("D3D9: Hooked GetWindowRect to hide minimized window parking rect");
+        return;
+      }
+    }
+#endif
+  }
+
   typedef HRESULT (STDMETHODCALLTYPE *D3DXDisassembleShader) (
     const void*      pShader, 
           BOOL       EnableColorCode, 
diff --git a/src/d3d9/d3d9_util.h b/src/d3d9/d3d9_util.h
index c9cc2d9..f3a0743 100644
--- a/src/d3d9/d3d9_util.h
+++ b/src/d3d9/d3d9_util.h
@@ -302,6 +302,46 @@ namespace dxvk {
     return D3D9TextureStageStateTypes(Type - 1);
   }
 
+  /**
+   * \brief Preserves the calling thread's floating point state
+   *
+   * Some Vulkan drivers (observed with Nvidia on Windows) change the SSE
+   * rounding mode in MXCSR while creating a device or swapchain and never
+   * restore it, so the application thread keeps running with round-toward-zero.
+   * Native D3D9 never touches MXCSR, and games that depend on the default
+   * rounding break in subtle ways (e.g. the camera shake in Assassin's Creed 2).
+   * The x87 control word is restored only if the application asked for it
+   * via D3DCREATE_FPU_PRESERVE, since D3D9 otherwise sets it up on purpose.
+   */
+  class D3D9FpuStateGuard {
+
+  public:
+
+    explicit D3D9FpuStateGuard(bool preserveX87);
+
+    ~D3D9FpuStateGuard();
+
+    D3D9FpuStateGuard             (const D3D9FpuStateGuard&) = delete;
+    D3D9FpuStateGuard& operator = (const D3D9FpuStateGuard&) = delete;
+
+  private:
+
+    bool      m_preserveX87 = false;
+    uint32_t  m_mxcsr       = 0;
+    uint16_t  m_x87Control  = 0;
+
+  };
+
+  /**
+   * \brief Hides the parking rect of minimized windows from the application
+   *
+   * Some games size their render targets from GetWindowRect, which returns
+   * the (-32000, -32000) parking position while the window is minimized,
+   * and then fail to create absurdly sized textures and crash. Hooks the
+   * executable's GetWindowRect import to report the last real rect instead.
+   */
+  void HookMinimizedWindowRect();
+
 }
 
 
diff --git a/src/util/config/config.cpp b/src/util/config/config.cpp
index 2b7ced4..783a962 100644
--- a/src/util/config/config.cpp
+++ b/src/util/config/config.cpp
@@ -900,9 +900,17 @@ namespace dxvk {
       { "d3d9.cachedWriteOnlyBuffers",      "True" },
     }} },
     /* Assassin's Creed 2                         *
-     * Helps alt tab crash on Linux               */
+     * Helps alt tab crash on Linux               *
+     * Crashes when minimized: sizes render       *
+     * targets from the window's parking rect     */
     { R"(\\AssassinsCreedIIGame\.exe$)" , {{
       { "d3d9.deviceLossOnFocusLoss",       "True" },
+      { "d3d9.fixMinimizedWindowRect",      "True" },
+    }} },
+    /* Assassin's Creed Brotherhood, Revelations  *
+     * Same engine as Assassin's Creed 2          */
+    { R"(\\AC(B|R)SP\.exe$)" , {{
+      { "d3d9.fixMinimizedWindowRect",      "True" },
     }} },
     /* Sonic CD                                   */
     { R"(\\soniccd\.exe$)", {{

I think I found the root cause of this one, at least for Assassin's Creed 2 on Windows + Nvidia.

I tried your patch and have attached two videos below. The first shows AC2 running on standard DXVK 3.1.1. The second shows AC2 with iwalker2005's patch for DXVK 3.1.1.

My setup uses an Nvidia GTX 1050 (laptop version). In my case, the patch helped.

@iwalker2005, низкий поклон

https://github.com/user-attachments/assets/ba415301-211b-4f4c-969d-e0b1cb38b4c0

https://github.com/user-attachments/assets/c12b266f-db8f-46ff-9472-39376bc09d67

Please someone also test this with Brotherhood and Revelations. On my end at least, Brotherhood does not seem to work, it still flickers.

I found that Assassin’s Creed Brotherhood needs a slightly more aggressive version of the MXCSR workaround than Assassin’s Creed II.

In AC2, the problem was that the Vulkan/NVIDIA path used during D3D9 device creation changed the calling thread’s MXCSR from the normal round-to-nearest mode to round-toward-zero and did not restore it. The original fix was therefore to save/restore MXCSR around CreateDeviceEx, Reset, and ResetEx. The original patch observed values such as 0x1F80 -> 0x7FA0, where the rounding-control bits changed from 00 (round-to-nearest) to 11 (round-toward-zero). Pasted text

That fix works for AC2, but in Brotherhood I still had visible camera twitching/flickering even though the initial device-creation leak was being restored correctly.

The diagnostic log confirmed that Brotherhood entered device creation with a normal MXCSR value, the driver changed it to 0x7FA0, and the existing guard restored it to 0x1FA0: ACBSP_d3d9

However, the camera twitch remained. The workaround that fixed Brotherhood was to additionally sanitize the MXCSR rounding-control bits at important D3D9 frame boundaries:

BeginScene
EndScene
PresentEx entry
PresentEx exit

At each of these points I read MXCSR with _mm_getcsr(), check the rounding-control bits, and if they are not round-to-nearest, clear them before continuing.

The important part is to change only the MXCSR rounding-mode bits rather than replacing the whole register, so exception masks, denormal handling, and sticky exception flags are left untouched.

Conceptually:

static void SanitizeMxcsr(const char* where) {
#if defined(DXVK_D3D9_X86_FPU_STATE)
 uint32_t mxcsr = _mm_getcsr();

  // MXCSR bits 13-14 = rounding control:
  // 00 = nearest
  // 01 = down
  // 10 = up
  // 11 = toward zero
  constexpr uint32_t RoundingMask = 0x6000;

  if (mxcsr & RoundingMask) {
    uint32_t fixed = mxcsr & ~RoundingMask;

    Logger::warn(str::format(
      "D3D9: ", where,
      " restoring MXCSR round-to-nearest: ",
     std::hex, mxcsr, " -> ", fixed));

   _mm_setcsr(fixed);
  }
#endif
}

Then call it around the frame API entry points, for example:

HRESULT STDMETHODCALLTYPE D3D9DeviceEx::BeginScene() {
  SanitizeMxcsr("BeginScene");
  ...
}

HRESULT STDMETHODCALLTYPE D3D9DeviceEx::EndScene() {
  SanitizeMxcsr("EndScene");
  ...
}

HRESULT STDMETHODCALLTYPE D3D9DeviceEx::PresentEx(...) {
  SanitizeMxcsr("PresentEx entry");

  HRESULT hr = ...;

  SanitizeMxcsr("PresentEx exit");
  return hr;
}

I kept the original RAII guard around device creation/reset as well:

D3D9FpuStateGuard fpuGuard(
  BehaviorFlags & D3DCREATE_FPU_PRESERVE);

and similarly in Reset / ResetEx. The original guard preserves the control portion of MXCSR while retaining sticky exception flags, and only restores x87 state when D3DCREATE_FPU_PRESERVE was requested. Pasted text

With only the device-creation guard, Brotherhood still had camera twitching. With the additional per-frame MXCSR sanitation at BeginScene, EndScene, and PresentEx, the twitch disappeared completely.

So the practical difference seems to be:

• AC2: restoring MXCSR after D3D9/Vulkan device creation/reset is sufficient.
• Brotherhood: something later in the frame/game execution path can leave the thread with a non-default MXCSR rounding mode, so sanitizing at frame boundaries is also required.

I would probably not make this behavior unconditional for every D3D9 application without more investigation. A game/profile-specific workaround for ACBSP.exe, or a more targeted diagnosis of exactly which call changes MXCSR after startup, would be safer.

There was also a separate Brotherhood fullscreen/DSR issue. When using 3840×2160 DSR on a 1920×1080 display, d3d9.deviceLossOnFocusLoss = True caused problems during the fullscreen mode transition. Setting:

d3d9.deviceLossOnFocusLoss = False

allowed Brotherhood to correctly reach a 3840×2160 window, client area, backbuffer, and Vulkan swapchain. The diagnostic log showed all of them at 3840×2160 after that change. ACBSP_d3d9

The DSR/focus-loss workaround and the MXCSR camera-twitch workaround are separate issues.

@missingnoXXVI here's a prebuilt one if you want to test without building: https://github.com/iwalker2005/dxvk/releases/tag/ac-mxcsr-fix-2026-10-04

It's K0bin's mxcsr-better branch (current master) plus two things on top, both only enabled for AC2 / Brotherhood / Revelations via app profile:

• MXCSR rounding reset to round-to-nearest at BeginScene / EndScene / PresentEx (what @valentyn-l found Brotherhood needs)
• a workaround for the AC2 crash on minimize (the game sizes its render targets from the minimized window's parking rect)

These games are 32-bit, so just copy x32\d3d9.dll next to the game exe. Tested on an RTX 5080 with driver 617.14, AC2 and Brotherhood: no shake. Unofficial build, not from the DXVK devs.

@missingnoXXVI here's a prebuilt one if you want to test without building: https://github.com/iwalker2005/dxvk/releases/tag/ac-mxcsr-fix-2026-10-04

It's K0bin's mxcsr-better branch (current master) plus two things on top, both only enabled for AC2 / Brotherhood / Revelations via app profile:

• MXCSR rounding reset to round-to-nearest at BeginScene / EndScene / PresentEx (what @valentyn-l found Brotherhood needs)
• a workaround for the AC2 crash on minimize (the game sizes its render targets from the minimized window's parking rect)

These games are 32-bit, so just copy x32\d3d9.dll next to the game exe. Tested on an RTX 5080 with driver 617.14, AC2 and Brotherhood: no shake. Unofficial build, not from the DXVK devs.

Yeah, I have been using DXVK for awhile, just not particularly skilled in the building department. Just tested this across AC2, Brotherhood, and Revelations and it gets a thumbs up across the board. Even works with Kamzik's performance and functionality tweakers without complaint. I will be keeping it around for my eventual next playthroughs of those particular AC titles until something similar or better can be merged in with an official release without causing trouble. Many thanks for aiming this in the right direction after such a long time for Windows. I'm curious if it will solve the issue for those with NVIDIA cards who have had this problem by default even without DXVK.

https://github.com/user-attachments/assets/e047279f-6192-4f34-860d-8ee5167ed50c

I still encounter a less worse version of the issue by default on ACIII compared to AC2, Brotherhood, and Revelations. It seems to go away shortly after for unknown reasons. Using regular DXVK however still kicks the issue back into overdrive.