3Dmigoto now open-source...
  16 / 141    
@Exposed123: I have yet to see a Stack Crawl of the actual crash. Still interested.
@Exposed123: I have yet to see a Stack Crawl of the actual crash. Still interested.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 01/03/2015 10:45 AM   
I followed Helix's suggestion and the following logs was generated: 'Launcher.exe' (Win32): Loaded 'D:\Program Files (x86)\Dragon Age Inquisition DELUXE EDITION\Launcher.exe'. Cannot find or open the PDB file. 'Launcher.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. Cannot find or open the PDB file. 'Launcher.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. Cannot find or open the PDB file. 'Launcher.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. Cannot find or open the PDB file. 'Launcher.exe' (Win32): Loaded 'C:\Windows\System32\msvcr100.dll'. Cannot find or open the PDB file. Application "\??\D:\Program Files (x86)\Dragon Age Inquisition DELUXE EDITION\DragonAgeInquisition.exe" found in cache The program '[3748] DragonAgeInquisition.exe' has exited with code 0 (0x0). Nothing useful that I could see, unfortunately.
I followed Helix's suggestion and the following logs was generated:

'Launcher.exe' (Win32): Loaded 'D:\Program Files (x86)\Dragon Age Inquisition DELUXE EDITION\Launcher.exe'. Cannot find or open the PDB file.
'Launcher.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. Cannot find or open the PDB file.
'Launcher.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. Cannot find or open the PDB file.
'Launcher.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. Cannot find or open the PDB file.
'Launcher.exe' (Win32): Loaded 'C:\Windows\System32\msvcr100.dll'. Cannot find or open the PDB file.
Application "\??\D:\Program Files (x86)\Dragon Age Inquisition DELUXE EDITION\DragonAgeInquisition.exe" found in cache
The program '[3748] DragonAgeInquisition.exe' has exited with code 0 (0x0).

Nothing useful that I could see, unfortunately.

Windows 10, Geforce GTX 1080 x2 (SLI), Haswell Core i7, 8GB DDR3 2133Mhz memory, 65" LG 4k 3DTV

Posted 01/05/2015 03:59 AM   
Yeah, unfortunately, I think that is the game detecting that a debugger is attached and just exiting. I see this on pretty much all games when I launch them directly from VS. I also get a Steam error when launching that way. Try this: add a line to the top of the d3dx.ini file in the Logging section for 'waitfordebugger=1'. That will pause and wait for you to attach VS from a normal launch. Then once it's attached will run normally until the crash. This bypasses the need to launch from VS. I assume you are using Express version? If you have the full version, you can just wait for the crash and use Just In Time debugging to get the Stack Crawl. The Stack Crawl is the key to getting information. Lastly, you can possibly generate a .dump file from the crash, although I'm not exactly clear on how to set this up. If you can generate a dump file, that can be read into VS to determine the Stack Crawl.
Yeah, unfortunately, I think that is the game detecting that a debugger is attached and just exiting. I see this on pretty much all games when I launch them directly from VS. I also get a Steam error when launching that way.

Try this: add a line to the top of the d3dx.ini file in the Logging section for 'waitfordebugger=1'. That will pause and wait for you to attach VS from a normal launch. Then once it's attached will run normally until the crash. This bypasses the need to launch from VS.

I assume you are using Express version? If you have the full version, you can just wait for the crash and use Just In Time debugging to get the Stack Crawl. The Stack Crawl is the key to getting information.

Lastly, you can possibly generate a .dump file from the crash, although I'm not exactly clear on how to set this up. If you can generate a dump file, that can be read into VS to determine the Stack Crawl.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 01/05/2015 08:47 AM   
For anybody interested in trying this on 8.1, have you tried the Windows 7 compatibility mode? I don't think I've heard of anyone trying that with DA:I.
For anybody interested in trying this on 8.1, have you tried the Windows 7 compatibility mode?

I don't think I've heard of anyone trying that with DA:I.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 01/11/2015 12:55 AM   
It just crashes as usual with the compatibility mode.
It just crashes as usual with the compatibility mode.

Posted 01/11/2015 02:41 AM   
[quote="badhomaks1"]It just crashes as usual with the compatibility mode.[/quote] Worth a shot, thanks for letting us know.
badhomaks1 said:It just crashes as usual with the compatibility mode.

Worth a shot, thanks for letting us know.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 01/11/2015 04:52 AM   
How is the ZBufferTexture generated inside 3Dmigoto? t126 I noticed what seems like an override if buffer is broken but not the main path of creation. What I have seen is storing texture hashes and matching against a known hash from the INI. I seem to be missing what happens otherwise. Assassins Creed 3 use t126 a lot. Any idea how 3Dmigoto generates t126? I can't seem to figure it out at the moment. Probably will eventually.
How is the ZBufferTexture generated inside 3Dmigoto?

t126

I noticed what seems like an override if buffer is broken but not the main path of creation.
What I have seen is storing texture hashes and matching against a known hash from the INI.
I seem to be missing what happens otherwise. Assassins Creed 3 use t126 a lot.

Any idea how 3Dmigoto generates t126? I can't seem to figure it out at the moment. Probably will eventually.

Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?

donations: ulfjalmbrant@hotmail.com

Posted 01/15/2015 11:29 PM   
Despite having the InjectedDepthTexture defined in each of the shaders, I don't think the AC3 fix is actually using that. It is not enabled in the d3dx.ini, and the only shader that has any sign that it was used at some point is aaceedcf559b15e0-ps_replace.txt, but it's been commented out. So, if you're looking to port that fix to your own wrapper I think you can just ignore it. I've been playing with this feature a bit recently while trying to find a solution to the mono depth texture in FC4, so I can tell you that if you add something like this: [code]fix_ZRepair_DepthTextureHash=56ec0f474627a0bf[/code] 3Dmigoto will look for any texture set as a shader resource (in the CreateShaderResourceView() call) that matches that hash and will record the view which is injected into shaders in register 126 on PSSetShader() calls. If multiple textures have the same hash (because all their properties match), it will use the most recent one. I've been adding features to 3Dmigoto recently to help identify these hashes through the ShaderUsage.txt - be sure to pull the latest code as I pushed some of this last night. One thing to keep in mind is if the hash matches a resource used as a render target or depth/stencil target it can't be set as a shader resource simultaneously - if you try this in 3Dmigoto you will find it breaks a lot of rendering (you might see flickering or something else will break). Having this enabled in the ini also adds some code to any newly decompiled shader to declare the injected depth register, adds a position semantic to the shader inputs, and adds a bit of boilerplate code to calculate zpos and wpos - these calculations can be altered with some of the other fix_ZRepair_* parameters in the ini, but I haven't looked into how much is achievable with that. From what I can gather reading the code, if you aren't using a texture injected via hash it searches decompiled shaders for a known depth texture (by name) and inserts the same boilerplate code to calculate zpos and wpos from that.
Despite having the InjectedDepthTexture defined in each of the shaders, I don't think the AC3 fix is actually using that. It is not enabled in the d3dx.ini, and the only shader that has any sign that it was used at some point is aaceedcf559b15e0-ps_replace.txt, but it's been commented out.

So, if you're looking to port that fix to your own wrapper I think you can just ignore it.

I've been playing with this feature a bit recently while trying to find a solution to the mono depth texture in FC4, so I can tell you that if you add something like this:
fix_ZRepair_DepthTextureHash=56ec0f474627a0bf

3Dmigoto will look for any texture set as a shader resource (in the CreateShaderResourceView() call) that matches that hash and will record the view which is injected into shaders in register 126 on PSSetShader() calls. If multiple textures have the same hash (because all their properties match), it will use the most recent one.

I've been adding features to 3Dmigoto recently to help identify these hashes through the ShaderUsage.txt - be sure to pull the latest code as I pushed some of this last night.

One thing to keep in mind is if the hash matches a resource used as a render target or depth/stencil target it can't be set as a shader resource simultaneously - if you try this in 3Dmigoto you will find it breaks a lot of rendering (you might see flickering or something else will break).

Having this enabled in the ini also adds some code to any newly decompiled shader to declare the injected depth register, adds a position semantic to the shader inputs, and adds a bit of boilerplate code to calculate zpos and wpos - these calculations can be altered with some of the other fix_ZRepair_* parameters in the ini, but I haven't looked into how much is achievable with that.

From what I can gather reading the code, if you aren't using a texture injected via hash it searches decompiled shaders for a known depth texture (by name) and inserts the same boilerplate code to calculate zpos and wpos from that.

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 01/16/2015 01:59 AM   
What I know about the zBufferTexture is that we don't actually use it for anything at present. I would skip over it for now. It was injected in the older code for AC3 for example, where we were just starting out. Rather than inject something that we never use, I made that code conditional upon it actually being specified in the d3dx.ini file. I also conditionally only set the t126 register if it's in use, because that would otherwise take GPU memory. In AC3, that was injected at the top for every shader, but was never actually used. It was benign, because stuff that is not referenced is automatically stripped by the compiler. So, at present, we don't have any fixes that use that feature. (possible exception is Chiri's Bioshock)
What I know about the zBufferTexture is that we don't actually use it for anything at present. I would skip over it for now.

It was injected in the older code for AC3 for example, where we were just starting out. Rather than inject something that we never use, I made that code conditional upon it actually being specified in the d3dx.ini file. I also conditionally only set the t126 register if it's in use, because that would otherwise take GPU memory.

In AC3, that was injected at the top for every shader, but was never actually used. It was benign, because stuff that is not referenced is automatically stripped by the compiler.

So, at present, we don't have any fixes that use that feature. (possible exception is Chiri's Bioshock)

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 01/16/2015 02:25 AM   
[quote="DarkStarSword"]Having this enabled in the ini also adds some code to any newly decompiled shader to declare the injected depth register, adds a position semantic to the shader inputs, and adds a bit of boilerplate code to calculate zpos and wpos - these calculations can be altered with some of the other fix_ZRepair_* parameters in the ini, but I haven't looked into how much is achievable with that. From what I can gather reading the code, if you aren't using a texture injected via hash it searches decompiled shaders for a known depth texture (by name) and inserts the same boilerplate code to calculate zpos and wpos from that.[/quote] That's right, there is a whole set of things that will be injected into the decompiled shaders via the WritePatches routine. That is only used when something is specified in the d3dx.ini that would activate one of those features. This WritePatches is roughly analogous to Helix's LUA scripts for auto-fixing shaders. Once a pattern is recognized, the computer can inject it automatically instead. I used the auto-fix of vertex shaders before for my initial SR3 fix (still gotta get back to that, dang.) That piece fixes halos automatically, by looking for the follow on textures that should also be stereoized, and injecting code at the bottom to fix them. For all of the current fixes, Mike doesn't use any of those features. His approach is to edit the files directly and avoid auto-fix mechanisms when possible. I'm pretty sure that I did not break any of those features while hacking about, so they can likely still work. The only example of their use will be the Bioshock Infinite fix.
DarkStarSword said:Having this enabled in the ini also adds some code to any newly decompiled shader to declare the injected depth register, adds a position semantic to the shader inputs, and adds a bit of boilerplate code to calculate zpos and wpos - these calculations can be altered with some of the other fix_ZRepair_* parameters in the ini, but I haven't looked into how much is achievable with that.

From what I can gather reading the code, if you aren't using a texture injected via hash it searches decompiled shaders for a known depth texture (by name) and inserts the same boilerplate code to calculate zpos and wpos from that.

That's right, there is a whole set of things that will be injected into the decompiled shaders via the WritePatches routine. That is only used when something is specified in the d3dx.ini that would activate one of those features.

This WritePatches is roughly analogous to Helix's LUA scripts for auto-fixing shaders. Once a pattern is recognized, the computer can inject it automatically instead. I used the auto-fix of vertex shaders before for my initial SR3 fix (still gotta get back to that, dang.) That piece fixes halos automatically, by looking for the follow on textures that should also be stereoized, and injecting code at the bottom to fix them.


For all of the current fixes, Mike doesn't use any of those features. His approach is to edit the files directly and avoid auto-fix mechanisms when possible.

I'm pretty sure that I did not break any of those features while hacking about, so they can likely still work. The only example of their use will be the Bioshock Infinite fix.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 01/16/2015 02:33 AM   
Nice, I won't have to handle t126 then. Makes me happy.
Nice, I won't have to handle t126 then. Makes me happy.

Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?

donations: ulfjalmbrant@hotmail.com

Posted 01/16/2015 07:06 AM   
Just a quick heads up to anyone using 3Dmigoto - we're replacing the old problematic DirectInput support with a simpler input infrastructure based around the GetAsyncKeyState() call. I've pushed the code to make this change, but bo3b will certainly be reviewing it before the next release. What does this mean for someone using 3Dmigoto? On the plus side this should allow 3Dmigoto to work in more games, and should remove the need to change the key bindings on a non-English system. However, it also means that we are using a different set of names for the keys - instead of using the system language specific DirectInput names, you need to use the virtual key names (or hex codes, either should work) from this page: http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx I've added aliases for the old English DirectInput names for the default key bindings to minimise the impact for most people, but if you have customised the bindings you may need to update them. The other major impact is that it removes support for using controllers with 3Dmigoto. I'm not sure if anyone is currently using this support and if using the keyboard instead would really be a problem for shader hunting - does anyone have a particular objection to this support being removed? I have a vague plan that I might bring controller support back after we add support for flexible key bindings for convergence & shader constant presets (e.g. conceivably someone might want a low convergence preset bound to the aim button on a controller in a FPS), but unless someone wants it back urgently I'd consider that a low priority.
Just a quick heads up to anyone using 3Dmigoto - we're replacing the old problematic DirectInput support with a simpler input infrastructure based around the GetAsyncKeyState() call. I've pushed the code to make this change, but bo3b will certainly be reviewing it before the next release.

What does this mean for someone using 3Dmigoto? On the plus side this should allow 3Dmigoto to work in more games, and should remove the need to change the key bindings on a non-English system.

However, it also means that we are using a different set of names for the keys - instead of using the system language specific DirectInput names, you need to use the virtual key names (or hex codes, either should work) from this page:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).aspx

I've added aliases for the old English DirectInput names for the default key bindings to minimise the impact for most people, but if you have customised the bindings you may need to update them.

The other major impact is that it removes support for using controllers with 3Dmigoto. I'm not sure if anyone is currently using this support and if using the keyboard instead would really be a problem for shader hunting - does anyone have a particular objection to this support being removed? I have a vague plan that I might bring controller support back after we add support for flexible key bindings for convergence & shader constant presets (e.g. conceivably someone might want a low convergence preset bound to the aim button on a controller in a FPS), but unless someone wants it back urgently I'd consider that a low priority.

2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit

Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD

Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword

Posted 01/19/2015 03:14 PM   
While it's a limited use case supporting XInput is fairly easy. Supporting other devices would probably impose directinput again. Directinput is not encouraged for keyboard so I guess it's time to remove directinput for keyboard and add it back for other devices later if needed.
While it's a limited use case supporting XInput is fairly easy. Supporting other devices would probably impose directinput again. Directinput is not encouraged for keyboard so I guess it's time to remove directinput for keyboard and add it back for other devices later if needed.

Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?

donations: ulfjalmbrant@hotmail.com

Posted 01/19/2015 07:51 PM   
The lords of the falling problem. I get instant CTD when running windows 8.1. Using my own wrapper it doesn't crash but CreateDevice is not captured so the fix cannot be applied.
The lords of the falling problem.

I get instant CTD when running windows 8.1.
Using my own wrapper it doesn't crash but CreateDevice is not captured so the fix cannot be applied.

Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?

donations: ulfjalmbrant@hotmail.com

Posted 01/22/2015 09:50 PM   
For these games that use NVidia GameWorks, you need to make sure that the d3d11.dll load happens. Not sure what technique you presently use to hook/wrap the calls, but in GameWorks games, they go directly to the Sytem32 folder for CreateDevice, which bypasses any earlier hooks. There is also an nvapi version of CreateDevice that has a similar problem. So, you might need to hook the nvapi version of CreateDevice (and CreateDeviceAndSwapChain), or might need to make sure that the loading path still uses the game directory and doesn't go direct to System32. Look at the mainhook.cpp file in 3Dmigoto for info on that.
For these games that use NVidia GameWorks, you need to make sure that the d3d11.dll load happens. Not sure what technique you presently use to hook/wrap the calls, but in GameWorks games, they go directly to the Sytem32 folder for CreateDevice, which bypasses any earlier hooks. There is also an nvapi version of CreateDevice that has a similar problem.

So, you might need to hook the nvapi version of CreateDevice (and CreateDeviceAndSwapChain), or might need to make sure that the loading path still uses the game directory and doesn't go direct to System32. Look at the mainhook.cpp file in 3Dmigoto for info on that.

Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers

Posted 01/23/2015 01:31 AM   
  16 / 141    
Scroll To Top