Far Cry 4 {3D Screenshots}
  10 / 28    
The fix for the fog might change the ShaderUsage.txt, depending on what level that changes things - if it only changes things in the driver I wouldn't expect it to make a difference, but if it changes something in the game it might. It would certainly be interesting to compare with and without it anyway. IIRC Mike said that running with either a NULL profile or with the SLI compatibility bits copied from the Far Cry 3 profile fixed the fog. I can't really see anything that suggests something is different here. For instance, here is one of the pixel shaders for the water: [code] SamplerState DepthVPSampler__SampObj___s : register(s0); Texture2D<float4> DepthVPSampler__TexObj__ : register(t0); From your ShaderUsage.txt: <PixelShader hash="d3cb9d7ab9fa827b"> <ParentVertexShaders>f60310a2b783bead </ParentVertexShaders> <Register id=0 handle=000000001B25A390>39ef11c975277cce</Register> <Register id=1 handle=000000002B9DF7D0>0000000000000000</Register> <Register id=2 handle=00000000186C4150>61f2434f5a0c5a47</Register> <Register id=3 handle=000000002D8243D0>89875eec9d8688da</Register> <Register id=4 handle=000000002D5CD550>35fc86ba8f79a8e3</Register> <Register id=5 handle=00000000250C04D0>0a1a99e54e5ac187</Register> <Register id=6 handle=0000000018555E10>6c121d35eaa18323</Register> <Register id=7 handle=0000000018555E10>6c121d35eaa18323</Register> <Register id=125 handle=00000000165D1850>24a83fdae0465bcc</Register> <RenderTarget id=0 handle=000000001B8FF610>fb867b48f4f9bd9c</RenderTarget> <DepthTarget handle=000000001B258290>bb9ce37afa6a5b92</DepthTarget> </PixelShader> From my ShaderUsage.txt: <PixelShader hash="d3cb9d7ab9fa827b"> <ParentVertexShaders>f60310a2b783bead </ParentVertexShaders> <Register id=0 handle=000000001C5D0510>dd64dbb61b36d8f6</Register> <Register id=1 handle=000000002C4800D0>0000000000000000</Register> <Register id=2 handle=0000000019CAAAD0>61f2434f5a0c5a47</Register> <Register id=3 handle=0000000036A4AE10>89875eec9d8688da</Register> <Register id=4 handle=0000000036A4A790>35fc86ba8f79a8e3</Register> <Register id=5 handle=000000002C491D50>8d5700e13d124f85</Register> <Register id=6 handle=0000000051A9E750>70d587a622cf01ce</Register> <Register id=120 handle=000000001769EBD0>0000000000000000</Register> <Register id=125 handle=000000001769E310>24a83fdae0465bcc</Register> <RenderTarget id=0 handle=000000001C7B3590>9fcd029aa9856234</RenderTarget> <DepthTarget handle=000000001C7B6150>617eea474caf667a</DepthTarget> </PixelShader> [/code] In both of these the depth texture in register 0 is only ever used as a texture - it's handle is never used in a DepthTarget or RenderTarget. The only difference I can see in the depth textures is the resolution: [code] <RenderTarget hash=39ef11c975277cce type=Texture2D Width=1280 Height=720 MipLevels=1 ArraySize=1 RawFormat=39 Format="R32_TYPELESS" SampleDesc.Count=1 SampleDesc.Quality=0 Usage=0 BindFlags=168 CPUAccessFlags=0 MiscFlags=0></RenderTarget> <RenderTarget hash=dd64dbb61b36d8f6 type=Texture2D Width=1920 Height=1080 MipLevels=1 ArraySize=1 RawFormat=39 Format="R32_TYPELESS" SampleDesc.Count=1 SampleDesc.Quality=0 Usage=0 BindFlags=168 CPUAccessFlags=0 MiscFlags=0></RenderTarget> [/code] That in itself is interesting - 3Dmigoto is supposed to special case textures that are the same size as the screen, so the fact that these ended up with different hashes might suggest that something is broken there (and since I touched that code last it's entirely possible that it's my bug). But short term all this does is show no obvious difference between the two. There was one unusual entry that grabbed my attention: [code] <PixelShader hash="ea7c9bf41ba3fd6b"> <ParentVertexShaders>9b451e2f72955bc1 </ParentVertexShaders> <Register id=0 handle=000000001B258290>bb9ce37afa6a5b92</Register> <Register id=1 handle=0000000035B435D0>e4f84562d73b6d0c</Register> <Register id=2 handle=000000002D83CFD0>c8757a454faa82bb</Register> <Register id=3 handle=000000002D83D210>f50d50166315c556</Register> <Register id=4 handle=0000000035B433D0>51e9dd54efe2a9be</Register> <Register id=5 handle=00000000399CF450>3aa25359a0ac6c7e</Register> <Register id=125 handle=00000000165D1850>24a83fdae0465bcc</Register> <RenderTarget id=0 handle=000000001B259890>bb3be3bdabea0d8a</RenderTarget> <RenderTarget id=1 handle=000000001B259410>3aa25359a0ac6c7e</RenderTarget> <RenderTarget id=2 handle=000000001B259AD0>bb3be3bdabea0d8a</RenderTarget> <RenderTarget id=3 handle=000000001B259CD0>bb3be3bdabea0d8a</RenderTarget> <RenderTarget id=4 handle=000000001B259F10>fb4bb9fb7bad4a24</RenderTarget> <RenderTarget id=4 handle=000000001B25A150>fb4bb9fb7bad4a24</RenderTarget> <DepthTarget handle=000000001B258290>bb9ce37afa6a5b92</DepthTarget> </PixelShader> [/code] Here the depth resource appears that it has been bound as a depth/stencil view and a shader resource view simultaneously (same resource handle), which would contradict the DirectX documentation and my own experience trying to inject an active depth buffer into an input. My guess is that they weren't actually used simultaneously, and this is simply showing that this pixel shader is sometimes used with an active depth buffer, and at other times with no depth target at all, but the depth buffer assigned to register 0 instead. However it certainly would be interesting if turned out that they were used simultaneously, and this is definitely something I'll try to take a closer look at. At the moment RenderTargets and DepthTargets record all the unique resources that have been assigned to each slot since launching the game (hence why there are two RenderTargets with id=4 above), but I haven't changed the registers to do the same yet, so they will only show the most recent texture used in each slot.
The fix for the fog might change the ShaderUsage.txt, depending on what level that changes things - if it only changes things in the driver I wouldn't expect it to make a difference, but if it changes something in the game it might. It would certainly be interesting to compare with and without it anyway. IIRC Mike said that running with either a NULL profile or with the SLI compatibility bits copied from the Far Cry 3 profile fixed the fog.

I can't really see anything that suggests something is different here. For instance, here is one of the pixel shaders for the water:
SamplerState DepthVPSampler__SampObj___s : register(s0);
Texture2D<float4> DepthVPSampler__TexObj__ : register(t0);

From your ShaderUsage.txt:
<PixelShader hash="d3cb9d7ab9fa827b">
<ParentVertexShaders>f60310a2b783bead </ParentVertexShaders>
<Register id=0 handle=000000001B25A390>39ef11c975277cce</Register>
<Register id=1 handle=000000002B9DF7D0>0000000000000000</Register>
<Register id=2 handle=00000000186C4150>61f2434f5a0c5a47</Register>
<Register id=3 handle=000000002D8243D0>89875eec9d8688da</Register>
<Register id=4 handle=000000002D5CD550>35fc86ba8f79a8e3</Register>
<Register id=5 handle=00000000250C04D0>0a1a99e54e5ac187</Register>
<Register id=6 handle=0000000018555E10>6c121d35eaa18323</Register>
<Register id=7 handle=0000000018555E10>6c121d35eaa18323</Register>
<Register id=125 handle=00000000165D1850>24a83fdae0465bcc</Register>
<RenderTarget id=0 handle=000000001B8FF610>fb867b48f4f9bd9c</RenderTarget>
<DepthTarget handle=000000001B258290>bb9ce37afa6a5b92</DepthTarget>
</PixelShader>

From my ShaderUsage.txt:
<PixelShader hash="d3cb9d7ab9fa827b">
<ParentVertexShaders>f60310a2b783bead </ParentVertexShaders>
<Register id=0 handle=000000001C5D0510>dd64dbb61b36d8f6</Register>
<Register id=1 handle=000000002C4800D0>0000000000000000</Register>
<Register id=2 handle=0000000019CAAAD0>61f2434f5a0c5a47</Register>
<Register id=3 handle=0000000036A4AE10>89875eec9d8688da</Register>
<Register id=4 handle=0000000036A4A790>35fc86ba8f79a8e3</Register>
<Register id=5 handle=000000002C491D50>8d5700e13d124f85</Register>
<Register id=6 handle=0000000051A9E750>70d587a622cf01ce</Register>
<Register id=120 handle=000000001769EBD0>0000000000000000</Register>
<Register id=125 handle=000000001769E310>24a83fdae0465bcc</Register>
<RenderTarget id=0 handle=000000001C7B3590>9fcd029aa9856234</RenderTarget>
<DepthTarget handle=000000001C7B6150>617eea474caf667a</DepthTarget>
</PixelShader>


In both of these the depth texture in register 0 is only ever used as a texture - it's handle is never used in a DepthTarget or RenderTarget. The only difference I can see in the depth textures is the resolution:

<RenderTarget hash=39ef11c975277cce type=Texture2D Width=1280 Height=720 MipLevels=1 ArraySize=1 RawFormat=39 Format="R32_TYPELESS" SampleDesc.Count=1 SampleDesc.Quality=0 Usage=0 BindFlags=168 CPUAccessFlags=0 MiscFlags=0></RenderTarget>
<RenderTarget hash=dd64dbb61b36d8f6 type=Texture2D Width=1920 Height=1080 MipLevels=1 ArraySize=1 RawFormat=39 Format="R32_TYPELESS" SampleDesc.Count=1 SampleDesc.Quality=0 Usage=0 BindFlags=168 CPUAccessFlags=0 MiscFlags=0></RenderTarget>


That in itself is interesting - 3Dmigoto is supposed to special case textures that are the same size as the screen, so the fact that these ended up with different hashes might suggest that something is broken there (and since I touched that code last it's entirely possible that it's my bug). But short term all this does is show no obvious difference between the two.


There was one unusual entry that grabbed my attention:
<PixelShader hash="ea7c9bf41ba3fd6b">
<ParentVertexShaders>9b451e2f72955bc1 </ParentVertexShaders>
<Register id=0 handle=000000001B258290>bb9ce37afa6a5b92</Register>
<Register id=1 handle=0000000035B435D0>e4f84562d73b6d0c</Register>
<Register id=2 handle=000000002D83CFD0>c8757a454faa82bb</Register>
<Register id=3 handle=000000002D83D210>f50d50166315c556</Register>
<Register id=4 handle=0000000035B433D0>51e9dd54efe2a9be</Register>
<Register id=5 handle=00000000399CF450>3aa25359a0ac6c7e</Register>
<Register id=125 handle=00000000165D1850>24a83fdae0465bcc</Register>
<RenderTarget id=0 handle=000000001B259890>bb3be3bdabea0d8a</RenderTarget>
<RenderTarget id=1 handle=000000001B259410>3aa25359a0ac6c7e</RenderTarget>
<RenderTarget id=2 handle=000000001B259AD0>bb3be3bdabea0d8a</RenderTarget>
<RenderTarget id=3 handle=000000001B259CD0>bb3be3bdabea0d8a</RenderTarget>
<RenderTarget id=4 handle=000000001B259F10>fb4bb9fb7bad4a24</RenderTarget>
<RenderTarget id=4 handle=000000001B25A150>fb4bb9fb7bad4a24</RenderTarget>
<DepthTarget handle=000000001B258290>bb9ce37afa6a5b92</DepthTarget>
</PixelShader>


Here the depth resource appears that it has been bound as a depth/stencil view and a shader resource view simultaneously (same resource handle), which would contradict the DirectX documentation and my own experience trying to inject an active depth buffer into an input.

My guess is that they weren't actually used simultaneously, and this is simply showing that this pixel shader is sometimes used with an active depth buffer, and at other times with no depth target at all, but the depth buffer assigned to register 0 instead. However it certainly would be interesting if turned out that they were used simultaneously, and this is definitely something I'll try to take a closer look at.

At the moment RenderTargets and DepthTargets record all the unique resources that have been assigned to each slot since launching the game (hence why there are two RenderTargets with id=4 above), but I haven't changed the registers to do the same yet, so they will only show the most recent texture used in each slot.

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

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

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

Posted 01/16/2015 01:57 PM   
[quote="bo3b"]I pulled in top-of-tree and ran against the current shader set in the project. This is running SLI, but no fix is enabled for the white fog/tree haze problem, but that shouldn't matter for a ShaderUsage.txt right? [/quote] Just a quick note to say that the SLI fog fix thing is a DAI feature, not FC4. All fog and haze is fixed in FC4 with my fix (but only in SLI of course).
bo3b said:I pulled in top-of-tree and ran against the current shader set in the project. This is running SLI, but no fix is enabled for the white fog/tree haze problem, but that shouldn't matter for a ShaderUsage.txt right?


Just a quick note to say that the SLI fog fix thing is a DAI feature, not FC4. All fog and haze is fixed in FC4 with my fix (but only in SLI of course).

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 01/16/2015 04:58 PM   
I'm taking a look at Far Cry 4 and discovering bugs in my wrapper along with shader fixes that don't compile. Only upside is that it's working when all the shaderfixes have been disabled. Nothing to brag about but it's kind of good that it doesn't crash when doing practically nothing. Generated a 1gb logfile in the process. I should trim the logging.
I'm taking a look at Far Cry 4 and discovering bugs in my wrapper along with shader fixes that don't compile. Only upside is that it's working when all the shaderfixes have been disabled.

Nothing to brag about but it's kind of good that it doesn't crash when doing practically nothing.

Generated a 1gb logfile in the process. I should trim the logging.

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

donations: ulfjalmbrant@hotmail.com

Posted 01/17/2015 11:24 PM   
log file 1 gb? Does it record row video? :D
log file 1 gb? Does it record row video? :D

Posted 01/18/2015 10:17 AM   
Any new about the possible patch?
Any new about the possible patch?

Posted 01/26/2015 05:31 PM   
[quote="Enzel02"]Any new about the possible patch?[/quote] Art shouldn`t be rushed ;)
Enzel02 said:Any new about the possible patch?

Art shouldn`t be rushed ;)
For timing of a fix, it's always very difficult to say. Depends on real-life issues and other difficulties that are not predictable. At present, we have a problem with the fix that is the same as SR4, where the fix only works in SLI. We know that's a serious bummer and are working on it. We might just disable some effects in the non-SLI case. In terms of timing, my best guess is that this is something like 2-3 weeks out, but not like 2-3 months out. Please don't hold me to any estimates, but I understand people would want to know if it was really close, or really far, before starting to play.
For timing of a fix, it's always very difficult to say. Depends on real-life issues and other difficulties that are not predictable.

At present, we have a problem with the fix that is the same as SR4, where the fix only works in SLI. We know that's a serious bummer and are working on it. We might just disable some effects in the non-SLI case.


In terms of timing, my best guess is that this is something like 2-3 weeks out, but not like 2-3 months out.

Please don't hold me to any estimates, but I understand people would want to know if it was really close, or really far, before starting to play.

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

Posted 01/28/2015 08:00 AM   
[quote="bo3b"]For timing of a fix, it's always very difficult to say. Depends on real-life issues and other difficulties that are not predictable. At present, we have a problem with the fix that is the same as SR4, where the fix only works in SLI. We know that's a serious bummer and are working on it. We might just disable some effects in the non-SLI case. In terms of timing, my best guess is that this is something like 2-3 weeks out, but not like 2-3 months out. Please don't hold me to any estimates, but I understand people would want to know if it was really close, or really far, before starting to play.[/quote] Thanks bo3b, your work is always appreciated. If we were to just grab the d3dx.ini and the shaders from the github repository would this work at any level for those of us running SLI or does it need to be properly compiled into a release?
bo3b said:For timing of a fix, it's always very difficult to say. Depends on real-life issues and other difficulties that are not predictable.

At present, we have a problem with the fix that is the same as SR4, where the fix only works in SLI. We know that's a serious bummer and are working on it. We might just disable some effects in the non-SLI case.


In terms of timing, my best guess is that this is something like 2-3 weeks out, but not like 2-3 months out.

Please don't hold me to any estimates, but I understand people would want to know if it was really close, or really far, before starting to play.



Thanks bo3b, your work is always appreciated. If we were to just grab the d3dx.ini and the shaders from the github repository would this work at any level for those of us running SLI or does it need to be properly compiled into a release?

i7 5930k @ 4.5GHz
Asus Sabertooth X99 Motherboard
2 x EVGA GTX 980 Ti SC @ 1380MHz/7.5GHz
Twin loop, triple rad water cooled
16GB Kingston Predator 3GHz

256GB Samsung XP941 M.2 SSD (OS)
2 x 256GB SSD RAID0 (Games)
2 x 2TB Mechanical (storage)

Asus ROG Swift PG278Q 1440p/144MHz 3D/G-sync monitor
Avermedia ExtremeCap U3 Video Capture for PS4 passthrough
Phanteks Enthoo Primo Gold case

Dual Boot OS Windows 8.1/Windows 10

Posted 01/28/2015 08:18 AM   
[quote="CarpeDiemPW"]Thanks bo3b, your work is always appreciated. If we were to just grab the d3dx.ini and the shaders from the github repository would this work at any level for those of us running SLI or does it need to be properly compiled into a release? [/quote] You could certainly give that a try with the latest 3Dmigoto code release, but I think the ShaderFixes is relatively incomplete. There is no fix for haze and fog, so it can be fairly distracting. If you are in a hurry to play, it sounds like the CM would actually be a better experience.
CarpeDiemPW said:Thanks bo3b, your work is always appreciated. If we were to just grab the d3dx.ini and the shaders from the github repository would this work at any level for those of us running SLI or does it need to be properly compiled into a release?

You could certainly give that a try with the latest 3Dmigoto code release, but I think the ShaderFixes is relatively incomplete. There is no fix for haze and fog, so it can be fairly distracting.

If you are in a hurry to play, it sounds like the CM would actually be a better experience.

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

Posted 01/28/2015 09:26 AM   
[quote="bo3b"] You could certainly give that a try with the latest 3Dmigoto code release, but I think the ShaderFixes is relatively incomplete. There is no fix for haze and fog, so it can be fairly distracting. If you are in a hurry to play, it sounds like the CM would actually be a better experience.[/quote] No probs - I'm already playing in CM and it really is a good example of how well it can work. It's just not quite true 3D though and given you said that things seemed to work in SLI just not single gpu, I thought it might be worth a try... more than happy to wait though if there are still a number shader fixes to come. Only managing to get in about 2 hours a night if I'm lucky anyway with work and the little one staying up later recently, so not going to be finishing anything anytime soon ;)
bo3b said:
You could certainly give that a try with the latest 3Dmigoto code release, but I think the ShaderFixes is relatively incomplete. There is no fix for haze and fog, so it can be fairly distracting.

If you are in a hurry to play, it sounds like the CM would actually be a better experience.


No probs - I'm already playing in CM and it really is a good example of how well it can work. It's just not quite true 3D though and given you said that things seemed to work in SLI just not single gpu, I thought it might be worth a try... more than happy to wait though if there are still a number shader fixes to come. Only managing to get in about 2 hours a night if I'm lucky anyway with work and the little one staying up later recently, so not going to be finishing anything anytime soon ;)

i7 5930k @ 4.5GHz
Asus Sabertooth X99 Motherboard
2 x EVGA GTX 980 Ti SC @ 1380MHz/7.5GHz
Twin loop, triple rad water cooled
16GB Kingston Predator 3GHz

256GB Samsung XP941 M.2 SSD (OS)
2 x 256GB SSD RAID0 (Games)
2 x 2TB Mechanical (storage)

Asus ROG Swift PG278Q 1440p/144MHz 3D/G-sync monitor
Avermedia ExtremeCap U3 Video Capture for PS4 passthrough
Phanteks Enthoo Primo Gold case

Dual Boot OS Windows 8.1/Windows 10

Posted 01/28/2015 09:58 AM   
[quote="bo3b"]For timing of a fix, it's always very difficult to say. Depends on real-life issues and other difficulties that are not predictable. At present, we have a problem with the fix that is the same as SR4, where the fix only works in SLI. We know that's a serious bummer and are working on it. We might just disable some effects in the non-SLI case. In terms of timing, my best guess is that this is something like 2-3 weeks out, but not like 2-3 months out. Please don't hold me to any estimates, but I understand people would want to know if it was really close, or really far, before starting to play.[/quote] Thanks for your kindness and effort Bo3b!
bo3b said:For timing of a fix, it's always very difficult to say. Depends on real-life issues and other difficulties that are not predictable.

At present, we have a problem with the fix that is the same as SR4, where the fix only works in SLI. We know that's a serious bummer and are working on it. We might just disable some effects in the non-SLI case.


In terms of timing, my best guess is that this is something like 2-3 weeks out, but not like 2-3 months out.

Please don't hold me to any estimates, but I understand people would want to know if it was really close, or really far, before starting to play.


Thanks for your kindness and effort Bo3b!

Posted 01/28/2015 10:11 AM   
[quote="bo3b"][quote="CarpeDiemPW"]Thanks bo3b, your work is always appreciated. If we were to just grab the d3dx.ini and the shaders from the github repository would this work at any level for those of us running SLI or does it need to be properly compiled into a release? [/quote] You could certainly give that a try with the latest 3Dmigoto code release, but I think the ShaderFixes is relatively incomplete. There is no fix for haze and fog, so it can be fairly distracting. If you are in a hurry to play, it sounds like the CM would actually be a better experience.[/quote] The haze and fog is broken in non-SLI, not SLI, unless you mean something else bo3b? I have fixed a fair few more things that are not in GitHub as well, especially (most) water reflections and Decals, but there are some difficult lighting/shadow shaders I have not worked out yet, and a particularly distracting water reflection shader. When I sort those two out the fix will be worthy of a beta release (for SLI only), but I can't say when I will have time yet. I am just about keeping up with Dragon Age Inquisition patches right now...
bo3b said:
CarpeDiemPW said:Thanks bo3b, your work is always appreciated. If we were to just grab the d3dx.ini and the shaders from the github repository would this work at any level for those of us running SLI or does it need to be properly compiled into a release?

You could certainly give that a try with the latest 3Dmigoto code release, but I think the ShaderFixes is relatively incomplete. There is no fix for haze and fog, so it can be fairly distracting.

If you are in a hurry to play, it sounds like the CM would actually be a better experience.

The haze and fog is broken in non-SLI, not SLI, unless you mean something else bo3b? I have fixed a fair few more things that are not in GitHub as well, especially (most) water reflections and Decals, but there are some difficult lighting/shadow shaders I have not worked out yet, and a particularly distracting water reflection shader. When I sort those two out the fix will be worthy of a beta release (for SLI only), but I can't say when I will have time yet. I am just about keeping up with Dragon Age Inquisition patches right now...

Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278

Posted 01/28/2015 03:20 PM   
Thanks Mike, take your time. :)
Thanks Mike, take your time. :)

Posted 01/28/2015 04:31 PM   
3d fix can hope
3d fix can hope

Posted 02/10/2015 05:53 PM   
[quote="walther14"]3d fix can hope[/quote] You should have Master Yoda avatar instead of that cat :)
walther14 said:3d fix can hope

You should have Master Yoda avatar instead of that cat :)
  10 / 28    
Scroll To Top