[quote="DarkStarSword"][quote="mike_ar69"][quote="DHR"]Mike...this one:
[code]bComputeShaderDeferredTiledLighting=0[/code]
I found yesterday, but not tested....if works or is another settings, is great news!
I fix the lensflares and also i starting to look the HUD (already separate the crosshair, but not by texture separation....there is one texture in the shader), but is really anoying with the crashes. Also when you push the crosshair higher than 0.3 the crosshair start to disappear[/quote]
Yeah that's the setting. It was a big relief to sort that out.
The HUD is a pain, I don't understand the clipping. One thing to try would be to force the hud to screen depth (even though it already is) then move it in a fixed depth. I had to do something like this in another game once (can't remember which).[/quote]
In my experience, HUD clipping can mean a few things:
- The adjustment is being applied to an off-screen buffer, possibly as well as, or instead of the adjustment when drawing it to the screen. Another tell-tale sign of this is that some UI elements seem to move further than expected when adjusting their depth. Usually very easy to solve using render target size filtering (see below).
- As above, but the driver's heuristics is adjusting the HUD on the off-screen buffer instead of/as well as us (unlikely if the HUD was already at screen depth). In this case forcing the off-screen render target to mono will prevent the driver from performing the adjustment, or alternatively normalising the output coordinate such that W==1 or W==convergence to bring it to screen depth before applying our adjustment should work.
- There may be another shader responsible for masking out the HUD that needs to be adjusted, which may be hard to locate as it may not have any visible effect when skipped. Hunting while it is clipped may find it, marking_mode=pink may help, or enabling frame analysis to dump out render targets during the HUD stage of the frame (I usually set a trigger on another HUD shader or late post-processing shader with 'analyse_options = persist dump_rt' to only enable dumping once the HUD is being drawn to save me some time + disk space when searching for these).
- Scissor clipping (although the d3dx.ini disables this by default nowadays)
[quote]Also some of the Hud shaders affect real world elements, like the control faces on the switches next to the freezer pods so that could do with texture separation.[/quote]
Very likely solvable using render target size filtering (as long as it is what is on the in-game display, and not the display itself). Depth buffer filtering and/or partner shader filtering may also work, depending on the game.
Render target size filtering works like:
[code]
[Device]
; Use whichever works independently of the resolution:
get_resolution_from = swap_chain
;get_resolution_from = depth_stencil
[ShaderOverrideHUD]
; Some HUD elements are drawn to an offscreen buffer before being copied to the
; screen. Check render target dimensions to determine which it is
Hash = bd5bda832fe2c401
x1 = rt_width
y1 = rt_height
z1 = res_width
w1 = res_height
[/code]
[code]
...
// This shader is used to render UI elements to an offscreen buffer that is
// then copied to the screen. We want to avoid adjusting them on the offscreen
// buffer, so only adjust them if the render target dimensions match the
// resolution:
float4 rt_filter = IniParams.Load(int2(1,0));
if (rt_filter.x == rt_filter.z && rt_filter.y == rt_filter.w) {
// Usual UI depth adjustment, e.g.
o0.x += stereo.x * params.x;
}
...
[/code]
[/quote]
Thanks DarkStarSword - great suggestions. DHR has been looking at the HUD, so if he has time he can give that a go, else I will look perhaps next week. It's going to be important to sort this out in this game as there are so many different HUD parts in different situations.
The rest of the game is looking great though - just some odd double imaging coming from GodRays, and some reflections that are to deep in depth, similar to what we had in Witcher 3 way back when. You resolved that ?reflection problem - what was the approach you used, I can't remember?
Biggest problem with this game at the moment (at least while fixing it) is that it keeps crashing every 5 minutes, so it's slow going.
I found yesterday, but not tested....if works or is another settings, is great news!
I fix the lensflares and also i starting to look the HUD (already separate the crosshair, but not by texture separation....there is one texture in the shader), but is really anoying with the crashes. Also when you push the crosshair higher than 0.3 the crosshair start to disappear
Yeah that's the setting. It was a big relief to sort that out.
The HUD is a pain, I don't understand the clipping. One thing to try would be to force the hud to screen depth (even though it already is) then move it in a fixed depth. I had to do something like this in another game once (can't remember which).
In my experience, HUD clipping can mean a few things:
- The adjustment is being applied to an off-screen buffer, possibly as well as, or instead of the adjustment when drawing it to the screen. Another tell-tale sign of this is that some UI elements seem to move further than expected when adjusting their depth. Usually very easy to solve using render target size filtering (see below).
- As above, but the driver's heuristics is adjusting the HUD on the off-screen buffer instead of/as well as us (unlikely if the HUD was already at screen depth). In this case forcing the off-screen render target to mono will prevent the driver from performing the adjustment, or alternatively normalising the output coordinate such that W==1 or W==convergence to bring it to screen depth before applying our adjustment should work.
- There may be another shader responsible for masking out the HUD that needs to be adjusted, which may be hard to locate as it may not have any visible effect when skipped. Hunting while it is clipped may find it, marking_mode=pink may help, or enabling frame analysis to dump out render targets during the HUD stage of the frame (I usually set a trigger on another HUD shader or late post-processing shader with 'analyse_options = persist dump_rt' to only enable dumping once the HUD is being drawn to save me some time + disk space when searching for these).
- Scissor clipping (although the d3dx.ini disables this by default nowadays)
Also some of the Hud shaders affect real world elements, like the control faces on the switches next to the freezer pods so that could do with texture separation.
Very likely solvable using render target size filtering (as long as it is what is on the in-game display, and not the display itself). Depth buffer filtering and/or partner shader filtering may also work, depending on the game.
Render target size filtering works like:
[Device]
; Use whichever works independently of the resolution:
get_resolution_from = swap_chain
;get_resolution_from = depth_stencil
[ShaderOverrideHUD]
; Some HUD elements are drawn to an offscreen buffer before being copied to the
; screen. Check render target dimensions to determine which it is
Hash = bd5bda832fe2c401
x1 = rt_width
y1 = rt_height
z1 = res_width
w1 = res_height
...
// This shader is used to render UI elements to an offscreen buffer that is
// then copied to the screen. We want to avoid adjusting them on the offscreen
// buffer, so only adjust them if the render target dimensions match the
// resolution:
float4 rt_filter = IniParams.Load(int2(1,0));
if (rt_filter.x == rt_filter.z && rt_filter.y == rt_filter.w) {
// Usual UI depth adjustment, e.g.
o0.x += stereo.x * params.x;
}
...
Thanks DarkStarSword - great suggestions. DHR has been looking at the HUD, so if he has time he can give that a go, else I will look perhaps next week. It's going to be important to sort this out in this game as there are so many different HUD parts in different situations.
The rest of the game is looking great though - just some odd double imaging coming from GodRays, and some reflections that are to deep in depth, similar to what we had in Witcher 3 way back when. You resolved that ?reflection problem - what was the approach you used, I can't remember?
Biggest problem with this game at the moment (at least while fixing it) is that it keeps crashing every 5 minutes, so it's slow going.
[quote="mike_ar69"]Biggest problem with this game at the moment (at least while fixing it) is that it keeps crashing every 5 minutes, so it's slow going. [/quote]
I'm taking a look at these crashes now.
Do you still have the crashes if you set "get_resolution_from = depth_stencil" as DHR was trying?
Also worth trying that will help narrow it down- try the old 1.0.1 version. No overlay, no DXGI stuff. It would be very interesting to know if the missing shaders can be hunted with that version, and also whether it crashes.
Not a huge rush, that will just help clarify where to look.
mike_ar69 said:Biggest problem with this game at the moment (at least while fixing it) is that it keeps crashing every 5 minutes, so it's slow going.
I'm taking a look at these crashes now.
Do you still have the crashes if you set "get_resolution_from = depth_stencil" as DHR was trying?
Also worth trying that will help narrow it down- try the old 1.0.1 version. No overlay, no DXGI stuff. It would be very interesting to know if the missing shaders can be hunted with that version, and also whether it crashes.
Not a huge rush, that will just help clarify where to look.
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
OK, took a look with latest version, and I'm not seeing any crashes. Ran for 55 minutes without any crashes. Cycling shaders, overlay is working, marking shaders is OK. Not sure why this is different for me, although I am running a fix that DarkStarSword just created.
On the off chance that fixes these crashes for you to, I made a new build with that fix: 1.2.8
https://github.com/bo3b/3Dmigoto/releases/download/1.2.8/3Dmigoto-1.2.8.zip
I looked briefly at the exception during Decompile, but every example that I saw was for Domain Shaders. If we need the DS, I can prioritize looking at these, but otherwise these are not significant.
It's always possible that a DomainShader and Tesselation is somehow related to the mystery shader problem. It sounds like you resolved that with setting the compute shaders to off in the .ini though.
OK, took a look with latest version, and I'm not seeing any crashes. Ran for 55 minutes without any crashes. Cycling shaders, overlay is working, marking shaders is OK. Not sure why this is different for me, although I am running a fix that DarkStarSword just created.
On the off chance that fixes these crashes for you to, I made a new build with that fix: 1.2.8
I looked briefly at the exception during Decompile, but every example that I saw was for Domain Shaders. If we need the DS, I can prioritize looking at these, but otherwise these are not significant.
It's always possible that a DomainShader and Tesselation is somehow related to the mystery shader problem. It sounds like you resolved that with setting the compute shaders to off in the .ini though.
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
BTW for those interested, Nvidia is having a screenshot contest for Fallout 4.
Fallout 4 Radiation Check Contest
https://contests.nvidia.com/en-us/fallout-4-radiation-check
i still have a crash with the 1.2.8 version of the game.
@bo3b: You are using the default ini included? i want to compare with mine, that i change a few stuff for hunting
Also try with render target dimensions and the HUD disappear, but not the object related (maybe i'm doing something wrong). The HUD in this game is "special", for example normally in HUD elements you can found more that 1 texture, in this game all HUD shaders have 1 texture only, and also noticed that for the same element of the HUD there are 2 VS that control that part of the HUD, for example
VS 1 controls crosshair and energy bar
VS 2 controls crosshair, energy bar, and af few more stuff
Also the HUD related to the armor fill almost 40% of the screen, there are 5 shaders related that also controls objects (also 1 texture only / also test render target, same results), so i will have to leave that way....is in depth, so is a little anoying with the gun.
@Helifax: Altering the output in PS, changes the color. So is not an option in this game.
i still have a crash with the 1.2.8 version of the game.
@bo3b: You are using the default ini included? i want to compare with mine, that i change a few stuff for hunting
Also try with render target dimensions and the HUD disappear, but not the object related (maybe i'm doing something wrong). The HUD in this game is "special", for example normally in HUD elements you can found more that 1 texture, in this game all HUD shaders have 1 texture only, and also noticed that for the same element of the HUD there are 2 VS that control that part of the HUD, for example
VS 1 controls crosshair and energy bar
VS 2 controls crosshair, energy bar, and af few more stuff
Also the HUD related to the armor fill almost 40% of the screen, there are 5 shaders related that also controls objects (also 1 texture only / also test render target, same results), so i will have to leave that way....is in depth, so is a little anoying with the gun.
@Helifax: Altering the output in PS, changes the color. So is not an option in this game.
[quote="DHR"]
@Helifax: Altering the output in PS, changes the color. So is not an option in this game.[/quote]
CRAP! :( That's a bummer....
I also tested the game with the latest 3DMigoto 1.28 (with the default ini where I just changed the stuff to dump shaders and hunting=2).
Left it running on my laptop for around 45 minutes, no crashes. But then again I haven't ALT+TAB nor did actually play the game :-s Maybe this is why it worked?
Which reminds me of Dragon Age: Inquisition. We had the same issue there where it would crash on ALT+TAB (or soon after). The way we tackled that problem was to use 2 PCs: One for running the game and ofc dumping the shaders, the other to open the dumped shaders and editing;) This way we were able to hunt and fix the shaders without ALT+TAB involved ^_^ Maybe this will work here? (if this is the problem you are seeing).
DHR said:
@Helifax: Altering the output in PS, changes the color. So is not an option in this game.
CRAP! :( That's a bummer....
I also tested the game with the latest 3DMigoto 1.28 (with the default ini where I just changed the stuff to dump shaders and hunting=2).
Left it running on my laptop for around 45 minutes, no crashes. But then again I haven't ALT+TAB nor did actually play the game :-s Maybe this is why it worked?
Which reminds me of Dragon Age: Inquisition. We had the same issue there where it would crash on ALT+TAB (or soon after). The way we tackled that problem was to use 2 PCs: One for running the game and ofc dumping the shaders, the other to open the dumped shaders and editing;) This way we were able to hunt and fix the shaders without ALT+TAB involved ^_^ Maybe this will work here? (if this is the problem you are seeing).
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
Just a quick update - I've identified a definite reference counting discrepancy in 3DMigoto that allows the DirectX device and other objects to be freed prematurely (I've hit this after 10 minutes of play in FC4 once, and am currently hitting it 100% of the time when launching FC4), but the cause is proving somewhat elusive. I'm not positive that this is the only 10 minute crash, but it's definitely a real possibility.
In addition to the crash I fixed in 1.2.8 (which can crash FC4 on launch), I've also fixed an issue with the texture hashes for compressed textures and texture arrays (which unfortunately might break existing fixes, but I've tried to minimise that possibility by not fixing any hashes which would work - more testing is needed to be sure if that's ok), and some problems when 3D is disabled via the control panel.
Just a quick update - I've identified a definite reference counting discrepancy in 3DMigoto that allows the DirectX device and other objects to be freed prematurely (I've hit this after 10 minutes of play in FC4 once, and am currently hitting it 100% of the time when launching FC4), but the cause is proving somewhat elusive. I'm not positive that this is the only 10 minute crash, but it's definitely a real possibility.
In addition to the crash I fixed in 1.2.8 (which can crash FC4 on launch), I've also fixed an issue with the texture hashes for compressed textures and texture arrays (which unfortunately might break existing fixes, but I've tried to minimise that possibility by not fixing any hashes which would work - more testing is needed to be sure if that's ok), and some problems when 3D is disabled via the control panel.
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="bo3b"]OK, took a look with latest version, and I'm not seeing any crashes. Ran for 55 minutes without any crashes.[/quote]It's worth noting that I never seem to hit the 10 minute crash (and reduce the chance of a crash on launch) when I enable debug logging, use the debug DLL or use API monitor - pretty sure the slowdown caused by either of those is closing a race window, which also suggests that the reason you aren't hitting them might just be down to a difference in speed on your machine. I've been selectively bumping any log messages I think may be relevant to try to get more info and still be able to hit the crash.
bo3b said:OK, took a look with latest version, and I'm not seeing any crashes. Ran for 55 minutes without any crashes.
It's worth noting that I never seem to hit the 10 minute crash (and reduce the chance of a crash on launch) when I enable debug logging, use the debug DLL or use API monitor - pretty sure the slowdown caused by either of those is closing a race window, which also suggests that the reason you aren't hitting them might just be down to a difference in speed on your machine. I've been selectively bumping any log messages I think may be relevant to try to get more info and still be able to hit the crash.
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 the 1.2.8 version have the crash fix?
I'm still have the crash and is 100% of the times at aprox. 10 min of playing. Happens also if i don't ALT-TAB in the game.
[quote="DHR"]DarkStarSword the 1.2.8 version have the crash fix? [/quote]Nope (it included a fix for a different crash I encountered), but 1.2.9 does:
https://github.com/bo3b/3Dmigoto/releases/tag/1.2.9
This version also fixes some of the texture CRC calculations (specifically for compressed textures and texture arrays), which has the potential to change some of the texture hashes... I've left any hashes that were "good enough" alone, which hopefully will mean this won't have too much impact, but I haven't checked every game that was using these. @DHR - since you have used these pretty extensively would you mind checking if it has broken any of your fixes?
This version also fixes some of the texture CRC calculations (specifically for compressed textures and texture arrays), which has the potential to change some of the texture hashes... I've left any hashes that were "good enough" alone, which hopefully will mean this won't have too much impact, but I haven't checked every game that was using these. @DHR - since you have used these pretty extensively would you mind checking if it has broken any of your fixes?
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="DHR"]Thanks DarkStarSword!!
The 1.2.9 fix the crash!!!
I will take a look other fixes when i use texture separation.[/quote]
Awesome! Glad to hear that DarkStarSword found the culprit. Great one!
Good job guys!
BTW if we can be of any help, any grunt work, like just running around in the game and spot textures/effects that are at the wrong depth, feel free to ask! I'd gladly help! (given instruction on how to identify shaders :))
Note: I played the game for a good 8 hours without any glitch or crash. Seems like a stable setup I have. If this can help iron out some bugs that we don't know if they're from the game or the 3D fix, I can test out bugs too.
BTW if we can be of any help, any grunt work, like just running around in the game and spot textures/effects that are at the wrong depth, feel free to ask! I'd gladly help! (given instruction on how to identify shaders :))
Note: I played the game for a good 8 hours without any glitch or crash. Seems like a stable setup I have. If this can help iron out some bugs that we don't know if they're from the game or the 3D fix, I can test out bugs too.
[quote="DarkStarSword"]https://github.com/bo3b/3Dmigoto/releases/tag/1.2.9
[/quote]
Installed it to game directory but it didnt fix 3D issues. Do I miss something or its not a fix?
Thanks DarkStarSword - great suggestions. DHR has been looking at the HUD, so if he has time he can give that a go, else I will look perhaps next week. It's going to be important to sort this out in this game as there are so many different HUD parts in different situations.
The rest of the game is looking great though - just some odd double imaging coming from GodRays, and some reflections that are to deep in depth, similar to what we had in Witcher 3 way back when. You resolved that ?reflection problem - what was the approach you used, I can't remember?
Biggest problem with this game at the moment (at least while fixing it) is that it keeps crashing every 5 minutes, so it's slow going.
Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278
I'm taking a look at these crashes now.
Do you still have the crashes if you set "get_resolution_from = depth_stencil" as DHR was trying?
Also worth trying that will help narrow it down- try the old 1.0.1 version. No overlay, no DXGI stuff. It would be very interesting to know if the missing shaders can be hunted with that version, and also whether it crashes.
Not a huge rush, that will just help clarify where to look.
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
On the off chance that fixes these crashes for you to, I made a new build with that fix: 1.2.8
https://github.com/bo3b/3Dmigoto/releases/download/1.2.8/3Dmigoto-1.2.8.zip
I looked briefly at the exception during Decompile, but every example that I saw was for Domain Shaders. If we need the DS, I can prioritize looking at these, but otherwise these are not significant.
It's always possible that a DomainShader and Tesselation is somehow related to the mystery shader problem. It sounds like you resolved that with setting the compute shaders to off in the .ini though.
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
Fallout 4 Radiation Check Contest
https://contests.nvidia.com/en-us/fallout-4-radiation-check
@bo3b: You are using the default ini included? i want to compare with mine, that i change a few stuff for hunting
Also try with render target dimensions and the HUD disappear, but not the object related (maybe i'm doing something wrong). The HUD in this game is "special", for example normally in HUD elements you can found more that 1 texture, in this game all HUD shaders have 1 texture only, and also noticed that for the same element of the HUD there are 2 VS that control that part of the HUD, for example
VS 1 controls crosshair and energy bar
VS 2 controls crosshair, energy bar, and af few more stuff
Also the HUD related to the armor fill almost 40% of the screen, there are 5 shaders related that also controls objects (also 1 texture only / also test render target, same results), so i will have to leave that way....is in depth, so is a little anoying with the gun.
@Helifax: Altering the output in PS, changes the color. So is not an option in this game.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Like my work? Donations can be made via PayPal to: rauti@inetmx.de
CRAP! :( That's a bummer....
I also tested the game with the latest 3DMigoto 1.28 (with the default ini where I just changed the stuff to dump shaders and hunting=2).
Left it running on my laptop for around 45 minutes, no crashes. But then again I haven't ALT+TAB nor did actually play the game :-s Maybe this is why it worked?
Which reminds me of Dragon Age: Inquisition. We had the same issue there where it would crash on ALT+TAB (or soon after). The way we tackled that problem was to use 2 PCs: One for running the game and ofc dumping the shaders, the other to open the dumped shaders and editing;) This way we were able to hunt and fix the shaders without ALT+TAB involved ^_^ Maybe this will work here? (if this is the problem you are seeing).
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)
In addition to the crash I fixed in 1.2.8 (which can crash FC4 on launch), I've also fixed an issue with the texture hashes for compressed textures and texture arrays (which unfortunately might break existing fixes, but I've tried to minimise that possibility by not fixing any hashes which would work - more testing is needed to be sure if that's ok), and some problems when 3D is disabled via the control panel.
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
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'm still have the crash and is 100% of the times at aprox. 10 min of playing. Happens also if i don't ALT-TAB in the game.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
https://github.com/bo3b/3Dmigoto/releases/tag/1.2.9
This version also fixes some of the texture CRC calculations (specifically for compressed textures and texture arrays), which has the potential to change some of the texture hashes... I've left any hashes that were "good enough" alone, which hopefully will mean this won't have too much impact, but I haven't checked every game that was using these. @DHR - since you have used these pretty extensively would you mind checking if it has broken any of your fixes?
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 1.2.9 fix the crash!!!
I will take a look other fixes when i use texture separation.
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Awesome! Glad to hear that DarkStarSword found the culprit. Great one!
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
BTW if we can be of any help, any grunt work, like just running around in the game and spot textures/effects that are at the wrong depth, feel free to ask! I'd gladly help! (given instruction on how to identify shaders :))
Note: I played the game for a good 8 hours without any glitch or crash. Seems like a stable setup I have. If this can help iron out some bugs that we don't know if they're from the game or the 3D fix, I can test out bugs too.
Installed it to game directory but it didnt fix 3D issues. Do I miss something or its not a fix?
i5 2500K/16gb/GTX 970/Asus VG278H + Sony HMZ-T1