[center][color="orange"][size="XL"]3Dmigoto 1.3.16[/size]
[/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases[/url][/color][/center]
[center][size="L"][color="green"]Misc Big Deals[/color][/size][/center]
[list]
[.][b][color="orange"]Fix games switching partially/completely to 2D at random[/color][/b] [size="S"]when StereoMode or mono/stereo copies were in use[/size][/.]
[.][b][color="orange"]Fix performance issue getting progressively worse over time[/color][/b] [size="S"]due to endlessly duplicating ShaderRegex command lists[/size][/.]
[.][b][color="orange"]Fix "Dynamic xxx unsupported" issue with ReShade[/color][/b] [size="S"]when using resource copying[/size][/.]
[/list]
[center][size="L"][color="green"]ShaderRegex caching[/color][/size][/center]
ShaderRegex now supports caching if cache_shaders=1 to eliminate stuttering and make config reload (that does not alter any ShaderRegex sections) *much* faster, and is now recommended to enable even while developing a fix, not just for release (this option also makes CustomShader reloads much faster).
The cached files will be stored in ShaderCache and have _regex in their name (*_regex.dat, *_regex.bin) and 3DMigoto will handle updating these on demand as necessary. Note that you will see .dat files appear for shaders that are not matched by ShaderRegex as well, as these tell 3DMigoto not to bother checking them again (unless a ShaderRegex section is altered).
You can also export the patched assembly by turning on export_fixed=1, but note that since these files are updated on demand there may be stale assembly files present from outdated ShaderRegex patterns. If you need to make sure you are only looking at up to date assembly files, delete all the *_regex.* files in ShaderCache and reload the config.
A new marking action has been added (marking_actions=regex) that will dump the ShaderRegex patched shaders rather than the original assembly. If both regex and asm/hlsl are in use regex will take priority for applicable shaders and asm/hlsl will handle everything else. Note that any command lists from the ShaderRegex sections will stop applying after dumping a shader, and a warning will appear indicating if this has happened to remind you that you may need to add them to the [ShaderOverride] instead.
The patched shaders are no longer logged in d3d11_log.txt in favour of the above two methods to find it.
[center][size="L"][color="green"]patch_assembly_cb_offsets[/color][/size][/center]
A new patch_assembly_cb_offsets=1 option has been added to change the constant/structured buffer offsets in the assembly into indices (offset divided by 16) and components to make these easier to match up by eye, and to make certain ShaderRegex matches on these easier/possible. This option may break existing ShaderRegex patterns, so if it is missing in the d3dx.ini (e.g. due to a fix being upgraded) it will not be enabled, but it is included in the new template d3dx.ini in anticipation of being generally more useful than the previous output (existing dumped shaders will not be updated).
This means instead of the old Offset & (optional) Size, you will now see Index and Components:
[code]
// float localIblMipmapBias; // Index: 5.x Components: 1 [unused]
// float screenAspectRatio; // Index: 5.y Components: 1 [unused]
// float2 invResolution; // Index: 5.zw Components: 2
// float4 shadowMapSizeAndInvSize; // Index: 6.xyzw Components: 4 [unused]
[/code]
Or if the entry was missing the size field (embedded structures) only the starting index and component will be shown:
[code]
// int m_PatchX; // Index: 0
// int m_PatchZ; // Index: 0.y
[/code]
Matrices or other items occupying multiple indices will be expanded out a little differently. Items occupying 2-4 complete indices (such as matrices) will have all indices spelled out, allowing each index to be matched with a ShaderRegex capture group to be used in either the pattern or replace sections. Items occupying more than four indices or that do not completely occupy the final index will be expanded into a range instead:
[code]
// row_major float4x4 g_mViewProj; // Index: 0 1 2 3 Components: 16 [unused]
// row_major float4x4 g_mLightProj[4];// Index: 8-23 Components: 64 [unused]
// float _NeighborIsAdapting[4]; // Index: 6-9.x Components: 13
[/code]
If using a regex pattern to match these note that the number of spaces after "Index:" is variable, as are the number of spaces before and after "Components:". Matrices that have been expanded will only have a single space separating their indices, so a pattern such as the following can match these reliably:
[code]
// row_major float4x4 mW2P; // Index:\s+(?P<mW2P_0>\d+) (?P<mW2P_1>\d+) (?P<mW2P_2>\d+) (?P<mW2P_3>\d+)\s+Components:\s+16\n
[/code]
And you might then use these in a ShaderRegex replace section like:
[code]
mul ${tmp2}.xyzw, ${tmp1}.xxxx, cb0[${mW2P_0}].xyzw\n
mad ${tmp2}.xyzw, ${tmp1}.yyyy, cb0[${mW2P_1}].xyzw, ${tmp2}.xyzw\n
mad ${tmp2}.xyzw, ${tmp1}.zzzz, cb0[${mW2P_2}].xyzw, ${tmp2}.xyzw\n
add ${tmp2}.xyzw, ${tmp2}.xyzw, cb0[${mW2P_3}].xyzw\n
[/code]
Note that assembly found via the comment block in HLSL shaders will not be patched, so you should prefer getting assembly shaders via marking_actions=asm or export_shaders=1, especially if you intend to write a ShaderRegex pattern for them.
To have cmd_Decompiler produce this new format, pass it --patch-cb-offsets when disassembling a shader.
[center][size="L"][color="green"]Included Files Conditional on 3D Vision[/color][/size][/center]
Included files can now be marked to be skipped if 3D Vision is disabled in the control panel (or otherwise not supported on the user's system) by adding a "condition = stereo_available" line at the top of the file, before any sections. This will skip the entire ini file, including any global variable, Resource, CustomShader and CommandList definitions, so be wary of refering to them from other ini files that do not also have this condition.
Note that it is important to use "stereo_available" here, and not "stereo_active" as "stereo_available" refers to the control panel setting, while "stereo_active" refers to whether 3D Vision is active at this very moment in time, and only "stereo_available" is guaranteed to be statically evaluatable when the ini file is included (this line is evaluated as an expression, but must be statically evaluatable).
If you wish to disable something when 3D Vision is only temporarily inactive you should do so in a command list instead (the command list optimiser can still eliminate entire if blocks that depend on stereo_active when 3D Vision is disabled in the control panel).
[center][size="L"][color="green"]Override Included Files Namespace[/color][/size][/center]
You can now override the namespace used with an included ini file, so that you can use a well known name to access their variables, Resources, etc. from outside the file rather than the filename. This can be useful for environments where the user may drop in extra mods and may not be so good at following instructions about where to install the mods to allow these to work wherever the user placed them, or just to reduce the verbosity when accessing your own resources, e.g. you could use the notification mechanism in the [url=https://github.com/DarkStarSword/3d-fixes/tree/master/custom_shader_help_text]help text shader[/url] (that has namespace=help) like:
[code]
Resource\help\Notification = ref ResourceShadowsOff
run = CustomShader\help\FormatText
$\help\notification_timeout = time + 2.0
[ResourceShadowsOff]
type = Buffer
data = "Shadows: Off"
[/code]
However, due inexperienced modders copy+pasting someone else' mod as a starting point or two independent mods happening to choose the same namespace it is possible that a namespace collision may occur (there is no explicit protection against this, though duplicate variables & prefixed section names will trigger warnings), so this is only recommended for use in ini files that provide variables/Resources/shaders/command lists intended to be accessed from other files. Simpler mods should not override the namespace to ensure that a unique value (their filename) will be used.
If switching an existing mod that other mods already depend on to use a well known namespace, consider using the well known namespace you expected to be used previously (i.e. the path & filename of where you previously documented the mod should be installed) to fulfil both backwards compatibility and future protection against PEBKAC users.
[center][size="L"][color="green"]Driver [Profile] Helper[/color][/size][/center]
The [Profile] section now supports all setting names from Nvidia Profile Inspector (as of 2.3.0.2), eliminating the need to use the setting hex IDs for a large number of settings. As before you can discover the name for a Hex setting by adding the hex setting to the [Profile] section, installing the profile then examining the d3d11_log.txt to see what 3DMigoto decoded it as.
Notably [color="orange"]APP_COMPAT_SHIM=2 can work around[/color] threading bugs (that manifest as [color="orange"]hangs and/or driver crashes[/color]) in certain games (RE2, RE5, DMC5) - special thanks to Kaimasta for discovering this one :)
[center][size="L"][color="green"]Partner Shader Filtering / Bound Test[/color][/size][/center]
You can now test partner shaders in the same way as Texture Filtering. "vs" "hs" "ds" "gs" "ps" and "cs" can be used as operands in any expression and will evaluate to:
[list]
[.]Shader matched a ShaderOverride with a filter_index: value of filter_index[/.]
[.]Shader matched 1 (or more) ShaderRegex sections with a filter_index: value of filter_index from the first matched pattern (alphabetically)[/.]
[.]Shader matched a ShaderOverride/Regex, but no filter_index: 1.0[/.]
[.]Shader bound but did not match any ShaderOverride/Regex: 0.0[/.]
[.]No shader bound: -0.0 (negative zero - needs an explicit test with === / !== operator in d3dx.ini, asint(...) == asint(-0.0) in HLSL or ieq r0.x, r0.x, l(0x80000000) in Assembly)[/.]
[/list]
The no pixel shader bound case is useful to detect depth only passes, such as shadow maps or occlusion culling (depending on the game), or to detect one possible situation where the driver heuristics may not run a shader for the left eye.
The old deprecated partner= option has been removed from the d3dx.ini template, and the deprecation warning has been updated to suggest using this new form instead. The other alternate form setting variables from the partner's command list still works, and may or may not perform slightly faster than this new form so don't worry about switching if you are already using that (this new form has the advantage of not having any order constraints, and allows for a no shader bound test).
[center][size="L"][color="green"]nvapi[/color][/size][/center]
[list]
[.]Worked around game and/or driver bug causing Resident Evil 2 & Devil May Cry 5 to stop rendering geometry (thanks to Schwing for identifying the faulty API and finding a workaround)[/.]
[.]Avoid potential crashes if Nvidia remove their stereo calls from nvapi in the future[/.]
[/list]
[center][size="L"][color="green"]"undecipherable custom data"[/color][/size][/center]
If a game includes any custom data in their shaders (Project Cars is known to do this) it can now be disassembled and reassembled (as a hexdump) by enabling disassemble_undecipherable_custom_data=1 in the d3dx.ini. This will also fix issues where the presence of these could cause a shader to disassemble incorrectly.
It's not clear what this is (by definition), whether it is important, or even if it could cause issues - but we are taking the policy of including it by default so you can see it in the assembly and decide what to do with it yourself, and as such the option is enabled in the template d3dx.ini.
[center][size="L"][color="green"]Indirect Draw Calls[/color][/size][/center]
[list]
[.]Frame Analysis will now log the hash of indirect parameter buffers. If the game uses these (e.g. for particle effects) you may need to force them to mono with:
[code][TextureOverrideIndirect]
match_misc_flags = +drawindirect_args
StereoMode = 2[/code]
These particle effects are known to also write to index and/or vertex buffers on the GPU, so you may also need to force those to mono:
[code]
[TextureOverrideIndirectIB]
match_bind_flags = +index_buffer
StereoMode = 2
[TextureOverrideIndirectVB]
match_bind_flags = +vertex_buffer
StereoMode = 2
[/code]
[/.]
[.]ShaderOverrides/Regex command lists can now replace the indirect buffer with "this = ...", e.g. "this = mono copy this"[/.]
[.]Added support to issue DrawIndexedInstancedIndirect, DrawInstancedIndirect or DispatchIndirect calls of our own, which can be useful to have one custom shader decide how many invocations another custom shader will run, e.g.:
[code]DrawIndexedInstancedIndirect = ResourceIndirectArgs, 0[/code](Only lightly tested - please report any issues)[/.]
[/list]
[center][size="L"][color="green"]3DMigoto Loader[/color][/size][/center]
[list]
[.]Will now set the working directory if launch is set to the game's executable (fixes some games not launching automatically)[/.]
[.]If launch option is in use but the game takes a while to spawn it will now display a message indicating that the game can be launched manually (for cases where we have assumed a game is only available on Steam that is later released through some other distribution channel, since some users assumed the Steam launch was required when it actually is not)[/.]
[/list]
[center][size="L"][color="green"]Crash Handler[/color][/size][/center]
3DMigoto now includes an optional crash handler that can be enabled with crash=1 under [Logging]. If the game crashes while this is enabled 3DMigoto will sound an SOS, flush the log file (possibly replacing the need for unbuffered=1 to get valid crash debug logs in some cases) and write out a minidump file that can be opened in a debugger to find out what happened (many games already do this themselves, but not all).
If the game should hang instead of crash you can attempt to manually invoke the crash handler to write out a minidump file by holding Ctrl+Alt+F11 for five seconds (crash=1 must have been enabled in advance). If that doesn't work you can always use Task Manager to dump the process as usual.
EDIT: It looks like this was incorrectly merged. The crash handler is included, but has some issues that were supposed to have been polished out before release.
[center][size="L"][color="green"]Misc[/color][/size][/center]
[list]
[.]handling=skip and draw=from_caller now work with compute shaders[/.]
[.]Operands added to access remaining draw arguments (in addition to the existing vertex_count, index_count & instance_count): first_vertex, first_index, first_instance, thread_group_count_x, thread_group_count_y, thread_group_count_z, indirect_offset, draw_type
draw_type will be one of: N/A=0, Draw=1, DrawIndexed=2, DrawInstanced=3, DrawIndexedInstanced=4, DrawInstancedIndirect=5, DrawIndexedInstancedIndirect=6, DrawAuto=7, Dispatch=8, DispatchIndirect=9[/.]
[.]Arguments passed to draw/dispatch commands are now expressions and can be calculated live, e.g. to launch a compute shader with thread groups for each 16x16 block (calculated from the currently assigned o0 - fetching dimensions of arbitrary resources is still on my TODO list):
[code]Dispatch = (rt_width + 15) / 16, (rt_height + 15) / 16, 1[/code][/.]
[.]Frame analysis log will now indicate any resources that failed to create (check the d3d11_log.txt to find out why)[/.]
[.]Fix certain resources failing to create due to incompatible combination of bind+misc flags[/.]
[.][Resource] sections may now override misc_flags if required (usually should not be)[/.]
[.]ShaderUsage.txt now expands bind_flags, misc_flags and cpu_access_flags into words instead of numbers (the same words that can be used when matching these in fuzzy TextureOverrides, or when overriding them in Resource sections)[/.]
[.]TextureOverride matches will now include the resource description in the d3d11_log.txt[/.]
[.]Shaders decompiled via export_hlsl now use our disassembly fixup path, which should fix any floating point precision issues in these. Shaders decompiled via hunting already used the precision fixup.[/.]
[.]Dropped support for the broken marking_mode=zero[/.]
[.]Refactored and fixed numerous issues in the "big scary shader replacement routine" that could be used to frighten small children. If you see any new bugs loading shaders out of ShaderFixes, exporting shaders to ShaderCache or using Chiri's old HLSL auto-fixes* it means the Bogeyman got me ;-)
* These auto-fixes may be dropped at some point in the future - if anyone is using them please let me know.
[/.]
[/list]
Fix games switching partially/completely to 2D at randomwhen StereoMode or mono/stereo copies were in use
Fix performance issue getting progressively worse over timedue to endlessly duplicating ShaderRegex command lists
Fix "Dynamic xxx unsupported" issue with ReShadewhen using resource copying
ShaderRegex caching
ShaderRegex now supports caching if cache_shaders=1 to eliminate stuttering and make config reload (that does not alter any ShaderRegex sections) *much* faster, and is now recommended to enable even while developing a fix, not just for release (this option also makes CustomShader reloads much faster).
The cached files will be stored in ShaderCache and have _regex in their name (*_regex.dat, *_regex.bin) and 3DMigoto will handle updating these on demand as necessary. Note that you will see .dat files appear for shaders that are not matched by ShaderRegex as well, as these tell 3DMigoto not to bother checking them again (unless a ShaderRegex section is altered).
You can also export the patched assembly by turning on export_fixed=1, but note that since these files are updated on demand there may be stale assembly files present from outdated ShaderRegex patterns. If you need to make sure you are only looking at up to date assembly files, delete all the *_regex.* files in ShaderCache and reload the config.
A new marking action has been added (marking_actions=regex) that will dump the ShaderRegex patched shaders rather than the original assembly. If both regex and asm/hlsl are in use regex will take priority for applicable shaders and asm/hlsl will handle everything else. Note that any command lists from the ShaderRegex sections will stop applying after dumping a shader, and a warning will appear indicating if this has happened to remind you that you may need to add them to the [ShaderOverride] instead.
The patched shaders are no longer logged in d3d11_log.txt in favour of the above two methods to find it.
patch_assembly_cb_offsets
A new patch_assembly_cb_offsets=1 option has been added to change the constant/structured buffer offsets in the assembly into indices (offset divided by 16) and components to make these easier to match up by eye, and to make certain ShaderRegex matches on these easier/possible. This option may break existing ShaderRegex patterns, so if it is missing in the d3dx.ini (e.g. due to a fix being upgraded) it will not be enabled, but it is included in the new template d3dx.ini in anticipation of being generally more useful than the previous output (existing dumped shaders will not be updated).
This means instead of the old Offset & (optional) Size, you will now see Index and Components:
Or if the entry was missing the size field (embedded structures) only the starting index and component will be shown:
// int m_PatchX; // Index: 0
// int m_PatchZ; // Index: 0.y
Matrices or other items occupying multiple indices will be expanded out a little differently. Items occupying 2-4 complete indices (such as matrices) will have all indices spelled out, allowing each index to be matched with a ShaderRegex capture group to be used in either the pattern or replace sections. Items occupying more than four indices or that do not completely occupy the final index will be expanded into a range instead:
If using a regex pattern to match these note that the number of spaces after "Index:" is variable, as are the number of spaces before and after "Components:". Matrices that have been expanded will only have a single space separating their indices, so a pattern such as the following can match these reliably:
Note that assembly found via the comment block in HLSL shaders will not be patched, so you should prefer getting assembly shaders via marking_actions=asm or export_shaders=1, especially if you intend to write a ShaderRegex pattern for them.
To have cmd_Decompiler produce this new format, pass it --patch-cb-offsets when disassembling a shader.
Included Files Conditional on 3D Vision
Included files can now be marked to be skipped if 3D Vision is disabled in the control panel (or otherwise not supported on the user's system) by adding a "condition = stereo_available" line at the top of the file, before any sections. This will skip the entire ini file, including any global variable, Resource, CustomShader and CommandList definitions, so be wary of refering to them from other ini files that do not also have this condition.
Note that it is important to use "stereo_available" here, and not "stereo_active" as "stereo_available" refers to the control panel setting, while "stereo_active" refers to whether 3D Vision is active at this very moment in time, and only "stereo_available" is guaranteed to be statically evaluatable when the ini file is included (this line is evaluated as an expression, but must be statically evaluatable).
If you wish to disable something when 3D Vision is only temporarily inactive you should do so in a command list instead (the command list optimiser can still eliminate entire if blocks that depend on stereo_active when 3D Vision is disabled in the control panel).
Override Included Files Namespace
You can now override the namespace used with an included ini file, so that you can use a well known name to access their variables, Resources, etc. from outside the file rather than the filename. This can be useful for environments where the user may drop in extra mods and may not be so good at following instructions about where to install the mods to allow these to work wherever the user placed them, or just to reduce the verbosity when accessing your own resources, e.g. you could use the notification mechanism in the help text shader (that has namespace=help) like:
Resource\help\Notification = ref ResourceShadowsOff
run = CustomShader\help\FormatText
$\help\notification_timeout = time + 2.0
[ResourceShadowsOff]
type = Buffer
data = "Shadows: Off"
However, due inexperienced modders copy+pasting someone else' mod as a starting point or two independent mods happening to choose the same namespace it is possible that a namespace collision may occur (there is no explicit protection against this, though duplicate variables & prefixed section names will trigger warnings), so this is only recommended for use in ini files that provide variables/Resources/shaders/command lists intended to be accessed from other files. Simpler mods should not override the namespace to ensure that a unique value (their filename) will be used.
If switching an existing mod that other mods already depend on to use a well known namespace, consider using the well known namespace you expected to be used previously (i.e. the path & filename of where you previously documented the mod should be installed) to fulfil both backwards compatibility and future protection against PEBKAC users.
Driver [Profile] Helper
The [Profile] section now supports all setting names from Nvidia Profile Inspector (as of 2.3.0.2), eliminating the need to use the setting hex IDs for a large number of settings. As before you can discover the name for a Hex setting by adding the hex setting to the [Profile] section, installing the profile then examining the d3d11_log.txt to see what 3DMigoto decoded it as.
Notably APP_COMPAT_SHIM=2 can work around threading bugs (that manifest as hangs and/or driver crashes) in certain games (RE2, RE5, DMC5) - special thanks to Kaimasta for discovering this one :)
Partner Shader Filtering / Bound Test
You can now test partner shaders in the same way as Texture Filtering. "vs" "hs" "ds" "gs" "ps" and "cs" can be used as operands in any expression and will evaluate to:
Shader matched a ShaderOverride with a filter_index: value of filter_index
Shader matched 1 (or more) ShaderRegex sections with a filter_index: value of filter_index from the first matched pattern (alphabetically)
Shader matched a ShaderOverride/Regex, but no filter_index: 1.0
Shader bound but did not match any ShaderOverride/Regex: 0.0
No shader bound: -0.0 (negative zero - needs an explicit test with === / !== operator in d3dx.ini, asint(...) == asint(-0.0) in HLSL or ieq r0.x, r0.x, l(0x80000000) in Assembly)
The no pixel shader bound case is useful to detect depth only passes, such as shadow maps or occlusion culling (depending on the game), or to detect one possible situation where the driver heuristics may not run a shader for the left eye.
The old deprecated partner= option has been removed from the d3dx.ini template, and the deprecation warning has been updated to suggest using this new form instead. The other alternate form setting variables from the partner's command list still works, and may or may not perform slightly faster than this new form so don't worry about switching if you are already using that (this new form has the advantage of not having any order constraints, and allows for a no shader bound test).
nvapi
Worked around game and/or driver bug causing Resident Evil 2 & Devil May Cry 5 to stop rendering geometry (thanks to Schwing for identifying the faulty API and finding a workaround)
Avoid potential crashes if Nvidia remove their stereo calls from nvapi in the future
"undecipherable custom data"
If a game includes any custom data in their shaders (Project Cars is known to do this) it can now be disassembled and reassembled (as a hexdump) by enabling disassemble_undecipherable_custom_data=1 in the d3dx.ini. This will also fix issues where the presence of these could cause a shader to disassemble incorrectly.
It's not clear what this is (by definition), whether it is important, or even if it could cause issues - but we are taking the policy of including it by default so you can see it in the assembly and decide what to do with it yourself, and as such the option is enabled in the template d3dx.ini.
Indirect Draw Calls
Frame Analysis will now log the hash of indirect parameter buffers. If the game uses these (e.g. for particle effects) you may need to force them to mono with:
ShaderOverrides/Regex command lists can now replace the indirect buffer with "this = ...", e.g. "this = mono copy this"
Added support to issue DrawIndexedInstancedIndirect, DrawInstancedIndirect or DispatchIndirect calls of our own, which can be useful to have one custom shader decide how many invocations another custom shader will run, e.g.:
Will now set the working directory if launch is set to the game's executable (fixes some games not launching automatically)
If launch option is in use but the game takes a while to spawn it will now display a message indicating that the game can be launched manually (for cases where we have assumed a game is only available on Steam that is later released through some other distribution channel, since some users assumed the Steam launch was required when it actually is not)
Crash Handler
3DMigoto now includes an optional crash handler that can be enabled with crash=1 under [Logging]. If the game crashes while this is enabled 3DMigoto will sound an SOS, flush the log file (possibly replacing the need for unbuffered=1 to get valid crash debug logs in some cases) and write out a minidump file that can be opened in a debugger to find out what happened (many games already do this themselves, but not all).
If the game should hang instead of crash you can attempt to manually invoke the crash handler to write out a minidump file by holding Ctrl+Alt+F11 for five seconds (crash=1 must have been enabled in advance). If that doesn't work you can always use Task Manager to dump the process as usual.
EDIT: It looks like this was incorrectly merged. The crash handler is included, but has some issues that were supposed to have been polished out before release.
Misc
handling=skip and draw=from_caller now work with compute shaders
Operands added to access remaining draw arguments (in addition to the existing vertex_count, index_count & instance_count): first_vertex, first_index, first_instance, thread_group_count_x, thread_group_count_y, thread_group_count_z, indirect_offset, draw_type
draw_type will be one of: N/A=0, Draw=1, DrawIndexed=2, DrawInstanced=3, DrawIndexedInstanced=4, DrawInstancedIndirect=5, DrawIndexedInstancedIndirect=6, DrawAuto=7, Dispatch=8, DispatchIndirect=9
Arguments passed to draw/dispatch commands are now expressions and can be calculated live, e.g. to launch a compute shader with thread groups for each 16x16 block (calculated from the currently assigned o0 - fetching dimensions of arbitrary resources is still on my TODO list):
Frame analysis log will now indicate any resources that failed to create (check the d3d11_log.txt to find out why)
Fix certain resources failing to create due to incompatible combination of bind+misc flags
[Resource] sections may now override misc_flags if required (usually should not be)
ShaderUsage.txt now expands bind_flags, misc_flags and cpu_access_flags into words instead of numbers (the same words that can be used when matching these in fuzzy TextureOverrides, or when overriding them in Resource sections)
TextureOverride matches will now include the resource description in the d3d11_log.txt
Shaders decompiled via export_hlsl now use our disassembly fixup path, which should fix any floating point precision issues in these. Shaders decompiled via hunting already used the precision fixup.
Dropped support for the broken marking_mode=zero
Refactored and fixed numerous issues in the "big scary shader replacement routine" that could be used to frighten small children. If you see any new bugs loading shaders out of ShaderFixes, exporting shaders to ShaderCache or using Chiri's old HLSL auto-fixes* it means the Bogeyman got me ;-)
* These auto-fixes may be dropped at some point in the future - if anyone is using them please let me know.
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
[quote="DarkStarSword"][center][color="orange"][size="XL"]3Dmigoto 1.3.16[/size]
[/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases[/url][/color][/center]
[center][size="L"][color="green"]Misc Big Deals[/color][/size][/center]
[list]
[.][b][color="orange"]Fix games switching partially/completely to 2D at random[/color][/b] [size="S"]when StereoMode or mono/stereo copies were in use[/size][/.]
[.][b][color="orange"]Fix performance issue getting progressively worse over time[/color][/b] [size="S"]due to endlessly duplicating ShaderRegex command lists[/size][/.]
[.][b][color="orange"]Fix "Dynamic xxx unsupported" issue with ReShade[/color][/b] [size="S"]when using resource copying[/size][/.]
[/list]
[center][size="L"][color="green"]ShaderRegex caching[/color][/size][/center]
ShaderRegex now supports caching if cache_shaders=1 to eliminate stuttering and make config reload (that does not alter any ShaderRegex sections) *much* faster, and is now recommended to enable even while developing a fix, not just for release (this option also makes CustomShader reloads much faster).
The cached files will be stored in ShaderCache and have _regex in their name (*_regex.dat, *_regex.bin) and 3DMigoto will handle updating these on demand as necessary. Note that you will see .dat files appear for shaders that are not matched by ShaderRegex as well, as these tell 3DMigoto not to bother checking them again (unless a ShaderRegex section is altered).
You can also export the patched assembly by turning on export_fixed=1, but note that since these files are updated on demand there may be stale assembly files present from outdated ShaderRegex patterns. If you need to make sure you are only looking at up to date assembly files, delete all the *_regex.* files in ShaderCache and reload the config.
A new marking action has been added (marking_actions=regex) that will dump the ShaderRegex patched shaders rather than the original assembly. If both regex and asm/hlsl are in use regex will take priority for applicable shaders and asm/hlsl will handle everything else. Note that any command lists from the ShaderRegex sections will stop applying after dumping a shader, and a warning will appear indicating if this has happened to remind you that you may need to add them to the [ShaderOverride] instead.
The patched shaders are no longer logged in d3d11_log.txt in favour of the above two methods to find it.
[center][size="L"][color="green"]patch_assembly_cb_offsets[/color][/size][/center]
A new patch_assembly_cb_offsets=1 option has been added to change the constant/structured buffer offsets in the assembly into indices (offset divided by 16) and components to make these easier to match up by eye, and to make certain ShaderRegex matches on these easier/possible. This option may break existing ShaderRegex patterns, so if it is missing in the d3dx.ini (e.g. due to a fix being upgraded) it will not be enabled, but it is included in the new template d3dx.ini in anticipation of being generally more useful than the previous output (existing dumped shaders will not be updated).
This means instead of the old Offset & (optional) Size, you will now see Index and Components:
[code]
// float localIblMipmapBias; // Index: 5.x Components: 1 [unused]
// float screenAspectRatio; // Index: 5.y Components: 1 [unused]
// float2 invResolution; // Index: 5.zw Components: 2
// float4 shadowMapSizeAndInvSize; // Index: 6.xyzw Components: 4 [unused]
[/code]
Or if the entry was missing the size field (embedded structures) only the starting index and component will be shown:
[code]
// int m_PatchX; // Index: 0
// int m_PatchZ; // Index: 0.y
[/code]
Matrices or other items occupying multiple indices will be expanded out a little differently. Items occupying 2-4 complete indices (such as matrices) will have all indices spelled out, allowing each index to be matched with a ShaderRegex capture group to be used in either the pattern or replace sections. Items occupying more than four indices or that do not completely occupy the final index will be expanded into a range instead:
[code]
// row_major float4x4 g_mViewProj; // Index: 0 1 2 3 Components: 16 [unused]
// row_major float4x4 g_mLightProj[4];// Index: 8-23 Components: 64 [unused]
// float _NeighborIsAdapting[4]; // Index: 6-9.x Components: 13
[/code]
If using a regex pattern to match these note that the number of spaces after "Index:" is variable, as are the number of spaces before and after "Components:". Matrices that have been expanded will only have a single space separating their indices, so a pattern such as the following can match these reliably:
[code]
// row_major float4x4 mW2P; // Index:\s+(?P<mW2P_0>\d+) (?P<mW2P_1>\d+) (?P<mW2P_2>\d+) (?P<mW2P_3>\d+)\s+Components:\s+16\n
[/code]
And you might then use these in a ShaderRegex replace section like:
[code]
mul ${tmp2}.xyzw, ${tmp1}.xxxx, cb0[${mW2P_0}].xyzw\n
mad ${tmp2}.xyzw, ${tmp1}.yyyy, cb0[${mW2P_1}].xyzw, ${tmp2}.xyzw\n
mad ${tmp2}.xyzw, ${tmp1}.zzzz, cb0[${mW2P_2}].xyzw, ${tmp2}.xyzw\n
add ${tmp2}.xyzw, ${tmp2}.xyzw, cb0[${mW2P_3}].xyzw\n
[/code]
Note that assembly found via the comment block in HLSL shaders will not be patched, so you should prefer getting assembly shaders via marking_actions=asm or export_shaders=1, especially if you intend to write a ShaderRegex pattern for them.
To have cmd_Decompiler produce this new format, pass it --patch-cb-offsets when disassembling a shader.
[center][size="L"][color="green"]Included Files Conditional on 3D Vision[/color][/size][/center]
Included files can now be marked to be skipped if 3D Vision is disabled in the control panel (or otherwise not supported on the user's system) by adding a "condition = stereo_available" line at the top of the file, before any sections. This will skip the entire ini file, including any global variable, Resource, CustomShader and CommandList definitions, so be wary of refering to them from other ini files that do not also have this condition.
Note that it is important to use "stereo_available" here, and not "stereo_active" as "stereo_available" refers to the control panel setting, while "stereo_active" refers to whether 3D Vision is active at this very moment in time, and only "stereo_available" is guaranteed to be statically evaluatable when the ini file is included (this line is evaluated as an expression, but must be statically evaluatable).
If you wish to disable something when 3D Vision is only temporarily inactive you should do so in a command list instead (the command list optimiser can still eliminate entire if blocks that depend on stereo_active when 3D Vision is disabled in the control panel).
[center][size="L"][color="green"]Override Included Files Namespace[/color][/size][/center]
You can now override the namespace used with an included ini file, so that you can use a well known name to access their variables, Resources, etc. from outside the file rather than the filename. This can be useful for environments where the user may drop in extra mods and may not be so good at following instructions about where to install the mods to allow these to work wherever the user placed them, or just to reduce the verbosity when accessing your own resources, e.g. you could use the notification mechanism in the [url=https://github.com/DarkStarSword/3d-fixes/tree/master/custom_shader_help_text]help text shader[/url] (that has namespace=help) like:
[code]
Resource\help\Notification = ref ResourceShadowsOff
run = CustomShader\help\FormatText
$\help\notification_timeout = time + 2.0
[ResourceShadowsOff]
type = Buffer
data = "Shadows: Off"
[/code]
However, due inexperienced modders copy+pasting someone else' mod as a starting point or two independent mods happening to choose the same namespace it is possible that a namespace collision may occur (there is no explicit protection against this, though duplicate variables & prefixed section names will trigger warnings), so this is only recommended for use in ini files that provide variables/Resources/shaders/command lists intended to be accessed from other files. Simpler mods should not override the namespace to ensure that a unique value (their filename) will be used.
If switching an existing mod that other mods already depend on to use a well known namespace, consider using the well known namespace you expected to be used previously (i.e. the path & filename of where you previously documented the mod should be installed) to fulfil both backwards compatibility and future protection against PEBKAC users.
[center][size="L"][color="green"]Driver [Profile] Helper[/color][/size][/center]
The [Profile] section now supports all setting names from Nvidia Profile Inspector (as of 2.3.0.2), eliminating the need to use the setting hex IDs for a large number of settings. As before you can discover the name for a Hex setting by adding the hex setting to the [Profile] section, installing the profile then examining the d3d11_log.txt to see what 3DMigoto decoded it as.
Notably [color="orange"]APP_COMPAT_SHIM=2 can work around[/color] threading bugs (that manifest as [color="orange"]hangs and/or driver crashes[/color]) in certain games (RE2, RE5, DMC5) - special thanks to Kaimasta for discovering this one :)
[center][size="L"][color="green"]Partner Shader Filtering / Bound Test[/color][/size][/center]
You can now test partner shaders in the same way as Texture Filtering. "vs" "hs" "ds" "gs" "ps" and "cs" can be used as operands in any expression and will evaluate to:
[list]
[.]Shader matched a ShaderOverride with a filter_index: value of filter_index[/.]
[.]Shader matched 1 (or more) ShaderRegex sections with a filter_index: value of filter_index from the first matched pattern (alphabetically)[/.]
[.]Shader matched a ShaderOverride/Regex, but no filter_index: 1.0[/.]
[.]Shader bound but did not match any ShaderOverride/Regex: 0.0[/.]
[.]No shader bound: -0.0 (negative zero - needs an explicit test with === / !== operator in d3dx.ini, asint(...) == asint(-0.0) in HLSL or ieq r0.x, r0.x, l(0x80000000) in Assembly)[/.]
[/list]
The no pixel shader bound case is useful to detect depth only passes, such as shadow maps or occlusion culling (depending on the game), or to detect one possible situation where the driver heuristics may not run a shader for the left eye.
The old deprecated partner= option has been removed from the d3dx.ini template, and the deprecation warning has been updated to suggest using this new form instead. The other alternate form setting variables from the partner's command list still works, and may or may not perform slightly faster than this new form so don't worry about switching if you are already using that (this new form has the advantage of not having any order constraints, and allows for a no shader bound test).
[center][size="L"][color="green"]nvapi[/color][/size][/center]
[list]
[.]Worked around game and/or driver bug causing Resident Evil 2 & Devil May Cry 5 to stop rendering geometry (thanks to Schwing for identifying the faulty API and finding a workaround)[/.]
[.]Avoid potential crashes if Nvidia remove their stereo calls from nvapi in the future[/.]
[/list]
[center][size="L"][color="green"]"undecipherable custom data"[/color][/size][/center]
If a game includes any custom data in their shaders (Project Cars is known to do this) it can now be disassembled and reassembled (as a hexdump) by enabling disassemble_undecipherable_custom_data=1 in the d3dx.ini. This will also fix issues where the presence of these could cause a shader to disassemble incorrectly.
It's not clear what this is (by definition), whether it is important, or even if it could cause issues - but we are taking the policy of including it by default so you can see it in the assembly and decide what to do with it yourself, and as such the option is enabled in the template d3dx.ini.
[center][size="L"][color="green"]Indirect Draw Calls[/color][/size][/center]
[list]
[.]Frame Analysis will now log the hash of indirect parameter buffers. If the game uses these (e.g. for particle effects) you may need to force them to mono with:
[code][TextureOverrideIndirect]
match_misc_flags = +drawindirect_args
StereoMode = 2[/code]
These particle effects are known to also write to index and/or vertex buffers on the GPU, so you may also need to force those to mono:
[code]
[TextureOverrideIndirectIB]
match_bind_flags = +index_buffer
StereoMode = 2
[TextureOverrideIndirectVB]
match_bind_flags = +vertex_buffer
StereoMode = 2
[/code]
[/.]
[.]ShaderOverrides/Regex command lists can now replace the indirect buffer with "this = ...", e.g. "this = mono copy this"[/.]
[.]Added support to issue DrawIndexedInstancedIndirect, DrawInstancedIndirect or DispatchIndirect calls of our own, which can be useful to have one custom shader decide how many invocations another custom shader will run, e.g.:
[code]DrawIndexedInstancedIndirect = ResourceIndirectArgs, 0[/code](Only lightly tested - please report any issues)[/.]
[/list]
[center][size="L"][color="green"]3DMigoto Loader[/color][/size][/center]
[list]
[.]Will now set the working directory if launch is set to the game's executable (fixes some games not launching automatically)[/.]
[.]If launch option is in use but the game takes a while to spawn it will now display a message indicating that the game can be launched manually (for cases where we have assumed a game is only available on Steam that is later released through some other distribution channel, since some users assumed the Steam launch was required when it actually is not)[/.]
[/list]
[center][size="L"][color="green"]Crash Handler[/color][/size][/center]
3DMigoto now includes an optional crash handler that can be enabled with crash=1 under [Logging]. If the game crashes while this is enabled 3DMigoto will sound an SOS, flush the log file (possibly replacing the need for unbuffered=1 to get valid crash debug logs in some cases) and write out a minidump file that can be opened in a debugger to find out what happened (many games already do this themselves, but not all).
If the game should hang instead of crash you can attempt to manually invoke the crash handler to write out a minidump file by holding Ctrl+Alt+F11 for five seconds (crash=1 must have been enabled in advance). If that doesn't work you can always use Task Manager to dump the process as usual.
[center][size="L"][color="green"]Misc[/color][/size][/center]
[list]
[.]handling=skip and draw=from_caller now work with compute shaders[/.]
[.]Operands added to access remaining draw arguments (in addition to the existing vertex_count, index_count & instance_count): first_vertex, first_index, first_instance, thread_group_count_x, thread_group_count_y, thread_group_count_z, indirect_offset, draw_type
draw_type will be one of: N/A=0, Draw=1, DrawIndexed=2, DrawInstanced=3, DrawIndexedInstanced=4, DrawInstancedIndirect=5, DrawIndexedInstancedIndirect=6, DrawAuto=7, Dispatch=8, DispatchIndirect=9[/.]
[.]Arguments passed to draw/dispatch commands are now expressions and can be calculated live, e.g. to launch a compute shader with thread groups for each 16x16 block (calculated from the currently assigned o0 - fetching dimensions of arbitrary resources is still on my TODO list):
[code]Dispatch = (rt_width + 15) / 16, (rt_height + 15) / 16, 1[/code][/.]
[.]Frame analysis log will now indicate any resources that failed to create (check the d3d11_log.txt to find out why)[/.]
[.]Fix certain resources failing to create due to incompatible combination of bind+misc flags[/.]
[.][Resource] sections may now override misc_flags if required (usually should not be)[/.]
[.]ShaderUsage.txt now expands bind_flags, misc_flags and cpu_access_flags into words instead of numbers (the same words that can be used when matching these in fuzzy TextureOverrides, or when overriding them in Resource sections)[/.]
[.]TextureOverride matches will now include the resource description in the d3d11_log.txt[/.]
[.]Shaders decompiled via export_hlsl now use our disassembly fixup path, which should fix any floating point precision issues in these. Shaders decompiled via hunting already used the precision fixup.[/.]
[.]Dropped support for the broken marking_mode=zero[/.]
[.]Refactored and fixed numerous issues in the "big scary shader replacement routine" that could be used to frighten small children. If you see any new bugs loading shaders out of ShaderFixes, exporting shaders to ShaderCache or using Chiri's old HLSL auto-fixes* it means the Bogeyman got me ;-)
* These auto-fixes may be dropped at some point in the future - if anyone is using them please let me know.
[/.]
[/list]
[/quote]
@NVIDIA
seriously you want to cut the 3D tap?
These guys have more games running in 3D than in SLI (official)...Please reconsider
@DarkStarSword
Awesome job as always
Fix games switching partially/completely to 2D at randomwhen StereoMode or mono/stereo copies were in use
Fix performance issue getting progressively worse over timedue to endlessly duplicating ShaderRegex command lists
Fix "Dynamic xxx unsupported" issue with ReShadewhen using resource copying
ShaderRegex caching
ShaderRegex now supports caching if cache_shaders=1 to eliminate stuttering and make config reload (that does not alter any ShaderRegex sections) *much* faster, and is now recommended to enable even while developing a fix, not just for release (this option also makes CustomShader reloads much faster).
The cached files will be stored in ShaderCache and have _regex in their name (*_regex.dat, *_regex.bin) and 3DMigoto will handle updating these on demand as necessary. Note that you will see .dat files appear for shaders that are not matched by ShaderRegex as well, as these tell 3DMigoto not to bother checking them again (unless a ShaderRegex section is altered).
You can also export the patched assembly by turning on export_fixed=1, but note that since these files are updated on demand there may be stale assembly files present from outdated ShaderRegex patterns. If you need to make sure you are only looking at up to date assembly files, delete all the *_regex.* files in ShaderCache and reload the config.
A new marking action has been added (marking_actions=regex) that will dump the ShaderRegex patched shaders rather than the original assembly. If both regex and asm/hlsl are in use regex will take priority for applicable shaders and asm/hlsl will handle everything else. Note that any command lists from the ShaderRegex sections will stop applying after dumping a shader, and a warning will appear indicating if this has happened to remind you that you may need to add them to the [ShaderOverride] instead.
The patched shaders are no longer logged in d3d11_log.txt in favour of the above two methods to find it.
patch_assembly_cb_offsets
A new patch_assembly_cb_offsets=1 option has been added to change the constant/structured buffer offsets in the assembly into indices (offset divided by 16) and components to make these easier to match up by eye, and to make certain ShaderRegex matches on these easier/possible. This option may break existing ShaderRegex patterns, so if it is missing in the d3dx.ini (e.g. due to a fix being upgraded) it will not be enabled, but it is included in the new template d3dx.ini in anticipation of being generally more useful than the previous output (existing dumped shaders will not be updated).
This means instead of the old Offset & (optional) Size, you will now see Index and Components:
Or if the entry was missing the size field (embedded structures) only the starting index and component will be shown:
// int m_PatchX; // Index: 0
// int m_PatchZ; // Index: 0.y
Matrices or other items occupying multiple indices will be expanded out a little differently. Items occupying 2-4 complete indices (such as matrices) will have all indices spelled out, allowing each index to be matched with a ShaderRegex capture group to be used in either the pattern or replace sections. Items occupying more than four indices or that do not completely occupy the final index will be expanded into a range instead:
If using a regex pattern to match these note that the number of spaces after "Index:" is variable, as are the number of spaces before and after "Components:". Matrices that have been expanded will only have a single space separating their indices, so a pattern such as the following can match these reliably:
Note that assembly found via the comment block in HLSL shaders will not be patched, so you should prefer getting assembly shaders via marking_actions=asm or export_shaders=1, especially if you intend to write a ShaderRegex pattern for them.
To have cmd_Decompiler produce this new format, pass it --patch-cb-offsets when disassembling a shader.
Included Files Conditional on 3D Vision
Included files can now be marked to be skipped if 3D Vision is disabled in the control panel (or otherwise not supported on the user's system) by adding a "condition = stereo_available" line at the top of the file, before any sections. This will skip the entire ini file, including any global variable, Resource, CustomShader and CommandList definitions, so be wary of refering to them from other ini files that do not also have this condition.
Note that it is important to use "stereo_available" here, and not "stereo_active" as "stereo_available" refers to the control panel setting, while "stereo_active" refers to whether 3D Vision is active at this very moment in time, and only "stereo_available" is guaranteed to be statically evaluatable when the ini file is included (this line is evaluated as an expression, but must be statically evaluatable).
If you wish to disable something when 3D Vision is only temporarily inactive you should do so in a command list instead (the command list optimiser can still eliminate entire if blocks that depend on stereo_active when 3D Vision is disabled in the control panel).
Override Included Files Namespace
You can now override the namespace used with an included ini file, so that you can use a well known name to access their variables, Resources, etc. from outside the file rather than the filename. This can be useful for environments where the user may drop in extra mods and may not be so good at following instructions about where to install the mods to allow these to work wherever the user placed them, or just to reduce the verbosity when accessing your own resources, e.g. you could use the notification mechanism in the help text shader (that has namespace=help) like:
Resource\help\Notification = ref ResourceShadowsOff
run = CustomShader\help\FormatText
$\help\notification_timeout = time + 2.0
[ResourceShadowsOff]
type = Buffer
data = "Shadows: Off"
However, due inexperienced modders copy+pasting someone else' mod as a starting point or two independent mods happening to choose the same namespace it is possible that a namespace collision may occur (there is no explicit protection against this, though duplicate variables & prefixed section names will trigger warnings), so this is only recommended for use in ini files that provide variables/Resources/shaders/command lists intended to be accessed from other files. Simpler mods should not override the namespace to ensure that a unique value (their filename) will be used.
If switching an existing mod that other mods already depend on to use a well known namespace, consider using the well known namespace you expected to be used previously (i.e. the path & filename of where you previously documented the mod should be installed) to fulfil both backwards compatibility and future protection against PEBKAC users.
Driver [Profile] Helper
The [Profile] section now supports all setting names from Nvidia Profile Inspector (as of 2.3.0.2), eliminating the need to use the setting hex IDs for a large number of settings. As before you can discover the name for a Hex setting by adding the hex setting to the [Profile] section, installing the profile then examining the d3d11_log.txt to see what 3DMigoto decoded it as.
Notably APP_COMPAT_SHIM=2 can work around threading bugs (that manifest as hangs and/or driver crashes) in certain games (RE2, RE5, DMC5) - special thanks to Kaimasta for discovering this one :)
Partner Shader Filtering / Bound Test
You can now test partner shaders in the same way as Texture Filtering. "vs" "hs" "ds" "gs" "ps" and "cs" can be used as operands in any expression and will evaluate to:
Shader matched a ShaderOverride with a filter_index: value of filter_index
Shader matched 1 (or more) ShaderRegex sections with a filter_index: value of filter_index from the first matched pattern (alphabetically)
Shader matched a ShaderOverride/Regex, but no filter_index: 1.0
Shader bound but did not match any ShaderOverride/Regex: 0.0
No shader bound: -0.0 (negative zero - needs an explicit test with === / !== operator in d3dx.ini, asint(...) == asint(-0.0) in HLSL or ieq r0.x, r0.x, l(0x80000000) in Assembly)
The no pixel shader bound case is useful to detect depth only passes, such as shadow maps or occlusion culling (depending on the game), or to detect one possible situation where the driver heuristics may not run a shader for the left eye.
The old deprecated partner= option has been removed from the d3dx.ini template, and the deprecation warning has been updated to suggest using this new form instead. The other alternate form setting variables from the partner's command list still works, and may or may not perform slightly faster than this new form so don't worry about switching if you are already using that (this new form has the advantage of not having any order constraints, and allows for a no shader bound test).
nvapi
Worked around game and/or driver bug causing Resident Evil 2 & Devil May Cry 5 to stop rendering geometry (thanks to Schwing for identifying the faulty API and finding a workaround)
Avoid potential crashes if Nvidia remove their stereo calls from nvapi in the future
"undecipherable custom data"
If a game includes any custom data in their shaders (Project Cars is known to do this) it can now be disassembled and reassembled (as a hexdump) by enabling disassemble_undecipherable_custom_data=1 in the d3dx.ini. This will also fix issues where the presence of these could cause a shader to disassemble incorrectly.
It's not clear what this is (by definition), whether it is important, or even if it could cause issues - but we are taking the policy of including it by default so you can see it in the assembly and decide what to do with it yourself, and as such the option is enabled in the template d3dx.ini.
Indirect Draw Calls
Frame Analysis will now log the hash of indirect parameter buffers. If the game uses these (e.g. for particle effects) you may need to force them to mono with:
ShaderOverrides/Regex command lists can now replace the indirect buffer with "this = ...", e.g. "this = mono copy this"
Added support to issue DrawIndexedInstancedIndirect, DrawInstancedIndirect or DispatchIndirect calls of our own, which can be useful to have one custom shader decide how many invocations another custom shader will run, e.g.:
Will now set the working directory if launch is set to the game's executable (fixes some games not launching automatically)
If launch option is in use but the game takes a while to spawn it will now display a message indicating that the game can be launched manually (for cases where we have assumed a game is only available on Steam that is later released through some other distribution channel, since some users assumed the Steam launch was required when it actually is not)
Crash Handler
3DMigoto now includes an optional crash handler that can be enabled with crash=1 under [Logging]. If the game crashes while this is enabled 3DMigoto will sound an SOS, flush the log file (possibly replacing the need for unbuffered=1 to get valid crash debug logs in some cases) and write out a minidump file that can be opened in a debugger to find out what happened (many games already do this themselves, but not all).
If the game should hang instead of crash you can attempt to manually invoke the crash handler to write out a minidump file by holding Ctrl+Alt+F11 for five seconds (crash=1 must have been enabled in advance). If that doesn't work you can always use Task Manager to dump the process as usual.
Misc
handling=skip and draw=from_caller now work with compute shaders
Operands added to access remaining draw arguments (in addition to the existing vertex_count, index_count & instance_count): first_vertex, first_index, first_instance, thread_group_count_x, thread_group_count_y, thread_group_count_z, indirect_offset, draw_type
draw_type will be one of: N/A=0, Draw=1, DrawIndexed=2, DrawInstanced=3, DrawIndexedInstanced=4, DrawInstancedIndirect=5, DrawIndexedInstancedIndirect=6, DrawAuto=7, Dispatch=8, DispatchIndirect=9
Arguments passed to draw/dispatch commands are now expressions and can be calculated live, e.g. to launch a compute shader with thread groups for each 16x16 block (calculated from the currently assigned o0 - fetching dimensions of arbitrary resources is still on my TODO list):
Frame analysis log will now indicate any resources that failed to create (check the d3d11_log.txt to find out why)
Fix certain resources failing to create due to incompatible combination of bind+misc flags
[Resource] sections may now override misc_flags if required (usually should not be)
ShaderUsage.txt now expands bind_flags, misc_flags and cpu_access_flags into words instead of numbers (the same words that can be used when matching these in fuzzy TextureOverrides, or when overriding them in Resource sections)
TextureOverride matches will now include the resource description in the d3d11_log.txt
Shaders decompiled via export_hlsl now use our disassembly fixup path, which should fix any floating point precision issues in these. Shaders decompiled via hunting already used the precision fixup.
Dropped support for the broken marking_mode=zero
Refactored and fixed numerous issues in the "big scary shader replacement routine" that could be used to frighten small children. If you see any new bugs loading shaders out of ShaderFixes, exporting shaders to ShaderCache or using Chiri's old HLSL auto-fixes* it means the Bogeyman got me ;-)
* These auto-fixes may be dropped at some point in the future - if anyone is using them please let me know.
@NVIDIA
seriously you want to cut the 3D tap?
These guys have more games running in 3D than in SLI (official)...Please reconsider
@DarkStarSword
Awesome job as always
i7 4970k@4.5Ghz, SLI GTX1080Ti Aorus Gigabyte Xtreme, 16GB G Skill 2400hrz, 3*PG258Q in 3D surround.
[quote="DarkStarSword"]Included Files Conditional on 3D Vision
Included files can now be marked to be skipped if 3D Vision is disabled in the control panel (or otherwise not supported on the user's system) by adding a "condition = stereo_available" line at the top of the file, before any sections. This will skip the entire ini file, including any global variable, Resource, CustomShader and CommandList definitions, so be wary of refering to them from other ini files that do not also have this condition.
Note that it is important to use "stereo_available" here, and not "stereo_active" as "stereo_available" refers to the control panel setting, while "stereo_active" refers to whether 3D Vision is active at this very moment in time, and only "stereo_available" is guaranteed to be statically evaluatable when the ini file is included (this line is evaluated as an expression, but must be statically evaluatable).
If you wish to disable something when 3D Vision is only temporarily inactive you should do so in a command list instead (the command list optimiser can still eliminate entire if blocks that depend on stereo_active when 3D Vision is disabled in the control panel).[/quote]
I believe that this is geared towards 2D modders that use 3Dmigoto?
Or is it a start of a stereoscopic ecosystem outside of Nvidia's drivers?
DarkStarSword said:Included Files Conditional on 3D Vision
Included files can now be marked to be skipped if 3D Vision is disabled in the control panel (or otherwise not supported on the user's system) by adding a "condition = stereo_available" line at the top of the file, before any sections. This will skip the entire ini file, including any global variable, Resource, CustomShader and CommandList definitions, so be wary of refering to them from other ini files that do not also have this condition.
Note that it is important to use "stereo_available" here, and not "stereo_active" as "stereo_available" refers to the control panel setting, while "stereo_active" refers to whether 3D Vision is active at this very moment in time, and only "stereo_available" is guaranteed to be statically evaluatable when the ini file is included (this line is evaluated as an expression, but must be statically evaluatable).
If you wish to disable something when 3D Vision is only temporarily inactive you should do so in a command list instead (the command list optimiser can still eliminate entire if blocks that depend on stereo_active when 3D Vision is disabled in the control panel).
I believe that this is geared towards 2D modders that use 3Dmigoto?
Or is it a start of a stereoscopic ecosystem outside of Nvidia's drivers?
[quote="D-Man11"]I believe that this is geared towards 2D modders that use 3Dmigoto?
Or is it a start of a stereoscopic ecosystem outside of Nvidia's drivers?[/quote]
It's for cases where one of our 3D Vision mods might be used to provide something useful outside of 3D Vision as well, such as disabling post-processing, annoying crosshairs, etc. and that people without 3D Vision won't have to pay any performance cost of the 3D Vision part of the mod (a lot of Cyclopes seem to have lower spec systems than ours and complain about fps hits). I'm specifically using it in the DOA6 mod so that the costume modding community doesn't go and release their own 3DMigoto based mods that become annoying to combine with mine for people who want to use both.
If we later support a stereo backend other than 3D Vision, "stereo_available" would count for that as well.
D-Man11 said:I believe that this is geared towards 2D modders that use 3Dmigoto?
Or is it a start of a stereoscopic ecosystem outside of Nvidia's drivers?
It's for cases where one of our 3D Vision mods might be used to provide something useful outside of 3D Vision as well, such as disabling post-processing, annoying crosshairs, etc. and that people without 3D Vision won't have to pay any performance cost of the 3D Vision part of the mod (a lot of Cyclopes seem to have lower spec systems than ours and complain about fps hits). I'm specifically using it in the DOA6 mod so that the costume modding community doesn't go and release their own 3DMigoto based mods that become annoying to combine with mine for people who want to use both.
If we later support a stereo backend other than 3D Vision, "stereo_available" would count for that as well.
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
Hi
I'm not sure if this is the right place to ask but I am running into a bit of a problem.
Using the analyse frame function with dump_tex gets me everything the game is using except volume/3d textures. Every entry in shaderusage that is type=Texture3D doesn't dump.
Is there a setting that I should enable to get them?
I'm not sure if this is the right place to ask but I am running into a bit of a problem.
Using the analyse frame function with dump_tex gets me everything the game is using except volume/3d textures. Every entry in shaderusage that is type=Texture3D doesn't dump.
Is there a setting that I should enable to get them?
Frame analysis can currently only dump buffers and 2D textures - not 1D or 3D textures (it's on my TODO list), but because the nvapi reverse stereo blit only works with 2D textures, 1D and 3D textures dumped through frame analysis would only ever be mono.
If you just want to examine them to create a 3D fix (especially if you need to examine them in stereo 3D), use this debug shader:
[url]https://github.com/DarkStarSword/3d-fixes/tree/master/custom_shader_debug_volume[/url]
It will render each slice of a 3D texture to the screen, and supports stereo volume buffers so you can comare each of the slices left & right views live (these screenshots are from the original version for Far Cry Primal that also shows shadow maps on the right - the above debug shader would just show the volumetric buffer on the left):
[url=http://darkstarsword.net/screenshots/FCPrimal/fcprimal%20-%202016-03-05%20-%20165238.0.jps][img]http://darkstarsword.net/screenshots/FCPrimal/fcprimal%20-%202016-03-05%20-%20165238.0.jps[/img][/url]
[url=http://darkstarsword.net/screenshots/FCPrimal/fcprimal%20-%202016-03-07%20-%20005832.0.jps][img]http://darkstarsword.net/screenshots/FCPrimal/fcprimal%20-%202016-03-07%20-%20005832.0.jps[/img][/url]
Drop it in your ShaderFixes and use it like this, setting the shader hash and target resource you wish to examine (example from DOA6):
[code]
[Include]
; must be before 3dvision2sbs shader
include = ShaderFixes\debug_volume.ini
[ShaderOverrideVolumeFogCS]
hash = d1d67e56bd5e656f
post Resource\debug_volume\Volume = ref cs-u0
; Make it brighter:
;post $\debug_volume\amplify = 100
; Scale the size down if the entire thing doesn't fit on the screen:
;post $\debug_volume\scale = 1/3
[/code]
If you specifically want to dump them to a file on disk let me know and I'll bump the priority of that one on my TODO list up a little.
Frame analysis can currently only dump buffers and 2D textures - not 1D or 3D textures (it's on my TODO list), but because the nvapi reverse stereo blit only works with 2D textures, 1D and 3D textures dumped through frame analysis would only ever be mono.
It will render each slice of a 3D texture to the screen, and supports stereo volume buffers so you can comare each of the slices left & right views live (these screenshots are from the original version for Far Cry Primal that also shows shadow maps on the right - the above debug shader would just show the volumetric buffer on the left):
Drop it in your ShaderFixes and use it like this, setting the shader hash and target resource you wish to examine (example from DOA6):
[Include]
; must be before 3dvision2sbs shader
include = ShaderFixes\debug_volume.ini
[ShaderOverrideVolumeFogCS]
hash = d1d67e56bd5e656f
post Resource\debug_volume\Volume = ref cs-u0
; Make it brighter:
;post $\debug_volume\amplify = 100
; Scale the size down if the entire thing doesn't fit on the screen:
;post $\debug_volume\scale = 1/3
If you specifically want to dump them to a file on disk let me know and I'll bump the priority of that one on my TODO list up a little.
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
Thanks for the quick reply. But the main issue is replacing a 3d texture. I may have messed up my initial attempt so let me know if 3dmigoto can already do this. Otherwise I'll make another stab at this when I have time.
The issue with the game I'm working on is kind of a weird one. They are using a 3d texture to store a bayer dither for reducing the banding in the sky. It doesnt do a good job and this game has some of the worst banding I've ever seen.
However the game has a mods on mode and through that I was able to change the dither texture to a blue noise 3d texture that pretty much eliminates this banding issue. The only problem is mods on mode doesnt work with online, and most of this games playerbase is multiplayer. 3dmigoto works fine with online and the devs have even semiofficially endorsed it.
So I've made a fix for this game that rectifies a major visual issue but its irrelevant except to the few people who play singleplayer. If I can get this working with 3dmigoto then a really ugly issue is solved for everyone. This is a flight sim btw so you can imagine just what an issue banding in the sky is.
Thanks for the quick reply. But the main issue is replacing a 3d texture. I may have messed up my initial attempt so let me know if 3dmigoto can already do this. Otherwise I'll make another stab at this when I have time.
The issue with the game I'm working on is kind of a weird one. They are using a 3d texture to store a bayer dither for reducing the banding in the sky. It doesnt do a good job and this game has some of the worst banding I've ever seen.
However the game has a mods on mode and through that I was able to change the dither texture to a blue noise 3d texture that pretty much eliminates this banding issue. The only problem is mods on mode doesnt work with online, and most of this games playerbase is multiplayer. 3dmigoto works fine with online and the devs have even semiofficially endorsed it.
So I've made a fix for this game that rectifies a major visual issue but its irrelevant except to the few people who play singleplayer. If I can get this working with 3dmigoto then a really ugly issue is solved for everyone. This is a flight sim btw so you can imagine just what an issue banding in the sky is.
Although 3DMigoto can't dump out a 3D texture in frame analysis as yet, it should be able to load one from a properly formatted .dds file (the DirectXTK library we use to read them does support this), and from there you should be able to follow standard texture replacement procedures in nearly the same way as for a 2D texture - the biggest difference will be how you get the hash, since frame analysis won't dump it out you won't be able to get it from the filename, but you should be able to find it in the frame analysis log file (look for "Skipped dumping Texture3D: <filename>") and/or ShaderUsage.txt, but other than that it should work the same. If you haven't done a texture swap before, it generally follows this form (though there are other variations):
[code]
[ShaderOverrideSky]
; Fill in either the pixel or vertex shader hash the texture is used with:
hash = .......
; Fill in the texture slot that the texture is in:
checktextureoverride = ps-t10
[TextureOverrideBayerDither]
; Original texture hash you want to replace:
hash = .......
; "this" will be whatever slot the checktextureoverride was used on:
this = ResourceReplaceDither
[ResourceReplaceDither]
filename = replace_dither.dds
[/code]
I'm not entirely sure what software can write to a 3D dds file though (I don't see any options to do so in MS texconv), and this is a code path that I don't think anyone has ever tested, so if you do try it let me know how you go.
Although 3DMigoto can't dump out a 3D texture in frame analysis as yet, it should be able to load one from a properly formatted .dds file (the DirectXTK library we use to read them does support this), and from there you should be able to follow standard texture replacement procedures in nearly the same way as for a 2D texture - the biggest difference will be how you get the hash, since frame analysis won't dump it out you won't be able to get it from the filename, but you should be able to find it in the frame analysis log file (look for "Skipped dumping Texture3D: <filename>") and/or ShaderUsage.txt, but other than that it should work the same. If you haven't done a texture swap before, it generally follows this form (though there are other variations):
[ShaderOverrideSky]
; Fill in either the pixel or vertex shader hash the texture is used with:
hash = .......
; Fill in the texture slot that the texture is in:
checktextureoverride = ps-t10
[TextureOverrideBayerDither]
; Original texture hash you want to replace:
hash = .......
; "this" will be whatever slot the checktextureoverride was used on:
this = ResourceReplaceDither
I'm not entirely sure what software can write to a 3D dds file though (I don't see any options to do so in MS texconv), and this is a code path that I don't think anyone has ever tested, so if you do try it let me know how you go.
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
[quote="DarkStarSword"]I'm not entirely sure what software can write to a 3D dds file though (I don't see any options to do so in MS texconv), and this is a code path that I don't think anyone has ever tested, so if you do try it let me know how you go.[/quote]
I know that you can use Gimp to edit DDS files in Skyrim SE, no idea if it's any help. But I figured that I'd mention it. Nvidia also has a viewer, but it can not be used for editing.
[url]https://forums.geforce.com/default/topic/1047668/pc-games/tech-heavy-help-needed-with-skyrim-se-mods/post/5327642/#5327642[/url]
DarkStarSword said:I'm not entirely sure what software can write to a 3D dds file though (I don't see any options to do so in MS texconv), and this is a code path that I don't think anyone has ever tested, so if you do try it let me know how you go.
[quote="D-Man11"]I know that you can use Gimp to edit DDS files in Skyrim SE, no idea if it's any help. But I figured that I'd mention it. Nvidia also has a viewer, but it can not be used for editing.
[url]https://forums.geforce.com/default/topic/1047668/pc-games/tech-heavy-help-needed-with-skyrim-se-mods/post/5327642/#5327642[/url][/quote]
[s]
GIMP's dds plugin is one of the worst available with barely any format support even for 2D textures and definitely lacks 3D / volumetric texture support. It has the advantage of having source available and I have considered overhauling it to improve it's compatibility, but there is only so much time in a day.
The Intel and/or nvidia Photoshop plugins might support it, but I lack a copy of Photoshop to check and all the screenshots I can find only show either 2D or cube mapped textures (but the nvidia one evidently does have a drop down that [i]might[/i] include 3D if only someone had taken a screenshot with it open).
Nvidia's standalone tool is considered obsolete and just crashes for most users (where I define "most" as "happens on both of my computers").
Microsoft's standalone tool doesn't appear to support 3D / volumetric textures.
My own ddsinfo.py script only decodes dds files, and does not support 3D / volumetric textures beyond informing you "Resource Dimension: Texture3D". Adding support for this is certainly possible, but again there's only so much time in one day.
Hand crafting a 3D DDS file with a hex editor is quite doable for small textures (a bayer dither would probably be simple enough to do this), or a 2D (non mip-mapped, non MSAA, not block compressed) Texture Array could be converted into a 3D texture with a hex editor by patching the DDS header to convert the array slices into depth (the 2D array slices should occupy the same space in the file as 3D depth slices).
There might be other options I don't know of with better 3D/volumetric texture support, but the above list covers all the major tools with support for 2D DDS textures.[/s]
I went back and had another look at Microsoft's offerings, and see that they have another tool for 3D DDS files:
https://github.com/Microsoft/DirectXTex/wiki/Texassemble
GIMP's dds plugin is one of the worst available with barely any format support even for 2D textures and definitely lacks 3D / volumetric texture support. It has the advantage of having source available and I have considered overhauling it to improve it's compatibility, but there is only so much time in a day.
The Intel and/or nvidia Photoshop plugins might support it, but I lack a copy of Photoshop to check and all the screenshots I can find only show either 2D or cube mapped textures (but the nvidia one evidently does have a drop down that might include 3D if only someone had taken a screenshot with it open).
Nvidia's standalone tool is considered obsolete and just crashes for most users (where I define "most" as "happens on both of my computers").
Microsoft's standalone tool doesn't appear to support 3D / volumetric textures.
My own ddsinfo.py script only decodes dds files, and does not support 3D / volumetric textures beyond informing you "Resource Dimension: Texture3D". Adding support for this is certainly possible, but again there's only so much time in one day.
Hand crafting a 3D DDS file with a hex editor is quite doable for small textures (a bayer dither would probably be simple enough to do this), or a 2D (non mip-mapped, non MSAA, not block compressed) Texture Array could be converted into a 3D texture with a hex editor by patching the DDS header to convert the array slices into depth (the 2D array slices should occupy the same space in the file as 3D depth slices).
There might be other options I don't know of with better 3D/volumetric texture support, but the above list covers all the major tools with support for 2D DDS textures.
[quote="DarkStarSword"]Although 3DMigoto can't dump out a 3D texture in frame analysis as yet, it should be able to load one from a properly formatted .dds file (the DirectXTK library we use to read them does support this), and from there you should be able to follow standard texture replacement procedures in nearly the same way as for a 2D texture - the biggest difference will be how you get the hash, since frame analysis won't dump it out you won't be able to get it from the filename, but you should be able to find it in the frame analysis log file (look for "Skipped dumping Texture3D: <filename>") and/or ShaderUsage.txt, but other than that it should work the same. If you haven't done a texture swap before, it generally follows this form (though there are other variations):
[code]
[ShaderOverrideSky]
; Fill in either the pixel or vertex shader hash the texture is used with:
hash = .......
; Fill in the texture slot that the texture is in:
checktextureoverride = ps-t10
[TextureOverrideBayerDither]
; Original texture hash you want to replace:
hash = .......
; "this" will be whatever slot the checktextureoverride was used on:
this = ResourceReplaceDither
[ResourceReplaceDither]
filename = replace_dither.dds
[/code]
I'm not entirely sure what software can write to a 3D dds file though (I don't see any options to do so in MS texconv), and this is a code path that I don't think anyone has ever tested, so if you do try it let me know how you go.[/quote]
Thanks for the help. I made a bit of a mistake - the shader that draws the skydome isnt the same shader as the one that does the dithering pass. I used the right shader and now everything works right.
But I have another question; is it possible to do texture replacement with two shaders that are using the same texture? For example shader A and shader B are both using texture X. Can I make shader A use texture X and shader B use texture Y?
DarkStarSword said:Although 3DMigoto can't dump out a 3D texture in frame analysis as yet, it should be able to load one from a properly formatted .dds file (the DirectXTK library we use to read them does support this), and from there you should be able to follow standard texture replacement procedures in nearly the same way as for a 2D texture - the biggest difference will be how you get the hash, since frame analysis won't dump it out you won't be able to get it from the filename, but you should be able to find it in the frame analysis log file (look for "Skipped dumping Texture3D: <filename>") and/or ShaderUsage.txt, but other than that it should work the same. If you haven't done a texture swap before, it generally follows this form (though there are other variations):
[ShaderOverrideSky]
; Fill in either the pixel or vertex shader hash the texture is used with:
hash = .......
; Fill in the texture slot that the texture is in:
checktextureoverride = ps-t10
[TextureOverrideBayerDither]
; Original texture hash you want to replace:
hash = .......
; "this" will be whatever slot the checktextureoverride was used on:
this = ResourceReplaceDither
I'm not entirely sure what software can write to a 3D dds file though (I don't see any options to do so in MS texconv), and this is a code path that I don't think anyone has ever tested, so if you do try it let me know how you go.
Thanks for the help. I made a bit of a mistake - the shader that draws the skydome isnt the same shader as the one that does the dithering pass. I used the right shader and now everything works right.
But I have another question; is it possible to do texture replacement with two shaders that are using the same texture? For example shader A and shader B are both using texture X. Can I make shader A use texture X and shader B use texture Y?
Yeah, you can do that. If you always want the same texture used with each shader you can do so pretty simply:
[code]
[ShaderOverrideX]
hash = .......
ps-t0 = ResourceX
[ResourceX]
filename = x.dds
[ShaderOverrideY]
hash = .......
ps-t0 = ResourceY
[ResourceY]
filename = x.dds
[/code]
If you still need some checks to make sure you are replacing the right texture you can do something like this:
[code]
[ShaderOverrideX]
hash = .......
if ps-t0 == 1234
ps-t0 = ResourceX
endif
[TextureOverrideX]
; The texture you want to replace:
hash = ....
; Make up some unique number >= 2 to identify this texture:
filter_index = 1234
[ResourceX]
filename = x.dds
[ShaderOverrideY]
hash = .......
if ps-t0 == 5432
ps-t0 = ResourceY
endif
[TextureOverrideX]
; The texture you want to replace:
hash = ....
; Make up some unique number >= 2 to identify this texture:
filter_index = 5432
[ResourceY]
filename = x.dds
[/code]
Hello. Is somebody know what should I do to remove black background from cursor texture in software mouse mode. Can I override cursor texture with 'cursor.dds' file to remove this issue?
Hello. Is somebody know what should I do to remove black background from cursor texture in software mouse mode. Can I override cursor texture with 'cursor.dds' file to remove this issue?
ShaderRegex now supports caching if cache_shaders=1 to eliminate stuttering and make config reload (that does not alter any ShaderRegex sections) *much* faster, and is now recommended to enable even while developing a fix, not just for release (this option also makes CustomShader reloads much faster).
The cached files will be stored in ShaderCache and have _regex in their name (*_regex.dat, *_regex.bin) and 3DMigoto will handle updating these on demand as necessary. Note that you will see .dat files appear for shaders that are not matched by ShaderRegex as well, as these tell 3DMigoto not to bother checking them again (unless a ShaderRegex section is altered).
You can also export the patched assembly by turning on export_fixed=1, but note that since these files are updated on demand there may be stale assembly files present from outdated ShaderRegex patterns. If you need to make sure you are only looking at up to date assembly files, delete all the *_regex.* files in ShaderCache and reload the config.
A new marking action has been added (marking_actions=regex) that will dump the ShaderRegex patched shaders rather than the original assembly. If both regex and asm/hlsl are in use regex will take priority for applicable shaders and asm/hlsl will handle everything else. Note that any command lists from the ShaderRegex sections will stop applying after dumping a shader, and a warning will appear indicating if this has happened to remind you that you may need to add them to the [ShaderOverride] instead.
The patched shaders are no longer logged in d3d11_log.txt in favour of the above two methods to find it.
A new patch_assembly_cb_offsets=1 option has been added to change the constant/structured buffer offsets in the assembly into indices (offset divided by 16) and components to make these easier to match up by eye, and to make certain ShaderRegex matches on these easier/possible. This option may break existing ShaderRegex patterns, so if it is missing in the d3dx.ini (e.g. due to a fix being upgraded) it will not be enabled, but it is included in the new template d3dx.ini in anticipation of being generally more useful than the previous output (existing dumped shaders will not be updated).
This means instead of the old Offset & (optional) Size, you will now see Index and Components:
Or if the entry was missing the size field (embedded structures) only the starting index and component will be shown:
Matrices or other items occupying multiple indices will be expanded out a little differently. Items occupying 2-4 complete indices (such as matrices) will have all indices spelled out, allowing each index to be matched with a ShaderRegex capture group to be used in either the pattern or replace sections. Items occupying more than four indices or that do not completely occupy the final index will be expanded into a range instead:
If using a regex pattern to match these note that the number of spaces after "Index:" is variable, as are the number of spaces before and after "Components:". Matrices that have been expanded will only have a single space separating their indices, so a pattern such as the following can match these reliably:
And you might then use these in a ShaderRegex replace section like:
Note that assembly found via the comment block in HLSL shaders will not be patched, so you should prefer getting assembly shaders via marking_actions=asm or export_shaders=1, especially if you intend to write a ShaderRegex pattern for them.
To have cmd_Decompiler produce this new format, pass it --patch-cb-offsets when disassembling a shader.
Included files can now be marked to be skipped if 3D Vision is disabled in the control panel (or otherwise not supported on the user's system) by adding a "condition = stereo_available" line at the top of the file, before any sections. This will skip the entire ini file, including any global variable, Resource, CustomShader and CommandList definitions, so be wary of refering to them from other ini files that do not also have this condition.
Note that it is important to use "stereo_available" here, and not "stereo_active" as "stereo_available" refers to the control panel setting, while "stereo_active" refers to whether 3D Vision is active at this very moment in time, and only "stereo_available" is guaranteed to be statically evaluatable when the ini file is included (this line is evaluated as an expression, but must be statically evaluatable).
If you wish to disable something when 3D Vision is only temporarily inactive you should do so in a command list instead (the command list optimiser can still eliminate entire if blocks that depend on stereo_active when 3D Vision is disabled in the control panel).
You can now override the namespace used with an included ini file, so that you can use a well known name to access their variables, Resources, etc. from outside the file rather than the filename. This can be useful for environments where the user may drop in extra mods and may not be so good at following instructions about where to install the mods to allow these to work wherever the user placed them, or just to reduce the verbosity when accessing your own resources, e.g. you could use the notification mechanism in the help text shader (that has namespace=help) like:
However, due inexperienced modders copy+pasting someone else' mod as a starting point or two independent mods happening to choose the same namespace it is possible that a namespace collision may occur (there is no explicit protection against this, though duplicate variables & prefixed section names will trigger warnings), so this is only recommended for use in ini files that provide variables/Resources/shaders/command lists intended to be accessed from other files. Simpler mods should not override the namespace to ensure that a unique value (their filename) will be used.
If switching an existing mod that other mods already depend on to use a well known namespace, consider using the well known namespace you expected to be used previously (i.e. the path & filename of where you previously documented the mod should be installed) to fulfil both backwards compatibility and future protection against PEBKAC users.
The [Profile] section now supports all setting names from Nvidia Profile Inspector (as of 2.3.0.2), eliminating the need to use the setting hex IDs for a large number of settings. As before you can discover the name for a Hex setting by adding the hex setting to the [Profile] section, installing the profile then examining the d3d11_log.txt to see what 3DMigoto decoded it as.
Notably APP_COMPAT_SHIM=2 can work around threading bugs (that manifest as hangs and/or driver crashes) in certain games (RE2, RE5, DMC5) - special thanks to Kaimasta for discovering this one :)
You can now test partner shaders in the same way as Texture Filtering. "vs" "hs" "ds" "gs" "ps" and "cs" can be used as operands in any expression and will evaluate to:
The no pixel shader bound case is useful to detect depth only passes, such as shadow maps or occlusion culling (depending on the game), or to detect one possible situation where the driver heuristics may not run a shader for the left eye.
The old deprecated partner= option has been removed from the d3dx.ini template, and the deprecation warning has been updated to suggest using this new form instead. The other alternate form setting variables from the partner's command list still works, and may or may not perform slightly faster than this new form so don't worry about switching if you are already using that (this new form has the advantage of not having any order constraints, and allows for a no shader bound test).
If a game includes any custom data in their shaders (Project Cars is known to do this) it can now be disassembled and reassembled (as a hexdump) by enabling disassemble_undecipherable_custom_data=1 in the d3dx.ini. This will also fix issues where the presence of these could cause a shader to disassemble incorrectly.
It's not clear what this is (by definition), whether it is important, or even if it could cause issues - but we are taking the policy of including it by default so you can see it in the assembly and decide what to do with it yourself, and as such the option is enabled in the template d3dx.ini.
These particle effects are known to also write to index and/or vertex buffers on the GPU, so you may also need to force those to mono:
(Only lightly tested - please report any issues)
3DMigoto now includes an optional crash handler that can be enabled with crash=1 under [Logging]. If the game crashes while this is enabled 3DMigoto will sound an SOS, flush the log file (possibly replacing the need for unbuffered=1 to get valid crash debug logs in some cases) and write out a minidump file that can be opened in a debugger to find out what happened (many games already do this themselves, but not all).
If the game should hang instead of crash you can attempt to manually invoke the crash handler to write out a minidump file by holding Ctrl+Alt+F11 for five seconds (crash=1 must have been enabled in advance). If that doesn't work you can always use Task Manager to dump the process as usual.
EDIT: It looks like this was incorrectly merged. The crash handler is included, but has some issues that were supposed to have been polished out before release.
draw_type will be one of: N/A=0, Draw=1, DrawIndexed=2, DrawInstanced=3, DrawIndexedInstanced=4, DrawInstancedIndirect=5, DrawIndexedInstancedIndirect=6, DrawAuto=7, Dispatch=8, DispatchIndirect=9
* These auto-fixes may be dropped at some point in the future - if anyone is using them please let me know.
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
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
@NVIDIA
seriously you want to cut the 3D tap?
These guys have more games running in 3D than in SLI (official)...Please reconsider
@DarkStarSword
Awesome job as always
i7 4970k@4.5Ghz, SLI GTX1080Ti Aorus Gigabyte Xtreme, 16GB G Skill 2400hrz, 3*PG258Q in 3D surround.
I believe that this is geared towards 2D modders that use 3Dmigoto?
Or is it a start of a stereoscopic ecosystem outside of Nvidia's drivers?
It's for cases where one of our 3D Vision mods might be used to provide something useful outside of 3D Vision as well, such as disabling post-processing, annoying crosshairs, etc. and that people without 3D Vision won't have to pay any performance cost of the 3D Vision part of the mod (a lot of Cyclopes seem to have lower spec systems than ours and complain about fps hits). I'm specifically using it in the DOA6 mod so that the costume modding community doesn't go and release their own 3DMigoto based mods that become annoying to combine with mine for people who want to use both.
If we later support a stereo backend other than 3D Vision, "stereo_available" would count for that as well.
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
Thanks for everything and this reply
I'm not sure if this is the right place to ask but I am running into a bit of a problem.
Using the analyse frame function with dump_tex gets me everything the game is using except volume/3d textures. Every entry in shaderusage that is type=Texture3D doesn't dump.
Is there a setting that I should enable to get them?
If you just want to examine them to create a 3D fix (especially if you need to examine them in stereo 3D), use this debug shader:
https://github.com/DarkStarSword/3d-fixes/tree/master/custom_shader_debug_volume
It will render each slice of a 3D texture to the screen, and supports stereo volume buffers so you can comare each of the slices left & right views live (these screenshots are from the original version for Far Cry Primal that also shows shadow maps on the right - the above debug shader would just show the volumetric buffer on the left):
Drop it in your ShaderFixes and use it like this, setting the shader hash and target resource you wish to examine (example from DOA6):
If you specifically want to dump them to a file on disk let me know and I'll bump the priority of that one on my TODO list up a little.
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
The issue with the game I'm working on is kind of a weird one. They are using a 3d texture to store a bayer dither for reducing the banding in the sky. It doesnt do a good job and this game has some of the worst banding I've ever seen.
However the game has a mods on mode and through that I was able to change the dither texture to a blue noise 3d texture that pretty much eliminates this banding issue. The only problem is mods on mode doesnt work with online, and most of this games playerbase is multiplayer. 3dmigoto works fine with online and the devs have even semiofficially endorsed it.
So I've made a fix for this game that rectifies a major visual issue but its irrelevant except to the few people who play singleplayer. If I can get this working with 3dmigoto then a really ugly issue is solved for everyone. This is a flight sim btw so you can imagine just what an issue banding in the sky is.
I'm not entirely sure what software can write to a 3D dds file though (I don't see any options to do so in MS texconv), and this is a code path that I don't think anyone has ever tested, so if you do try it let me know how you go.
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
I know that you can use Gimp to edit DDS files in Skyrim SE, no idea if it's any help. But I figured that I'd mention it. Nvidia also has a viewer, but it can not be used for editing.
https://forums.geforce.com/default/topic/1047668/pc-games/tech-heavy-help-needed-with-skyrim-se-mods/post/5327642/#5327642
GIMP's dds plugin is one of the worst available with barely any format support even for 2D textures and definitely lacks 3D / volumetric texture support. It has the advantage of having source available and I have considered overhauling it to improve it's compatibility, but there is only so much time in a day.
The Intel and/or nvidia Photoshop plugins might support it, but I lack a copy of Photoshop to check and all the screenshots I can find only show either 2D or cube mapped textures (but the nvidia one evidently does have a drop down that might include 3D if only someone had taken a screenshot with it open).
Nvidia's standalone tool is considered obsolete and just crashes for most users (where I define "most" as "happens on both of my computers").
Microsoft's standalone tool doesn't appear to support 3D / volumetric textures.
My own ddsinfo.py script only decodes dds files, and does not support 3D / volumetric textures beyond informing you "Resource Dimension: Texture3D". Adding support for this is certainly possible, but again there's only so much time in one day.
Hand crafting a 3D DDS file with a hex editor is quite doable for small textures (a bayer dither would probably be simple enough to do this), or a 2D (non mip-mapped, non MSAA, not block compressed) Texture Array could be converted into a 3D texture with a hex editor by patching the DDS header to convert the array slices into depth (the 2D array slices should occupy the same space in the file as 3D depth slices).
There might be other options I don't know of with better 3D/volumetric texture support, but the above list covers all the major tools with support for 2D DDS textures.
I went back and had another look at Microsoft's offerings, and see that they have another tool for 3D DDS files:
https://github.com/Microsoft/DirectXTex/wiki/Texassemble
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
Thanks for the help. I made a bit of a mistake - the shader that draws the skydome isnt the same shader as the one that does the dithering pass. I used the right shader and now everything works right.
But I have another question; is it possible to do texture replacement with two shaders that are using the same texture? For example shader A and shader B are both using texture X. Can I make shader A use texture X and shader B use texture Y?
If you still need some checks to make sure you are replacing the right texture you can do something like this:
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