If not using SpecialK either SKIF or renaming/removing the local .dll file (DXGI.dll for one possibility.) and the problem still persists it may work to just rename graphics_option.ini in the game folder.

Or you open it and change to windowed, lower resolution and D3D12 disabled and see if that helps. :)

[GraphicsOption]
ScreenMode=Windowed
Resolution=1920x1080
DirectX12Enable=Off


EDIT: Effectively there's some compatibility work and settings in SpecialK for having the game start up in D3D12 mode so ensuring that is disabled for the DXGI overrides in SpecialK not to cause any problems is important here as SpecialK's DirectX 12 support is still limited. :)

Lowering the resolution and using borderless or windowed isn't as important, mostly helps if the display res is unsupported but then it should normally go back to something lower or reset. :)



EDIT: Also don't change graphics_option_preset.ini that's what the game has for it's defaults.

So either SKIF or the local .dll file version which usually would be DXGI.dll in the game folder to remove SpecialK (Or rename DXGI.ini if that's there to reset SpecialK settings.) if that doesn't work and you're certain SpecialK isn't running (Possibly even rebooting to ensure it's not loaded.) then renaming or checking the games config file could help if anything is misconfigured.


For SpecialK compatibility itself unless the games latest update made things problematic in some other way it should just be that DirectX 12 support is still only partial at best and for these DXGI overrides through SpecialK you should make sure the games D3D12 support is first disabled.
(Otherwise there's some specific settings that are needed and SpecialK's GUI display won't work though a few other settings will still take effect.)

I would imagine the amount of resources and time you do get is also sometimes problematic plus getting additional resources for patches short of the game having something like a season pass and you get something like DLC -> Patch going for however long that content goes on.

Some of the engine issues and problems around older game engines, coding practices and documentation or source asset availability could also be a hindrance or even communication and if the PC version is given much effort at all though with successes with some of these games that has changed and there's been a lot of improvements to some of these ports even if some studios do have their problems but it might not be for lack of trying.


Wonder if Yakuza 7 will have that memory issue to take one upcoming title or how Koei Tecmo will handle Nioh 2 although it's not on the "Warriors" engine or what's powering the Atelier games.

Bandai Namco and Tales though perhaps the usage of Unreal Engine 4 will help even if it has some issues too and then Platinum and the studio behind the PC version of Nier.


Would be nice with a good port of Trails of Cold Steel 4 and eventually Ys 9 too if Durante and NIS America continue to have a working relationship with some of their PC output even if it's behind the console version release date. (Not that having the extra time is a problem.)

Plus whatever SEGA will do with further Atlus properties someone mentioned Persona 3 but being a even older game that would have other issues and there seems to be various editions of it so I have no idea which one is considered best or if a straight up merge and remake of it all would be something but Atlus JP probably does their own thing for how this works.

I could see some of the newer games being ported if sales are good at least far as SEGA wanting it to happen and maybe making things happen but it also seems the acquisition of Atlus might have also involved having them being more autonomous or how it's called so SEGA isn't pushing them around like other publishers for what to release and on which platforms.

Yeah it's not very common to use it nowadays as many 32-bit applications would likely already be using the LAA flag during compilation but this game for some reason does not yet it is already using pretty large amounts of memory for the default limit from what I am reading so it's nearing the limits as early as when movie playback like the logo or intro videos start playing. :)
(Bit higher and a random crash as whatever it wanted to use could no longer fit in the RAM limits.)

Ran into problems with this in 2006 - 2007 for Stalker which saw GSC patch the game with this so by this point years later I would have expected it to almost be a standard as RAM requirements and overall RAM availability has increased and there's no drawback as it just flips one byte for a flag telling the OS about the program being large address aware and the immediate benefit is being able to use more RAM.
(Almost the double and as can be seen it seems to really help.)


Well the explanation isn't too important, good to see it worked and thankfully it's a pretty easy change that should have no drawbacks at all as it merely flips one byte telling the OS this is large address aware and can use above 2 GB RAM now. :)

FlipDiscard to false I believe.

UseFlipDiscard=false

Possibly this back to zero too and disable waitable swap chain.

SwapChainWait=200



In terms of latency, frame pacing and performance Windows 8 and especially Windows 10 introducing flip model presentation and W10 additionally utilizing flip discard should have a benefit over earlier windowed and borderless mode presentations while matching full-screen exclusive mode.

You can still do full-screen exclusive though and it's not bad although I can't vouch for how this game behaves because the frame rate limiter the game has by default and the vsync the game does both differ a bit under full-screen mode from my understanding but it might be mostly by running into a 120 FPS cap which isn't too bad compared to 60 or at worst 30 for some of these games. :)

The limiter itself might not entirely match the set framerate but a few FPS over or under the target by itself isn't too bad although the frame pacing could be somewhat affected from how this is handled.


EDIT: But yeah the overrides for borderless or centering to false plus disabling flip discard and possibly also disabling the swap chain 200ms wait value should allow for configuring the game back to using full screen exclusive display mode if desired. :)

Did you patch the exe file with the LAA flag for large address awareness?
https://ntcore.com/?page_id=371

Makes the 32-bit app able to draw upon ~3.5 GB instead of 2 GB which should aid in stability going by what Kaldaien mentioned on how the game was already very close to the 2 GB limit to begin with.

Not as good as having it being 64-bit and able to hit 4GB+ but a good improvement until the developers ideally patch the game directly for LAA or provide a 64-bit compiled binary though I find the former more likely and even that is uncertain although as a 1-byte change sort of flag it's trivially easy to do.


Won't interfere with anything either. :)

There's a fairly up to date 0.11 based 64-bit .dll from Kaldaien's post here.
https://gtm.steamproxy.vip/groups/SpecialK_Mods/discussions/1/2254560552290148028/#c2254560552302077863

Could be compatible when compared to the earlier .dll files from SpecialK.
Would be easier if Valve allowed the app as early-access but instead it's a beta with a set of keys through a opt-in of sorts and request based system until the new version is ready for release. :)

https://store.steampowered.com/app/1157970/



EDIT: You'll want a very up to date build for the Atelier games, engine issues and certain quirks can be tricky for compatibility and getting it to perform nice with other utilities, there's fan patches too but they can only do so much.

Copy SpecialK64.new and rename it to dxgi.dll and move that to the game folder.

Should give a Special K 64-bit 0.11.33.0 dll set for local injection.
d3d11.dll or dinput8.dll could also work.

EDIT: Windows being Windows is one reason I usually prefer local injection but global has it's own advantages so you trade drawbacks and strengths a bit and might have to tinker a bit for ideal compatibility such as what gets loaded when. (D3D11 might work better than DXGI or DInput8 but loaded earlier or later in the process of starting up the title so compatibility and certain features might require a certain order for these things and other software also loading in from the OS itself, drivers, third party like the Steam overlay and such.)

Haven't tested it myself though other than a quick go with the Discovery Mode for Origins, will be giving it a better test once I get around to replaying the game but there's Assassin's Creed Syndicate first.

At least it has the most British villain in the series and doesn't try to take itself too seriously for what's going on during the game. (Whether that's intentional or not.) but I'll get around to it eventually.

From what I remember and from what Kaldaien posted back with Assassin's Creed Origins the game is pushing a lot of draw calls and updates plus for NVIDIA it utilizes an additional eight threads for CPU and GPU multi-threading but these have to go somewhere so without being able to scale down the game gets pretty CPU bound at times. :)

AMD's CPU usage varies but this also results in more uneven framerate and Odyssey in particular was almost broken on launch dropping into the teens for FPS during busier parts of the game world which for how much that game is pushing draws and all is pretty frequent.


There was also a issue with Zen and CPU scheduling but Microsoft and the newer Windows 10 updates should have improved how this is handled as should improvements to AMD's power schedule they use for Zen2 processors.

Beyond that the game itself creates a lot of worker threads upwards of I think 16 or so for what available CPU cores are available (Logical and physical with hyper threading on.) it usually isn't too terrible but it is one of the rare more recent games where a quad core can be a bit of a limit for once and it's not just about efficiency or clock speed for the primary core even if that has plenty of things going on too.


Kaldaien probably had more to say and that could have helped if Ubisoft hadn't acted on that whole malware report and just thrown a community ban without verifying those claims though at least this wrapper manages to resolve some issues which seem to work just as well on NVIDIA GPU's kinda proving there's something limiting the game pretty badly.

AMD's lack of D3D11 driver command lists and poorly multi threaded driver situation overall hinders things which NVIDIA resolved with one of their previous driver updates significantly improving DirectX 11 performance which for how these games are pushing multi-threaded rendering means there's a significant performance penalty for AMD and these games.

(And outside of D3D9 which is single threaded having this work as well as it does for NVIDIA too points at a pretty big bottleneck situation of some sort.)



Don't have a full understanding of what the engine is doing, other than pushing way above specs for D3D11 draw calls it seemed like a pretty impressive engine but it has it's issues so hopefully the next game will see these resolved.
(Guess it's incredibly unlikely Ubisoft would patch in Vulkan or D3D12 support much as it could help now that support for these two games is all but over.)



EDIT: Or just using Ghost Recon Breakpoint as a comparison also on a version of the Anvil Next engine and it's Vulkan API update while initially suffering from a memory leak it still gave a hefty 15 - 20% performance uplift plus improvements to CPU and GPU utilization overall.

Lots of text aside yeah Vulkan (Or D3D12) can really help long as the implementation is all good and stable, again it's really impressive (And a bit problematic for what's going on with the game and D3D11 then.) how it even assists on NVIDIA systems too.

There's posts confirming similar results on newer high-end processors as well so it's not just a hardware limit or CPU bottleneck either, Odyssey can be a bit finicky to get stable with DXVK apparently but Origins just seem to work and benefit nicely overall.

Impressive that it works well for NVIDIA too since their D3D11 driver code is pretty good but Origins already pushed the limits of what some of the D3D11 API limitations could deal with and Odyssey goes even further.

Hopefully the upcoming one will be using Vulkan or D3D12 natively and these limits and whatever limits Ubisoft added by their D3D12->D3D11 translation will be gone.
(Pretty certain Vulkan 1.1.x was developed enough to have been able to handle Odyssey while also allowing Windows 7 and Windows 8 compatibility.)


EDIT: Though part of it might be how the game also just all but requires a hexa core CPU or better otherwise the performance becomes pretty wonky especially in some areas like the cities plus you get a bunch of extra threading for how the NVIDIA driver handles command context queues I believe it's called and driver command lines what it was called again which also doesn't scale down for some reason and is just 8 I think it was.

Game itself still needs a lot from the CPU though, impressive how DXVK improves things considering it should have a bit of a CPU overhead but it might be improving average and mins even if max framerate is a tad slower but that's not as bad as lower mins or worse on average framerate plus what it does to smoothness if frame time and such is also good.
(Latency too and all that.)