[quote="lefuneste"][quote="bo3b"]
I don't see any other exceptions. Your crc 1ebdb3925859d5f6-vs.bin I don't see when I run the game and do Instant Action or first campaign.
[/quote]
It's because this shader is coming from the 2.0 alpha version. Unfortunately for the moment, this version is linked to a map that is not free ($50 !) and protected, so it is not worth to download it...
I though that the last 1.5.3 version used the same shader than the 2.0, because when they deploy the last 1.5.2 => 1.5.3 update, I had to rename all the fixed shaders with the same names used for 2.0 version. But I just checked: the problem with the night illumination is not present on 1.5.3 and is on the 2.0...
I also checked that, even if there are a lot of shaders with the " Known bad code for instruction", all are now dumped.
I am sorry for having make you spend your time...I know that I am annoying and clumsy, but as you have DCS on your PC, maybe you could have a look on my problem with the usage of depth buffer for label filtering ?
And I also did not manage to solve efficiently the problem with the horizon (use free flight with Su25T and roll plane to the right or the left to see it). I had to find from another shader the view matrix and add additional fix for left or right eye regarding the roll angle of the plane). I'm not proud of that fix...
In which mission did you find the glitching shader when at night ?[/quote]
OK, no problem, it was worth downloading to find out that it actually supports DK2 directly. I did not know that.
For that night shader, I think I made my own mission, then was able to choose what time of day to fly, and I chose middle of the night. Apparently there were bad guys though, as they blew me up while I was shader hunting. Not sure, only ran it to look for these problems.
bo3b said:
I don't see any other exceptions. Your crc 1ebdb3925859d5f6-vs.bin I don't see when I run the game and do Instant Action or first campaign.
It's because this shader is coming from the 2.0 alpha version. Unfortunately for the moment, this version is linked to a map that is not free ($50 !) and protected, so it is not worth to download it...
I though that the last 1.5.3 version used the same shader than the 2.0, because when they deploy the last 1.5.2 => 1.5.3 update, I had to rename all the fixed shaders with the same names used for 2.0 version. But I just checked: the problem with the night illumination is not present on 1.5.3 and is on the 2.0...
I also checked that, even if there are a lot of shaders with the " Known bad code for instruction", all are now dumped.
I am sorry for having make you spend your time...I know that I am annoying and clumsy, but as you have DCS on your PC, maybe you could have a look on my problem with the usage of depth buffer for label filtering ?
And I also did not manage to solve efficiently the problem with the horizon (use free flight with Su25T and roll plane to the right or the left to see it). I had to find from another shader the view matrix and add additional fix for left or right eye regarding the roll angle of the plane). I'm not proud of that fix...
In which mission did you find the glitching shader when at night ?
OK, no problem, it was worth downloading to find out that it actually supports DK2 directly. I did not know that.
For that night shader, I think I made my own mission, then was able to choose what time of day to fly, and I chose middle of the night. Apparently there were bad guys though, as they blew me up while I was shader hunting. Not sure, only ran it to look for these problems.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607 Latest 3Dmigoto Release Bo3b's School for ShaderHackers
I have another question. In the d3dx file, under [Rendering], how do you use this:
; Position variables to correct in pixel shaders.
;fix_ObjectPosition1=PointPositionAndInverseRadius
;fix_ObjectPosition1Multiplier=1, (stereoScreenRes.x/stereoScreenRes.y)*0.5, -0.5
I'm trying to make a screen size correction similar to what you'd see in some UE3 fixes. I think the above code is what I need. But I'm not sure how to use this in a shader.
[quote="4everAwake"]I have another question. In the d3dx file, under [Rendering], how do you use this:
[code]; Position variables to correct in pixel shaders.
;fix_ObjectPosition1=PointPositionAndInverseRadius
;fix_ObjectPosition1Multiplier=1, (stereoScreenRes.x/stereoScreenRes.y)*0.5, -0.5[/code]
[/quote]I actually don't know - that's one of the original features from Chiri that I have never touched. It would not surprise me if this does not work any more, but I haven't tried it so I can't say for sure. It will require the shader to be freshly decompiled for it to be applied, as it is (I think) supposed to be used for an automatic adjustment on any newly dumped shaders.
[quote]I'm trying to make a screen size correction similar to what you'd see in some UE3 fixes. I think the above code is what I need. But I'm not sure how to use this in a shader.[/quote]Well, this part I do ;-)
You can define a [ShaderOverride] section for the shader and pass the current resolution width & height in with some IniParams, e.g.
[code]
[ShaderOverrideNeedScreenAdjustment]
hash = ...
x1 = res_width
y1 = res_height
[/code]
I'm using x1 & y1 here, but you can choose any of the 32 available Ini Params (x, x1, x2, ..., x7, ditto for y, z & w). If you are using any of the ones that end in a number the syntax to load it is slightly different:
[code]
float4 res = IniParams.Load(int2(1, 0));
[/code]
Where the first number in the int2 corresponds with the number on the IniParam (the second number is always 0).
If you find the resolution you get is wrong (especially if not using a native resolution), try changing get_resolution_from to depth_stencil.
Notably, in addition to res_width/height there is also rt_width/height, which retuns the dimensions of the currently active render target - in many cases this will be the same as the resolution, but I use this to detect when an off-screen render target is in use and for this type of adjustment it might technically be the correct thing to use... but since it will usually match the resolution it probably won't matter.
The resolution is alternatively available through StereoParams.Load(int2(2, 0)).xy, which is obtained using a different technique again and should give you the resolution that the monitor is being driven at by the card. This is probably always the same as res_width/height when get_resolution_from=swap_chain is in use (but I'm not 100% certain of that - games do too many weird things).
4everAwake said:I have another question. In the d3dx file, under [Rendering], how do you use this:
; Position variables to correct in pixel shaders.
;fix_ObjectPosition1=PointPositionAndInverseRadius
;fix_ObjectPosition1Multiplier=1, (stereoScreenRes.x/stereoScreenRes.y)*0.5, -0.5
I actually don't know - that's one of the original features from Chiri that I have never touched. It would not surprise me if this does not work any more, but I haven't tried it so I can't say for sure. It will require the shader to be freshly decompiled for it to be applied, as it is (I think) supposed to be used for an automatic adjustment on any newly dumped shaders.
I'm trying to make a screen size correction similar to what you'd see in some UE3 fixes. I think the above code is what I need. But I'm not sure how to use this in a shader.
Well, this part I do ;-)
You can define a [ShaderOverride] section for the shader and pass the current resolution width & height in with some IniParams, e.g.
I'm using x1 & y1 here, but you can choose any of the 32 available Ini Params (x, x1, x2, ..., x7, ditto for y, z & w). If you are using any of the ones that end in a number the syntax to load it is slightly different:
float4 res = IniParams.Load(int2(1, 0));
Where the first number in the int2 corresponds with the number on the IniParam (the second number is always 0).
If you find the resolution you get is wrong (especially if not using a native resolution), try changing get_resolution_from to depth_stencil.
Notably, in addition to res_width/height there is also rt_width/height, which retuns the dimensions of the currently active render target - in many cases this will be the same as the resolution, but I use this to detect when an off-screen render target is in use and for this type of adjustment it might technically be the correct thing to use... but since it will usually match the resolution it probably won't matter.
The resolution is alternatively available through StereoParams.Load(int2(2, 0)).xy, which is obtained using a different technique again and should give you the resolution that the monitor is being driven at by the card. This is probably always the same as res_width/height when get_resolution_from=swap_chain is in use (but I'm not 100% certain of that - games do too many weird things).
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
[s]I don't know why, but cache_shaders=1 has no longer any effect. I don't see any bins in the shaders folder.[/s]
Ignore that. It's just me beeing stupid.
[size="M"][center][color="orange"]3DMigoto 1.2.32 is out:[/color]
[url]https://github.com/bo3b/3Dmigoto/releases[/url][/center][/size]
This release is primarily aimed at improving support for CustomShaders to make the side-by-side and top-and-bottom output mode custom shader more universal.
- The custom SBS / TAB shader is included in this release, but is not yet enabled by default (while it undergoes more testing) - uncomment the line in the [Present] section to enable then use F11 to switch modes.
- The following options are added to CustomShader sections to allow the rasterizer state to be overridden:
fill ("solid" / "wireframe"), cull ("none", "front", "back"), front ("clockwise", "counterclockwise"), depth_bias, depth_bias_clamp, slope_scaled_depth_bias, depth_clip_enable, scissor_enable, multisample_enable, antialiased_line_enable
These options correspond to those documented on [url=https://msdn.microsoft.com/en-us/library/windows/desktop/ff476198(v=vs.85).aspx]this MSDN article[/url]. Like the OM blend state, overriding any one of these will override them all back to the defaults from DX, and there is no provision to merge these with any existing state. The most useful option when injecting a full-screen shader is likely to be cull=none so that you don't have to worry about whether the game is using clockwise or counter-clockwise ordering to signify front-facing surfaces, or which is being culled.
- A "topology" option is added to CustomShader sections to define the vertex topology, such as "triangle_strip", "triangle_list", etc. The options correspond to those documented [url=https://msdn.microsoft.com/en-us/library/windows/desktop/ff476189(v=vs.85).aspx]here[/url].
- CustomShader sections will now automatically back up and restore all render targets, depth/stencil targets, UAVs bound to pixel (not compute) shaders and viewports that were bound when they were called. This largely eliminates the need to back these up into custom resources manually, and solves certain complications that could arise if a pixel shader was using UAVs. Textures are not backed up.
- Each shader type in a CustomShader section can now be set to "null" to explicitly unbind it from the pipeline. This is most useful to ensure that there are no tesselation or geometry shaders still bound. This must be done explicitly, which allows these sections to continue to inherit the state from the game if desired (e.g. as I did in The Witness).
- Resource copying has gained a "set_viewport" keyword, which sets the view-port to the dimensions of the resource being copied, which ensures that it can be drawn to if used as a render target (necessary for custom shaders to work in MGSV from the present call).
- Resource copying has gained a "no_view_cache" keyword, which disables caching any view created through that operation. This is necessary to eliminate a glitch in Mad Max that occurs if a render target view of the back buffer exists during a certain point of it's initialisation.
This release also includes some bug fixes:
- Fixes an issue creating depth/stencil views through resource copying
- Fixes the placement of the overlay in some games (e.g. MGSV)
This release is primarily aimed at improving support for CustomShaders to make the side-by-side and top-and-bottom output mode custom shader more universal.
- The custom SBS / TAB shader is included in this release, but is not yet enabled by default (while it undergoes more testing) - uncomment the line in the [Present] section to enable then use F11 to switch modes.
- The following options are added to CustomShader sections to allow the rasterizer state to be overridden:
fill ("solid" / "wireframe"), cull ("none", "front", "back"), front ("clockwise", "counterclockwise"), depth_bias, depth_bias_clamp, slope_scaled_depth_bias, depth_clip_enable, scissor_enable, multisample_enable, antialiased_line_enable
These options correspond to those documented on this MSDN article. Like the OM blend state, overriding any one of these will override them all back to the defaults from DX, and there is no provision to merge these with any existing state. The most useful option when injecting a full-screen shader is likely to be cull=none so that you don't have to worry about whether the game is using clockwise or counter-clockwise ordering to signify front-facing surfaces, or which is being culled.
- A "topology" option is added to CustomShader sections to define the vertex topology, such as "triangle_strip", "triangle_list", etc. The options correspond to those documented here.
- CustomShader sections will now automatically back up and restore all render targets, depth/stencil targets, UAVs bound to pixel (not compute) shaders and viewports that were bound when they were called. This largely eliminates the need to back these up into custom resources manually, and solves certain complications that could arise if a pixel shader was using UAVs. Textures are not backed up.
- Each shader type in a CustomShader section can now be set to "null" to explicitly unbind it from the pipeline. This is most useful to ensure that there are no tesselation or geometry shaders still bound. This must be done explicitly, which allows these sections to continue to inherit the state from the game if desired (e.g. as I did in The Witness).
- Resource copying has gained a "set_viewport" keyword, which sets the view-port to the dimensions of the resource being copied, which ensures that it can be drawn to if used as a render target (necessary for custom shaders to work in MGSV from the present call).
- Resource copying has gained a "no_view_cache" keyword, which disables caching any view created through that operation. This is necessary to eliminate a glitch in Mad Max that occurs if a render target view of the back buffer exists during a certain point of it's initialisation.
This release also includes some bug fixes:
- Fixes an issue creating depth/stencil views through resource copying
- Fixes the placement of the overlay in some games (e.g. MGSV)
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 DarkStarSword,
Really awesome update there! I'm a bit out of the loop with SBS support added in the latest 3DMigoto.
I am still working on Rise Of Tomb Raider fix. The fix started with 3DMigoto v.1.2.27.
Is there a reason to update to this version? It is posible some things are not compatible? Or should the upgrade just be a process of copy/paste the new DLL?:) I figured you are the best person to ask this:)
Really awesome update there! I'm a bit out of the loop with SBS support added in the latest 3DMigoto.
I am still working on Rise Of Tomb Raider fix. The fix started with 3DMigoto v.1.2.27.
Is there a reason to update to this version? It is posible some things are not compatible? Or should the upgrade just be a process of copy/paste the new DLL?:) I figured you are the best person to ask this:)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Would someone please take a look at that vertex shader below and try to help me to understand why the car models exploded after dumping that shader :) ?
Also, compiling that shader takes approximately 2 seconds.
// ---- Created with 3Dmigoto v1.2.31 on Sun Feb 28 14:20:44 2016
@oomek: Below is how I usually fix this bug with the wrong matrix index. The problem is the 3x4 matrix instead of the usual 4x4 matrix. The /3 part is trying to restore the proper index, but misses. The *3 then /3 in the ASM is just normal indexing, so I remove them both.
Try this version, as the array indices are correct in ASM. Not sure it's the same as yours, and might still have an alternate bug, but worth a try.
// ---- Created with 3Dmigoto v1.2.31 on Sun Feb 28 14:20:44 2016
[quote="helifax"]Hi DarkStarSword,
Really awesome update there! I'm a bit out of the loop with SBS support added in the latest 3DMigoto.
I am still working on Rise Of Tomb Raider fix. The fix started with 3DMigoto v.1.2.27.
Is there a reason to update to this version? It is posible some things are not compatible? Or should the upgrade just be a process of copy/paste the new DLL?:) I figured you are the best person to ask this:)[/quote]If you don't need the new features it's not critical to update. It might be worthwhile doing so anyway so people can use the SBS / TAB support with minimal effort on their part. There are also a couple of bug fixes since 1.2.27 that might be worth updating for, but nothing too major - I fixed a rare crash that may occur while either hunting, track_texture_updates, or expand_region_copy is enabled in multi-threaded games, plus a few other bugs found by static code analysis.
Updating 3DMigoto just needs the new DLLs copied in, though to add SBS & TAB support you will also need the [CustomShader3DVision2SBS] section from the ini, the line in the [Present] section to call it (if you are already using a [Present] section just add that line, otherwise add the whole section), the [KeyChange3DVision2SBSOutputMode] section and the custom vertex & pixel shaders in the ShaderFixes directory.
Generaly speaking we always aim to keep 3DMigoto compatible with existing fixes unless we have a good reason to break them - and if we do, we would bump the second number in the version string to signify that (i.e. 1.0 -> 1.1 was a major rewrite of some core code and re-introduced DXGI support, which broke a lot of games until it stabilised, 1.1 -> 1.2 changed the texture hashes for performance, 1.2 -> 1.3 will also likely be due to changing the texture hashes (for performance in games that need track_texture_updates for texture filtering to work reliably - FC4 in particular would benefit, and I've been holding off adding texture filtering to MGSV until this is ready since I noticed it had the same problem).
I did remove preloading shaders a couple of versions ago, but only because I'm pretty sure no one was using it and I'm pretty sure it had been broken for some time.
Of course there is always the risk that I might inadvertently introduce a bug, but if I do it will most likely be in the features that are under active development, like the resource copying or shader injection code, and just as likely to be fixed a couple of versions later when I notice ;-)
Really awesome update there! I'm a bit out of the loop with SBS support added in the latest 3DMigoto.
I am still working on Rise Of Tomb Raider fix. The fix started with 3DMigoto v.1.2.27.
Is there a reason to update to this version? It is posible some things are not compatible? Or should the upgrade just be a process of copy/paste the new DLL?:) I figured you are the best person to ask this:)
If you don't need the new features it's not critical to update. It might be worthwhile doing so anyway so people can use the SBS / TAB support with minimal effort on their part. There are also a couple of bug fixes since 1.2.27 that might be worth updating for, but nothing too major - I fixed a rare crash that may occur while either hunting, track_texture_updates, or expand_region_copy is enabled in multi-threaded games, plus a few other bugs found by static code analysis.
Updating 3DMigoto just needs the new DLLs copied in, though to add SBS & TAB support you will also need the [CustomShader3DVision2SBS] section from the ini, the line in the [Present] section to call it (if you are already using a [Present] section just add that line, otherwise add the whole section), the [KeyChange3DVision2SBSOutputMode] section and the custom vertex & pixel shaders in the ShaderFixes directory.
Generaly speaking we always aim to keep 3DMigoto compatible with existing fixes unless we have a good reason to break them - and if we do, we would bump the second number in the version string to signify that (i.e. 1.0 -> 1.1 was a major rewrite of some core code and re-introduced DXGI support, which broke a lot of games until it stabilised, 1.1 -> 1.2 changed the texture hashes for performance, 1.2 -> 1.3 will also likely be due to changing the texture hashes (for performance in games that need track_texture_updates for texture filtering to work reliably - FC4 in particular would benefit, and I've been holding off adding texture filtering to MGSV until this is ready since I noticed it had the same problem).
I did remove preloading shaders a couple of versions ago, but only because I'm pretty sure no one was using it and I'm pretty sure it had been broken for some time.
Of course there is always the risk that I might inadvertently introduce a bug, but if I do it will most likely be in the features that are under active development, like the resource copying or shader injection code, and just as likely to be fixed a couple of versions later when I notice ;-)
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
@DarkStarSword thank you for the TAB support. I mentioned it a while ago on the forum, but did not get any answer, so the feature you introduced was a big surprise.
@DarkStarSword thank you for the TAB support. I mentioned it a while ago on the forum, but did not get any answer, so the feature you introduced was a big surprise.
DarkStarSword, with my dx9 wrapper code public on GitHub you could look at it to see if it is feasable.
My wrapper only supports a sub-set of all game fixes.
Big Thanks DarkStarSword for the complete reply.
I guess no harm will come upgrading to the latest version;)
If something doesn't work at least we will catch a bug;)
I'll try to make the release with 1.2.32 version then;)
Big Thanks DarkStarSword for the complete reply.
I guess no harm will come upgrading to the latest version;)
If something doesn't work at least we will catch a bug;)
I'll try to make the release with 1.2.32 version then;)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
Bug?
3DM probably skips the shaders with warnings. I was unable to dump it with cycling through vertex shaders. I had to export all shaders and find that vertex shader based on the hash found in the Shaderusage.txt
[code]/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HLSL errors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\GAMES\STEAM\steamapps\common\DiRT 3 Complete Edition\wrapper1349(107,14-15): warning X3578: Output value 'o1' is not completely initialized
C:\GAMES\STEAM\steamapps\common\DiRT 3 Complete Edition\wrapper1349(109,14-15): warning X3578: Output value 'o3' is not completely initialized
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/[/code]
3DM probably skips the shaders with warnings. I was unable to dump it with cycling through vertex shaders. I had to export all shaders and find that vertex shader based on the hash found in the Shaderusage.txt
/*~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HLSL errors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\GAMES\STEAM\steamapps\common\DiRT 3 Complete Edition\wrapper1349(107,14-15): warning X3578: Output value 'o1' is not completely initialized
C:\GAMES\STEAM\steamapps\common\DiRT 3 Complete Edition\wrapper1349(109,14-15): warning X3578: Output value 'o3' is not completely initialized
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
OK, no problem, it was worth downloading to find out that it actually supports DK2 directly. I did not know that.
For that night shader, I think I made my own mission, then was able to choose what time of day to fly, and I chose middle of the night. Apparently there were bad guys though, as they blew me up while I was shader hunting. Not sure, only ran it to look for these problems.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
I'm trying to make a screen size correction similar to what you'd see in some UE3 fixes. I think the above code is what I need. But I'm not sure how to use this in a shader.
Typical UE3 Dx9 screen size correction fix:
And here's a Dx11 shader that (I think) needs this correction:
Dual boot Win 7 x64 & Win 10 (1809) | Geforce Drivers 417.35
Well, this part I do ;-)
You can define a [ShaderOverride] section for the shader and pass the current resolution width & height in with some IniParams, e.g.
I'm using x1 & y1 here, but you can choose any of the 32 available Ini Params (x, x1, x2, ..., x7, ditto for y, z & w). If you are using any of the ones that end in a number the syntax to load it is slightly different:
Where the first number in the int2 corresponds with the number on the IniParam (the second number is always 0).
If you find the resolution you get is wrong (especially if not using a native resolution), try changing get_resolution_from to depth_stencil.
Notably, in addition to res_width/height there is also rt_width/height, which retuns the dimensions of the currently active render target - in many cases this will be the same as the resolution, but I use this to detect when an off-screen render target is in use and for this type of adjustment it might technically be the correct thing to use... but since it will usually match the resolution it probably won't matter.
The resolution is alternatively available through StereoParams.Load(int2(2, 0)).xy, which is obtained using a different technique again and should give you the resolution that the monitor is being driven at by the card. This is probably always the same as res_width/height when get_resolution_from=swap_chain is in use (but I'm not 100% certain of that - games do too many weird things).
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 don't know why, but cache_shaders=1 has no longer any effect. I don't see any bins in the shaders folder.Ignore that. It's just me beeing stupid.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
https://github.com/bo3b/3Dmigoto/releases
This release is primarily aimed at improving support for CustomShaders to make the side-by-side and top-and-bottom output mode custom shader more universal.
- The custom SBS / TAB shader is included in this release, but is not yet enabled by default (while it undergoes more testing) - uncomment the line in the [Present] section to enable then use F11 to switch modes.
- The following options are added to CustomShader sections to allow the rasterizer state to be overridden:
fill ("solid" / "wireframe"), cull ("none", "front", "back"), front ("clockwise", "counterclockwise"), depth_bias, depth_bias_clamp, slope_scaled_depth_bias, depth_clip_enable, scissor_enable, multisample_enable, antialiased_line_enable
These options correspond to those documented on this MSDN article. Like the OM blend state, overriding any one of these will override them all back to the defaults from DX, and there is no provision to merge these with any existing state. The most useful option when injecting a full-screen shader is likely to be cull=none so that you don't have to worry about whether the game is using clockwise or counter-clockwise ordering to signify front-facing surfaces, or which is being culled.
- A "topology" option is added to CustomShader sections to define the vertex topology, such as "triangle_strip", "triangle_list", etc. The options correspond to those documented here.
- CustomShader sections will now automatically back up and restore all render targets, depth/stencil targets, UAVs bound to pixel (not compute) shaders and viewports that were bound when they were called. This largely eliminates the need to back these up into custom resources manually, and solves certain complications that could arise if a pixel shader was using UAVs. Textures are not backed up.
- Each shader type in a CustomShader section can now be set to "null" to explicitly unbind it from the pipeline. This is most useful to ensure that there are no tesselation or geometry shaders still bound. This must be done explicitly, which allows these sections to continue to inherit the state from the game if desired (e.g. as I did in The Witness).
- Resource copying has gained a "set_viewport" keyword, which sets the view-port to the dimensions of the resource being copied, which ensures that it can be drawn to if used as a render target (necessary for custom shaders to work in MGSV from the present call).
- Resource copying has gained a "no_view_cache" keyword, which disables caching any view created through that operation. This is necessary to eliminate a glitch in Mad Max that occurs if a render target view of the back buffer exists during a certain point of it's initialisation.
This release also includes some bug fixes:
- Fixes an issue creating depth/stencil views through resource copying
- Fixes the placement of the overlay in some games (e.g. MGSV)
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
Really awesome update there! I'm a bit out of the loop with SBS support added in the latest 3DMigoto.
I am still working on Rise Of Tomb Raider fix. The fix started with 3DMigoto v.1.2.27.
Is there a reason to update to this version? It is posible some things are not compatible? Or should the upgrade just be a process of copy/paste the new DLL?:) I figured you are the best person to ask this:)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
Also, compiling that shader takes approximately 2 seconds.
EDIT: I've identified a bug and fixed the indexing it but seems like there is still something else wrong.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
Try this version, as the array indices are correct in ASM. Not sure it's the same as yours, and might still have an alternate bug, but worth a try.
Acer H5360 (1280x720@120Hz) - ASUS VG248QE with GSync mod - 3D Vision 1&2 - Driver 372.54
GTX 970 - i5-4670K@4.2GHz - 12GB RAM - Win7x64+evilKB2670838 - 4 Disk X25 RAID
SAGER NP9870-S - GTX 980 - i7-6700K - Win10 Pro 1607
Latest 3Dmigoto Release
Bo3b's School for ShaderHackers
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
Updating 3DMigoto just needs the new DLLs copied in, though to add SBS & TAB support you will also need the [CustomShader3DVision2SBS] section from the ini, the line in the [Present] section to call it (if you are already using a [Present] section just add that line, otherwise add the whole section), the [KeyChange3DVision2SBSOutputMode] section and the custom vertex & pixel shaders in the ShaderFixes directory.
Generaly speaking we always aim to keep 3DMigoto compatible with existing fixes unless we have a good reason to break them - and if we do, we would bump the second number in the version string to signify that (i.e. 1.0 -> 1.1 was a major rewrite of some core code and re-introduced DXGI support, which broke a lot of games until it stabilised, 1.1 -> 1.2 changed the texture hashes for performance, 1.2 -> 1.3 will also likely be due to changing the texture hashes (for performance in games that need track_texture_updates for texture filtering to work reliably - FC4 in particular would benefit, and I've been holding off adding texture filtering to MGSV until this is ready since I noticed it had the same problem).
I did remove preloading shaders a couple of versions ago, but only because I'm pretty sure no one was using it and I'm pretty sure it had been broken for some time.
Of course there is always the risk that I might inadvertently introduce a bug, but if I do it will most likely be in the features that are under active development, like the resource copying or shader injection code, and just as likely to be fixed a couple of versions later when I notice ;-)
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
My wrapper only supports a sub-set of all game fixes.
Thanks to everybody using my assembler it warms my heart.
To have a critical piece of code that everyone can enjoy!
What more can you ask for?
donations: ulfjalmbrant@hotmail.com
I guess no harm will come upgrading to the latest version;)
If something doesn't work at least we will catch a bug;)
I'll try to make the release with 1.2.32 version then;)
1x Palit RTX 2080Ti Pro Gaming OC(watercooled and overclocked to hell)
3x 3D Vision Ready Asus VG278HE monitors (5760x1080).
Intel i9 9900K (overclocked to 5.3 and watercooled ofc).
Asus Maximus XI Hero Mobo.
16 GB Team Group T-Force Dark Pro DDR4 @ 3600.
Lots of Disks:
- Raid 0 - 256GB Sandisk Extreme SSD.
- Raid 0 - WD Black - 2TB.
- SanDisk SSD PLUS 480 GB.
- Intel 760p 256GB M.2 PCIe NVMe SSD.
Creative Sound Blaster Z.
Windows 10 x64 Pro.
etc
My website with my fixes and OpenGL to 3D Vision wrapper:
http://3dsurroundgaming.com
(If you like some of the stuff that I've done and want to donate something, you can do it with PayPal at tavyhome@gmail.com)
3DM probably skips the shaders with warnings. I was unable to dump it with cycling through vertex shaders. I had to export all shaders and find that vertex shader based on the hash found in the Shaderusage.txt
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64