DgVoodoo Crashing FFXI

The problem most of us with 10x0 mobile and optimus cards happens after we get into the game. With UAC all the way off no difference. Log in is fine, character select is fine, once you load you freeze, however you can often times see your still moving if you are dboxing and watching the unfrozen instance and moving the controller on the frozen instance.
I tried almost every combination possible in the client and wasnt able to get it to work unfortunately. The ashita wrapper does work.

That doesn't work and won't work.

The problem with Windows 10 and Optimus is that DX8 code isn't put on the same pipeline as DX11/12 code and often wont' be assigned to the high performance GPU. You can go into nVidia graphics control panel and assign the exe to high performance and it still won't take. All dgVodoo2 is doing is translating the DX8 code into DX11 code which is then detected and treated like any other DX11 application, including assigning it to the high performance GPU.

Have you tested it? You may well be right but you can't conclude Microsoft's implementation won't work just because Nvidia's doesn't.

Yes I have and yes I can. There is no MS implementation vs nVidia implementation, they are the exact same thing.

In a very general context we have this

Program -> Direct X API / Pileline -> Vendor API Drivers -> HW Drivers -> Hardware

The problem here isn't the Vendor API / Drivers, it's the Direct X API level and how the newer versions of Windows treat it. FFXI is DX8.1 code, DX8 doesn't exist on Windows Vista and higher, instead they support DX9 which in turn emulates functionality of older Direct X versions. Microsoft stopped caring a whole lot about that emulation layer other then "it mostly works" and so older DX applications have various compatibility problems in newer versions of Windows.

Now in the case of FFXI what's happening is the DX9 emulation layer is pegging the legacy DX8 application to Device0 for it's rendering target. Device0 is the first graphics adapter present when the system starts and is where the display defaults to unless told otherwise. Traditionally the vast majority of consumer PC's had a single graphics device, even multi-GPU systems had those GPU's working together as a single device. If you want to see a list of available adapters just click the drop down "Adapter's to use" on dgVoodoo, notice the Intel iGPU is the first on that list, Device0.

Now by default all applications are assigned to Device0 unless something tells them otherwise. Optimus is just a technology that attempts to sense if an application is using a lot of 3D resources and assign it to Device1 but since FFXI is being pegged to Device0 it won't migrate. DgVoodoo is presenting FFXI as a DX11 instance to the system which is bypassing the MS emulation layer and being treated the same as any other DX11 instance and being assigned to Device1.

Sorry for the long complex explanation, trying to describe whats going on without diving too deep into the weeds. I've actually been successful in getting FFXI to work on my nVidia GPU without dgVoodoo2 but that involved a lot of hacking around with things people shouldn't be hacking around in.

While the theory is nice, it's the evidence that's important.

It sounds like you are saying you tested the Microsoft method and it resulted in FFXI still running on the wrong GPU, correct?

Umm... you don't read so well.
Pol.exe isn't FFXI, FFXiMain.dll is. Pol.exe is a DirectDraw application without any 3D rendering and it just instantiates the Playonline lobby. Later after you click play, it launch's FFXiMain.dll which starts up the graphics pipeline and follows the typical process that I outlined above. Now bootstrapping a program isn't a new concept, and if FFXIMain.dll makes the right calls it gets assigned to the right GPU, but it doesn't make the right calls and the legacy emulation layer won't make them either.

Again I was able to make it work by hacking around inside Windows, but that's not something people should be doing and wasn't very stable anyway. The DirectX wrapper method is far better and there are several that just go DX8~DX9 which fixes the problem with the surface being selected properly.