That depends on how they are copied, and is one of the main reasons that you can specify whether they are copied by reference or using a full copy, and also why you can limit the number of copies per frame if using an intermediate resource.
I designed the defaults so that you usually wouldn't have to think about it and just let 3DMigoto take care of it, but it's conservative - if you know something is safe to copy by reference you can use the keyword to override it's behavior:
- If you are copying directly from one slot to another of the same type, 3DMigoto will default to copy by reference.
- If you are copying directly from one slot to another of a different type, 3DMigoto will default to a full copy (as the bind flags are unlikely to work copying by reference and there might be an input/output conflict).
- Whenever you copy anything *to* an intermediate resource, 3DMigoto will default to a full copy to minimise surprises if the game changes the resource later, to prevent input/output conflicts, and to make sure that it will have appropriate bind flags in case you copy the intermediate resource to a different slot type later.
- Whenever you copy something to the pipeline *from* an intermediate resource, 3DMigoto will default to copying by reference, and it will have created the intermediate resource with appropriate bind flags to allow this (provided that it was copied to the intermediate resource with a full copy - bind flags cannot be changed when copying by reference).
When copying by reference it is just a pointer. Full copies are performed on the GPU and should not have too much impact so long as you don't do too many of them (hence max_copies_per_frame).
That depends on how they are copied, and is one of the main reasons that you can specify whether they are copied by reference or using a full copy, and also why you can limit the number of copies per frame if using an intermediate resource.
I designed the defaults so that you usually wouldn't have to think about it and just let 3DMigoto take care of it, but it's conservative - if you know something is safe to copy by reference you can use the keyword to override it's behavior:
- If you are copying directly from one slot to another of the same type, 3DMigoto will default to copy by reference.
- If you are copying directly from one slot to another of a different type, 3DMigoto will default to a full copy (as the bind flags are unlikely to work copying by reference and there might be an input/output conflict).
- Whenever you copy anything *to* an intermediate resource, 3DMigoto will default to a full copy to minimise surprises if the game changes the resource later, to prevent input/output conflicts, and to make sure that it will have appropriate bind flags in case you copy the intermediate resource to a different slot type later.
- Whenever you copy something to the pipeline *from* an intermediate resource, 3DMigoto will default to copying by reference, and it will have created the intermediate resource with appropriate bind flags to allow this (provided that it was copied to the intermediate resource with a full copy - bind flags cannot be changed when copying by reference).
When copying by reference it is just a pointer. Full copies are performed on the GPU and should not have too much impact so long as you don't do too many of them (hence max_copies_per_frame).
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Thanks, all is clear now. There is still one thing that wonders me though.
Let's say I copy by reference some constant buffer, but the vertex shader I'm referencing from is a postprocess effect and the destination is a model Vertex shader which is called first.
What in that case? Will data be one frame late when I copy? Will it work when I reference? Does the order of calling shaders matter at all?
Thanks, all is clear now. There is still one thing that wonders me though.
Let's say I copy by reference some constant buffer, but the vertex shader I'm referencing from is a postprocess effect and the destination is a model Vertex shader which is called first.
What in that case? Will data be one frame late when I copy? Will it work when I reference? Does the order of calling shaders matter at all?
The answer is it depends on the game.
A full copy in that scenario will definitely be one frame out of date, but you can be certain that you have the right buffer.
A copy by reference might be one frame out of date, or the game might have updated it with the new values for the current frame before you use it, or it might have garbage in it if the game overwrote it with completely unrelated values.
You can use frame analysis' logging support to see what calls the game makes on the context (and as of 1.2.26 even across several frames) to try to work out when/how it updates them, and you can combine that with dump_cb_txt to dump out all constant buffers bound to the pipeline on every draw call.
A full copy in that scenario will definitely be one frame out of date, but you can be certain that you have the right buffer.
A copy by reference might be one frame out of date, or the game might have updated it with the new values for the current frame before you use it, or it might have garbage in it if the game overwrote it with completely unrelated values.
You can use frame analysis' logging support to see what calls the game makes on the context (and as of 1.2.26 even across several frames) to try to work out when/how it updates them, and you can combine that with dump_cb_txt to dump out all constant buffers bound to the pipeline on every draw call.
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
As 3Dmigoto has helped to fix so many issues with Dx11 games I wanted to ask if it could help with 2 problems I generally have with Dx11 games. I'm sorry if this questions were already answered before or are just stupid :(
1. Run DX11 games in windowed mode with 3DVision in shutter mode enabled (as it is possible for Dx9 games):
It is interesting that S3D in windowed mode works with 3D vision discover (anaglyph) for Dx11. Only the shutter mode is disabled. Could 3Dmigoto be used to force shutter glasses S3D in windowed mode?
2. Increase depth for compatibility mode:
I know that the most important feature of 3Dmigoto is to replace the "fake 3D" of the CM with real 3D. Nevertheless there are some games I have to play in CM because there is no fix available/possibe and it feels to me still much better than plain 2D. I can also tolerate some CM artefacts as halos etc. but I often wish to get more depth. Unfortunately CM seems to ignore the value for MonitorSize so the depth hack can't be used in this case. I think 3Dmigoto can be used in combination with CM. I have already used 3Dmigoto to fix CM for Evolve. The outline markers for enemies and group members caused CM to switch to 2D which I could prevent by disabling the outlines with 3Dmigoto. So I wonder if 3Dmigoto could increase the depth for CM by "stretching" the objects to more depth. We already can change the depth of HUD elements, sky boxes etc.. So is there a way not to push everything to more depth? Not by the same value but to stretch it so we get more depth separation for the objects? And could this be done in an easy way by changing only a few shaders or a general pattern that is responsible for the depth placement? Because it wouldn't make sense if improving the experience for CM takes more effort than really fixing the game.
As 3Dmigoto has helped to fix so many issues with Dx11 games I wanted to ask if it could help with 2 problems I generally have with Dx11 games. I'm sorry if this questions were already answered before or are just stupid :(
1. Run DX11 games in windowed mode with 3DVision in shutter mode enabled (as it is possible for Dx9 games):
It is interesting that S3D in windowed mode works with 3D vision discover (anaglyph) for Dx11. Only the shutter mode is disabled. Could 3Dmigoto be used to force shutter glasses S3D in windowed mode?
2. Increase depth for compatibility mode:
I know that the most important feature of 3Dmigoto is to replace the "fake 3D" of the CM with real 3D. Nevertheless there are some games I have to play in CM because there is no fix available/possibe and it feels to me still much better than plain 2D. I can also tolerate some CM artefacts as halos etc. but I often wish to get more depth. Unfortunately CM seems to ignore the value for MonitorSize so the depth hack can't be used in this case. I think 3Dmigoto can be used in combination with CM. I have already used 3Dmigoto to fix CM for Evolve. The outline markers for enemies and group members caused CM to switch to 2D which I could prevent by disabling the outlines with 3Dmigoto. So I wonder if 3Dmigoto could increase the depth for CM by "stretching" the objects to more depth. We already can change the depth of HUD elements, sky boxes etc.. So is there a way not to push everything to more depth? Not by the same value but to stretch it so we get more depth separation for the objects? And could this be done in an easy way by changing only a few shaders or a general pattern that is responsible for the depth placement? Because it wouldn't make sense if improving the experience for CM takes more effort than really fixing the game.
My original display name is 3d4dd - for some reason Nvidia changed it..?!
WOW, I finally get 3DMigoto to build on my machine.
Only took me a year to get it running :)
My old machine started dying 1,5 years ago what should have been a SLI upgrade turned into a broken mainboard and replacing a chunk of the computer including CPU. Never got it stable after that with loads of BSOD problems whatever I tried but that is in the past.
The solution was pretty simple, installing VS2013 and Windows 8.0 SDK pretty much.
I wasn't too keen on running multiple copies of VS.
My wrapper is newer so it turned out using compiler47 and 8.1 SDK which was convenient as compiler47 is preloaded on windows 8.1. Not as much fun on W7/W8 though.
I find it interesting that my wrapper is faster in Witcher 3 than 3DMigoto in a pretty brief test. Approximately 10% more fps. Need to do more testing, bo3b has made 3DMigoto pretty damn fast.
WOW, I finally get 3DMigoto to build on my machine.
Only took me a year to get it running :)
My old machine started dying 1,5 years ago what should have been a SLI upgrade turned into a broken mainboard and replacing a chunk of the computer including CPU. Never got it stable after that with loads of BSOD problems whatever I tried but that is in the past.
The solution was pretty simple, installing VS2013 and Windows 8.0 SDK pretty much.
I wasn't too keen on running multiple copies of VS.
My wrapper is newer so it turned out using compiler47 and 8.1 SDK which was convenient as compiler47 is preloaded on windows 8.1. Not as much fun on W7/W8 though.
I find it interesting that my wrapper is faster in Witcher 3 than 3DMigoto in a pretty brief test. Approximately 10% more fps. Need to do more testing, bo3b has made 3DMigoto pretty damn fast.
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?
Did some more limited testing.
This time using Crysis 3 which took me a while to get up and running on real 3D.
I couldn't get the old 3DMigoto to work with the game at all.
With the latest build it ran at about 37fps at the testing scenario while flugan wrapper would take the step to 38fps so no real difference there. One question is texture hashing where I'm using the old fix with md5 hashes while 3DMigoto is using hardware accelerated CRCs so newer 3DMigoto has lower overhead but is not compatible with the actual fix being applied. A kind of apples to oranges comparison.
I have no idea why the supplied 3DMigoto wrapper won't work with Crysis 3.
I will do more testing when I get time.
This time using Crysis 3 which took me a while to get up and running on real 3D.
I couldn't get the old 3DMigoto to work with the game at all.
With the latest build it ran at about 37fps at the testing scenario while flugan wrapper would take the step to 38fps so no real difference there. One question is texture hashing where I'm using the old fix with md5 hashes while 3DMigoto is using hardware accelerated CRCs so newer 3DMigoto has lower overhead but is not compatible with the actual fix being applied. A kind of apples to oranges comparison.
I have no idea why the supplied 3DMigoto wrapper won't work with Crysis 3.
I will do more testing when I get time.
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?
Which version of 3DMigoto are you using for comparisons (right click -> properties -> details -> product version), and which version of the Witcher 3 fix (there are some WIP changes on github that have not been published on the blog yet, and the version on the blog has had some changes since the original release that use new 3DMigoto functionality)?
If you're comparing Witcher 3 you need to disable all the functionality that is only supported by 3DMigoto, in particular all the [ShaderOverrideUI*] sections, [ShaderOverrideHBAODepthPass] and [Present]. If memory serves you did implement fake_o0, so you can leave [ShaderOverrideHairworksDepthMSAAResolver].
You can use profiling tools to try to identify where the bottlenecks are coming from so we know what to concentrate on to improve it. VS2013 express doesn't have these, but VS2015 community does.
One piece of low hanging fruit would be to disable the texture hashes since the Witcher 3 fix predates texture filtering and isn't using any TextureOverride sections, but I've got some fairly substantial changes on the way in this area (I'm changing the texture hashes again to make track_texture_updates less expensive) and as part of that I'll be skipping calculating any unnecessary hashes.
The Crysis 3 fix uses texture filtering so disabling texture hashes obviously isn't an answer there. My pending improvements might help as it would skip hashing a lot of textures that can't be part of the fix in release mode, but since the texture hashes will change someone would need to update it to use the new hashes, and without any clear benefit for that game it's probably not worth the effort.
Which version of 3DMigoto are you using for comparisons (right click -> properties -> details -> product version), and which version of the Witcher 3 fix (there are some WIP changes on github that have not been published on the blog yet, and the version on the blog has had some changes since the original release that use new 3DMigoto functionality)?
If you're comparing Witcher 3 you need to disable all the functionality that is only supported by 3DMigoto, in particular all the [ShaderOverrideUI*] sections, [ShaderOverrideHBAODepthPass] and [Present]. If memory serves you did implement fake_o0, so you can leave [ShaderOverrideHairworksDepthMSAAResolver].
You can use profiling tools to try to identify where the bottlenecks are coming from so we know what to concentrate on to improve it. VS2013 express doesn't have these, but VS2015 community does.
One piece of low hanging fruit would be to disable the texture hashes since the Witcher 3 fix predates texture filtering and isn't using any TextureOverride sections, but I've got some fairly substantial changes on the way in this area (I'm changing the texture hashes again to make track_texture_updates less expensive) and as part of that I'll be skipping calculating any unnecessary hashes.
The Crysis 3 fix uses texture filtering so disabling texture hashes obviously isn't an answer there. My pending improvements might help as it would skip hashing a lot of textures that can't be part of the fix in release mode, but since the texture hashes will change someone would need to update it to use the new hashes, and without any clear benefit for that game it's probably not worth the effort.
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
Anyway after spending way too much time testing and desperately looking at my code I'm at a loss. The ini parameters don't seem to transfer properly using multiple versions of my code and the "standard" version will not even load the current version of witcher 3. The values are being read from the ini, the texture and resourceview is being created and is being passed allong with all the SetShader calls but HUD depth is still stuck at 0. Replacing with 3DMigoto and HUD is at depth as configured by X.
Performance results, no wrapper 28fps, 3DMigoto 28fps latest Flugan 31fps!!! WTF is happening. Doesn't really matter. Debugging don't work, logging shows no problem. The only visible problem with limited testing is HUD at screen depth.
Anyway after spending way too much time testing and desperately looking at my code I'm at a loss. The ini parameters don't seem to transfer properly using multiple versions of my code and the "standard" version will not even load the current version of witcher 3. The values are being read from the ini, the texture and resourceview is being created and is being passed allong with all the SetShader calls but HUD depth is still stuck at 0. Replacing with 3DMigoto and HUD is at depth as configured by X.
Performance results, no wrapper 28fps, 3DMigoto 28fps latest Flugan 31fps!!! WTF is happening. Doesn't really matter. Debugging don't work, logging shows no problem. The only visible problem with limited testing is HUD at screen depth.
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?
If you're trying the ShaderFixes from github some of them use #include <x64\ShaderFixes\hud.hlsl> so you might want to check that you are using the default include handler when you D3DCompile those and not passing NULL instead (at some point I might switch to a custom include handler to normalise the paths so they are relative to the dll and remove that x64\ that should not be there).
[quote="Flugan"]Performance results, no wrapper 28fps, 3DMigoto 28fps latest Flugan 31fps!!! WTF is happening.[/quote]Haha! Makes no sense but maybe you can market your wrapper as an accelerator :)
If you're trying the ShaderFixes from github some of them use #include <x64\ShaderFixes\hud.hlsl> so you might want to check that you are using the default include handler when you D3DCompile those and not passing NULL instead (at some point I might switch to a custom include handler to normalise the paths so they are relative to the dll and remove that x64\ that should not be there).
Flugan said:Performance results, no wrapper 28fps, 3DMigoto 28fps latest Flugan 31fps!!! WTF is happening.
Haha! Makes no sense but maybe you can market your wrapper as an accelerator :)
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
Sorry for repeating my question about increasing the depth of a game in the case that the monitorsize hack doesn't work (as in CM). I remember some games already using this as a cinematic effect. It's called the "Vertigo effect" and looks like this (0:31 and 0:49):
https://www.youtube.com/watch?v=je0NhvAQ6fM
Of course it is not the transition effect itself but the final result I would like to reproduce. Do You think that this can be done by changing shader elements with 3Dmigoto?
Sorry for repeating my question about increasing the depth of a game in the case that the monitorsize hack doesn't work (as in CM). I remember some games already using this as a cinematic effect. It's called the "Vertigo effect" and looks like this (0:31 and 0:49):
Of course it is not the transition effect itself but the final result I would like to reproduce. Do You think that this can be done by changing shader elements with 3Dmigoto?
My original display name is 3d4dd - for some reason Nvidia changed it..?!
I'm quite familiar with that effect and what produces it from my other hobby - it's usually known as a "dolly zoom": https://en.wikipedia.org/wiki/Dolly_zoom
At the end of that transition the camera has moved forwards very close to the subject, and the lens has been zoomed out so that the FOV is much wider. You get the same exaggerated depth effect on a still photo when using an ultra-wide angle lens and moving very close to the subject (conversely this is generally best avoided when taking photos of people, because it exaggerates features like the noses and looks weird), and the same would happen in video games as well with the equivalent camera settings and positioning.
As to the question of whether you could do this with 3DMigoto for compatibility mode... technically yes - you could modify all the vertex shaders to use a wider FOV and move everything closer to the camera, but in doing so you would cause the same types of breakages that the driver does when it converts something to real 3D, which would then need to be repaired in a similar way, so there doesn't seem to be much point as you are just creating more work. Instead, I'd suggest checking if it is possible to just run the game at a higher FOV.
But will that give CM mode any more depth... probably not, at least not much - infinity is still infinity and that's pretty limited in CM. It might have an impact on things closer to the camera... but you may not be able to move the camera close enough to the subject to get that effect (in photography a common mistake is assuming that an ultra-wide angle lens will let you "fit more in the frame" - technically true, but that line of thinking tends to just lead to empty photos).
[quote="3d4dd"]1. Run DX11 games in windowed mode with 3DVision in shutter mode enabled (as it is possible for Dx9 games):
It is interesting that S3D in windowed mode works with 3D vision discover (anaglyph) for Dx11. Only the shutter mode is disabled. Could 3Dmigoto be used to force shutter glasses S3D in windowed mode?[/quote]If we knew of a way to make that work we would have done it already - that's entirely in the hands of the driver. Maybe there is a setting or API to allow this that we don't know of, but we haven't found any.
At the end of that transition the camera has moved forwards very close to the subject, and the lens has been zoomed out so that the FOV is much wider. You get the same exaggerated depth effect on a still photo when using an ultra-wide angle lens and moving very close to the subject (conversely this is generally best avoided when taking photos of people, because it exaggerates features like the noses and looks weird), and the same would happen in video games as well with the equivalent camera settings and positioning.
As to the question of whether you could do this with 3DMigoto for compatibility mode... technically yes - you could modify all the vertex shaders to use a wider FOV and move everything closer to the camera, but in doing so you would cause the same types of breakages that the driver does when it converts something to real 3D, which would then need to be repaired in a similar way, so there doesn't seem to be much point as you are just creating more work. Instead, I'd suggest checking if it is possible to just run the game at a higher FOV.
But will that give CM mode any more depth... probably not, at least not much - infinity is still infinity and that's pretty limited in CM. It might have an impact on things closer to the camera... but you may not be able to move the camera close enough to the subject to get that effect (in photography a common mistake is assuming that an ultra-wide angle lens will let you "fit more in the frame" - technically true, but that line of thinking tends to just lead to empty photos).
3d4dd said:1. Run DX11 games in windowed mode with 3DVision in shutter mode enabled (as it is possible for Dx9 games):
It is interesting that S3D in windowed mode works with 3D vision discover (anaglyph) for Dx11. Only the shutter mode is disabled. Could 3Dmigoto be used to force shutter glasses S3D in windowed mode?
If we knew of a way to make that work we would have done it already - that's entirely in the hands of the driver. Maybe there is a setting or API to allow this that we don't know of, but we haven't found any.
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,
I am trying to implement the auto-depth crosshair fix. But I am stuck at basically first step.
How do I find out if the depth buffer is enabled during a shader execution?
Actually I want to copy it from a different shader like here:
[quote]
Option 3: Copy from another shader (may make step 5 easier)
If the depth buffer is not assigned when the UI shader is drawn you can't just copy it directly and will need to copy it from a separate shader. This should not be too difficult as the depth buffer is typically available all over the place. You might even be able to find a version that has been pre-scaled to world coordinates (a "W-buffer"), which will make step 5 trivial.
e.g. you might copy it out of a shadow shader:
[ResourceDepthBuffer]
[ShaderOverrideShadow]
Hash = ...
; There's a good chance that copying by reference will work as we are copying a
; texture for use in a texture slot (same type of binding), and if it works this
; will save us the copy and extra storage:
ResourceDepthBuffer = reference ps-t0
; But if it doesn't work (maybe the game overwrites the texture afterwards),
; use a full copy instead, which is the default when copying to a temporary
; resource so we don't need to explicitly say so:
;ResourceDepthBuffer = ps-t0
[ShaderOverrideCrosshair]
Hash = ...
vs-t110 = ResourceDepthBuffer
[/quote]
But I am at a total loss... First of all:
- The hash can be of a vertex or pixel shader? or requires a special shader type?
- I don't understand this: "ResourceDepthBuffer = ps-t0" who is t0? Is it texture target zero? Do I need to use the Frame Analysis for this?
I have used the ShaderUsage file and I got this:
[code]
<PixelShader hash="3020ae9d794bc65e">
<ParentVertexShaders>b65139cd6130cd09 </ParentVertexShaders>
<Register id=0 handle=0000000013683A90>ba8af3fa</Register>
<Register id=0 handle=000000005DC6E3D0>4fca86ca</Register>
<Register id=0 handle=000000005DCAC4D0>5718061d</Register>
<Register id=0 handle=000000005DCCF090>7844a6c7</Register>
<Register id=0 handle=000000005DCCF950>71151c5c</Register>
<Register id=0 handle=000000005DE64A90 hash_contaminated=true>6e469011</Register>
<Register id=0 handle=0000000091890990 hash_contaminated=true>3315d2b5</Register>
<Register id=0 handle=0000000282CAEE10>cf8f57cc</Register>
<Register id=0 handle=0000000282CEC550>63436e8a</Register>
<Register id=1 handle=000000001367D6D0 hash_contaminated=true>02af55eb</Register>
<Register id=2 handle=0000000013D5DAD0>c6167b52</Register>
<Register id=3 handle=000000012CA5C450>f805542d</Register>
<Register id=4 handle=00000002834D28D0>4ce8bfab</Register>
<Register id=5 handle=000000012FDF0950>47b437e9</Register>
<Register id=5 handle=0000000231171090>596044c5</Register>
<Register id=6 handle=000000012CF36010>94ba8024</Register>
<Register id=6 handle=0000000231171510>0728ea33</Register>
<Register id=7 handle=000000012D42FE90>e3696c73</Register>
<Register id=7 handle=000000012D4300D0>9cde57de</Register>
<Register id=8 handle=000000021AA59B50>4abc56b4</Register>
<Register id=8 handle=000000022B402D50>a8e02bce</Register>
<Register id=9 handle=000000012CF35DD0>908a11a4</Register>
<Register id=9 handle=000000022B402B10>c3c16e73</Register>
<Register id=10 handle=000000012D42FE90>e3696c73</Register>
<Register id=10 handle=000000012D430310>94ba8024</Register>
<Register id=11 handle=000000012CB28CD0>588e2a7e</Register>
<Register id=11 handle=000000012D42FE90>e3696c73</Register>
<Register id=12 handle=000000012FDF0710>62ded84d</Register>
<Register id=12 handle=000000022B4028D0>6b1dc74e</Register>
<Register id=13 handle=000000012CF36210>3776874e</Register>
<Register id=13 handle=000000012D4300D0>9cde57de</Register>
<Register id=14 handle=0000000051F0F450>4bcf8033</Register>
<Register id=14 handle=000000012FDF0950>47b437e9</Register>
<Register id=15 handle=000000012CF36010>94ba8024</Register>
<Register id=15 handle=000000013FA93810>571cdb40</Register>
<Register id=16 handle=000000012CB28CD0>588e2a7e</Register>
<Register id=17 handle=0000000092421950>f3390264</Register>
<Register id=18 handle=000000012D6564D0>267e24af</Register>
<Register id=19 handle=000000012D6564D0>267e24af</Register>
<Register id=20 handle=000000013FA79410>b055dcb6</Register>
<Register id=21 handle=000000013FA79650>11c22927</Register>
<Register id=22 handle=00000002311605D0>c367c5e8</Register>
<Register id=23 handle=000000013FA78FD0>e18cb157</Register>
<Register id=24 handle=000000012D430510>8ea46149</Register>
<Register id=25 handle=000000012D430750>429c9785</Register>
<Register id=26 handle=000000012D430750>429c9785</Register>
<Register id=27 handle=000000012D42FE90>e3696c73</Register>
<Register id=28 handle=000000012D430510>8ea46149</Register>
<Register id=40 handle=0000000013683A90>ba8af3fa</Register>
<Register id=43 handle=0000000051E872D0>2df04740</Register>
<Register id=44 handle=00000000099C6310 hash_contaminated=true>dc7e5674</Register>
<Register id=53 handle=0000000013F77190>36f63b9f</Register>
<Register id=53 handle=00000000919FFB10>36f63b9f</Register>
<Register id=54 handle=00000000099C5A50>00000000</Register>
<Register id=56 handle=00000000099C4490>873be7b9</Register>
<Register id=57 handle=00000000099C48D0 hash_contaminated=true>18911d61</Register>
<Register id=58 handle=0000000051604690>588e2a7e</Register>
<Register id=58 handle=000000009282E850>588e2a7e</Register>
<Register id=120 handle=000000000642E550>00000000</Register>
<Register id=125 handle=000000000644EB90>00000000</Register>
<RenderTarget id=0 handle=0000000013F76490>fa5b122d</RenderTarget>
<DepthTarget handle=0000000013F766D0>a98c980a</DepthTarget>
</PixelShader>
[/code]
This is the pixel shader used by the HUD vertex shader (that I want to correct). I looked at the vertex shader and don't see a <DepthTarget handle=0000000013F766D0>a98c980a</DepthTarget> bound there...
But for example I want to use a shader like this (that has the DepthTarget bound) to copy the Depth Buffer. How exactly do I go on about it?
Do I need to go inside the shader and generate an output variable and then put the DepthTexture inside or??
Any help is appreciated.
Edit:
I was wondering if I can use a shader that defines this:
[code]
SamplerComparisonState SamplerGenericShadowCompare_s : register(s14);
Texture2D<float4> DepthBufferTexture_texture : register(t1);
Texture2D<float4> ShadowMapSampler_texture : register(t43);
[/code]
where register t1 is basically the DepthBuffer Texture. I could then say something like this:
[code]
[ResourceDepthBuffer]
[ShaderOverrideShadow]
Hash = 0xFFFFFF // whatever HASH of the PIxel shader that has the Depth Buffer texture
ResourceDepthBuffer = reference ps-t1
[ShaderOverrideCrosshair]
Hash = 0xFFFFF //VS hash code of the HUD
vs-t110 = ResourceDepthBuffer // This needs to be the same as is used by the crosshair.hlsl
[/code]
It should work no?
I am still very interested in the first approach though;) If I didn't came across this shader, how would one go about to extract the information. (Frame Analysis, ShaderUsage.txt )?
Big thank you in advance!
I am trying to implement the auto-depth crosshair fix. But I am stuck at basically first step.
How do I find out if the depth buffer is enabled during a shader execution?
Actually I want to copy it from a different shader like here:
Option 3: Copy from another shader (may make step 5 easier)
If the depth buffer is not assigned when the UI shader is drawn you can't just copy it directly and will need to copy it from a separate shader. This should not be too difficult as the depth buffer is typically available all over the place. You might even be able to find a version that has been pre-scaled to world coordinates (a "W-buffer"), which will make step 5 trivial.
e.g. you might copy it out of a shadow shader:
[ResourceDepthBuffer]
[ShaderOverrideShadow]
Hash = ...
; There's a good chance that copying by reference will work as we are copying a
; texture for use in a texture slot (same type of binding), and if it works this
; will save us the copy and extra storage:
ResourceDepthBuffer = reference ps-t0
; But if it doesn't work (maybe the game overwrites the texture afterwards),
; use a full copy instead, which is the default when copying to a temporary
; resource so we don't need to explicitly say so:
;ResourceDepthBuffer = ps-t0
But I am at a total loss... First of all:
- The hash can be of a vertex or pixel shader? or requires a special shader type?
- I don't understand this: "ResourceDepthBuffer = ps-t0" who is t0? Is it texture target zero? Do I need to use the Frame Analysis for this?
This is the pixel shader used by the HUD vertex shader (that I want to correct). I looked at the vertex shader and don't see a <DepthTarget handle=0000000013F766D0>a98c980a</DepthTarget> bound there...
But for example I want to use a shader like this (that has the DepthTarget bound) to copy the Depth Buffer. How exactly do I go on about it?
Do I need to go inside the shader and generate an output variable and then put the DepthTexture inside or??
Any help is appreciated.
Edit:
I was wondering if I can use a shader that defines this:
where register t1 is basically the DepthBuffer Texture. I could then say something like this:
[ResourceDepthBuffer]
[ShaderOverrideShadow]
Hash = 0xFFFFFF // whatever HASH of the PIxel shader that has the Depth Buffer texture
ResourceDepthBuffer = reference ps-t1
[ShaderOverrideCrosshair]
Hash = 0xFFFFF //VS hash code of the HUD
vs-t110 = ResourceDepthBuffer // This needs to be the same as is used by the crosshair.hlsl
It should work no?
I am still very interested in the first approach though;) If I didn't came across this shader, how would one go about to extract the information. (Frame Analysis, ShaderUsage.txt )?
Big thank you in advance!
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
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
@DDS: Thank Your for Your very interesting explanation how this changed depth perception is simulated in 2D mediums! I should have known that I talk to an expert and so I better had choosen another example for illustrating my intention. In fact I don't want to simulate exactly this technique but just increase the separation the same way I do when using the wheel on the emitter. But You have already mentioned that changing shaders could break the CM and that there are limitations regarding infinity in CM. There also seems to be a difference how CM makes use of its limited infinity. I have played Rise of the Tomb Raider in CM and observed that in open areas the skybox has an acceptable depth (infinity). However distant mountains where not placed at the depth of the skybox but so much closer. So the landscape gets sqeezed to quite a low depth level although there would be much more space available in front of the skybox. After that I have played SNOW in CM (AC Unity profile) and had a much better experience (almost real 3D) as in this case the landscape was presented in all the depth levels that are available. Indeed CM is just a workaround but no real solution...
Regarding S3D for windowed mode in Dx11 games I was just surprised that it works with 3D vision discover. I thought it wouldn't work per se. So it's even more annoying that the shutter mode can't be activated.
@DDS: Thank Your for Your very interesting explanation how this changed depth perception is simulated in 2D mediums! I should have known that I talk to an expert and so I better had choosen another example for illustrating my intention. In fact I don't want to simulate exactly this technique but just increase the separation the same way I do when using the wheel on the emitter. But You have already mentioned that changing shaders could break the CM and that there are limitations regarding infinity in CM. There also seems to be a difference how CM makes use of its limited infinity. I have played Rise of the Tomb Raider in CM and observed that in open areas the skybox has an acceptable depth (infinity). However distant mountains where not placed at the depth of the skybox but so much closer. So the landscape gets sqeezed to quite a low depth level although there would be much more space available in front of the skybox. After that I have played SNOW in CM (AC Unity profile) and had a much better experience (almost real 3D) as in this case the landscape was presented in all the depth levels that are available. Indeed CM is just a workaround but no real solution...
Regarding S3D for windowed mode in Dx11 games I was just surprised that it works with 3D vision discover. I thought it wouldn't work per se. So it's even more annoying that the shutter mode can't be activated.
My original display name is 3d4dd - for some reason Nvidia changed it..?!
I designed the defaults so that you usually wouldn't have to think about it and just let 3DMigoto take care of it, but it's conservative - if you know something is safe to copy by reference you can use the keyword to override it's behavior:
- If you are copying directly from one slot to another of the same type, 3DMigoto will default to copy by reference.
- If you are copying directly from one slot to another of a different type, 3DMigoto will default to a full copy (as the bind flags are unlikely to work copying by reference and there might be an input/output conflict).
- Whenever you copy anything *to* an intermediate resource, 3DMigoto will default to a full copy to minimise surprises if the game changes the resource later, to prevent input/output conflicts, and to make sure that it will have appropriate bind flags in case you copy the intermediate resource to a different slot type later.
- Whenever you copy something to the pipeline *from* an intermediate resource, 3DMigoto will default to copying by reference, and it will have created the intermediate resource with appropriate bind flags to allow this (provided that it was copied to the intermediate resource with a full copy - bind flags cannot be changed when copying by reference).
When copying by reference it is just a pointer. Full copies are performed on the GPU and should not have too much impact so long as you don't do too many of them (hence max_copies_per_frame).
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
Let's say I copy by reference some constant buffer, but the vertex shader I'm referencing from is a postprocess effect and the destination is a model Vertex shader which is called first.
What in that case? Will data be one frame late when I copy? Will it work when I reference? Does the order of calling shaders matter at all?
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
A full copy in that scenario will definitely be one frame out of date, but you can be certain that you have the right buffer.
A copy by reference might be one frame out of date, or the game might have updated it with the new values for the current frame before you use it, or it might have garbage in it if the game overwrote it with completely unrelated values.
You can use frame analysis' logging support to see what calls the game makes on the context (and as of 1.2.26 even across several frames) to try to work out when/how it updates them, and you can combine that with dump_cb_txt to dump out all constant buffers bound to the pipeline on every draw call.
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
1. Run DX11 games in windowed mode with 3DVision in shutter mode enabled (as it is possible for Dx9 games):
It is interesting that S3D in windowed mode works with 3D vision discover (anaglyph) for Dx11. Only the shutter mode is disabled. Could 3Dmigoto be used to force shutter glasses S3D in windowed mode?
2. Increase depth for compatibility mode:
I know that the most important feature of 3Dmigoto is to replace the "fake 3D" of the CM with real 3D. Nevertheless there are some games I have to play in CM because there is no fix available/possibe and it feels to me still much better than plain 2D. I can also tolerate some CM artefacts as halos etc. but I often wish to get more depth. Unfortunately CM seems to ignore the value for MonitorSize so the depth hack can't be used in this case. I think 3Dmigoto can be used in combination with CM. I have already used 3Dmigoto to fix CM for Evolve. The outline markers for enemies and group members caused CM to switch to 2D which I could prevent by disabling the outlines with 3Dmigoto. So I wonder if 3Dmigoto could increase the depth for CM by "stretching" the objects to more depth. We already can change the depth of HUD elements, sky boxes etc.. So is there a way not to push everything to more depth? Not by the same value but to stretch it so we get more depth separation for the objects? And could this be done in an easy way by changing only a few shaders or a general pattern that is responsible for the depth placement? Because it wouldn't make sense if improving the experience for CM takes more effort than really fixing the game.
My original display name is 3d4dd - for some reason Nvidia changed it..?!
Only took me a year to get it running :)
My old machine started dying 1,5 years ago what should have been a SLI upgrade turned into a broken mainboard and replacing a chunk of the computer including CPU. Never got it stable after that with loads of BSOD problems whatever I tried but that is in the past.
The solution was pretty simple, installing VS2013 and Windows 8.0 SDK pretty much.
I wasn't too keen on running multiple copies of VS.
My wrapper is newer so it turned out using compiler47 and 8.1 SDK which was convenient as compiler47 is preloaded on windows 8.1. Not as much fun on W7/W8 though.
I find it interesting that my wrapper is faster in Witcher 3 than 3DMigoto in a pretty brief test. Approximately 10% more fps. Need to do more testing, bo3b has made 3DMigoto pretty damn fast.
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
What about other games? Are you able to make some more testing?
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
This time using Crysis 3 which took me a while to get up and running on real 3D.
I couldn't get the old 3DMigoto to work with the game at all.
With the latest build it ran at about 37fps at the testing scenario while flugan wrapper would take the step to 38fps so no real difference there. One question is texture hashing where I'm using the old fix with md5 hashes while 3DMigoto is using hardware accelerated CRCs so newer 3DMigoto has lower overhead but is not compatible with the actual fix being applied. A kind of apples to oranges comparison.
I have no idea why the supplied 3DMigoto wrapper won't work with Crysis 3.
I will do more testing when I get time.
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
If you're comparing Witcher 3 you need to disable all the functionality that is only supported by 3DMigoto, in particular all the [ShaderOverrideUI*] sections, [ShaderOverrideHBAODepthPass] and [Present]. If memory serves you did implement fake_o0, so you can leave [ShaderOverrideHairworksDepthMSAAResolver].
You can use profiling tools to try to identify where the bottlenecks are coming from so we know what to concentrate on to improve it. VS2013 express doesn't have these, but VS2015 community does.
One piece of low hanging fruit would be to disable the texture hashes since the Witcher 3 fix predates texture filtering and isn't using any TextureOverride sections, but I've got some fairly substantial changes on the way in this area (I'm changing the texture hashes again to make track_texture_updates less expensive) and as part of that I'll be skipping calculating any unnecessary hashes.
The Crysis 3 fix uses texture filtering so disabling texture hashes obviously isn't an answer there. My pending improvements might help as it would skip hashing a lot of textures that can't be part of the fix in release mode, but since the texture hashes will change someone would need to update it to use the new hashes, and without any clear benefit for that game it's probably not worth the effort.
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
Performance results, no wrapper 28fps, 3DMigoto 28fps latest Flugan 31fps!!! WTF is happening. Doesn't really matter. Debugging don't work, logging shows no problem. The only visible problem with limited testing is HUD at screen depth.
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
Haha! Makes no sense but maybe you can market your wrapper as an accelerator :)
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
Of course it is not the transition effect itself but the final result I would like to reproduce. Do You think that this can be done by changing shader elements with 3Dmigoto?
My original display name is 3d4dd - for some reason Nvidia changed it..?!
At the end of that transition the camera has moved forwards very close to the subject, and the lens has been zoomed out so that the FOV is much wider. You get the same exaggerated depth effect on a still photo when using an ultra-wide angle lens and moving very close to the subject (conversely this is generally best avoided when taking photos of people, because it exaggerates features like the noses and looks weird), and the same would happen in video games as well with the equivalent camera settings and positioning.
As to the question of whether you could do this with 3DMigoto for compatibility mode... technically yes - you could modify all the vertex shaders to use a wider FOV and move everything closer to the camera, but in doing so you would cause the same types of breakages that the driver does when it converts something to real 3D, which would then need to be repaired in a similar way, so there doesn't seem to be much point as you are just creating more work. Instead, I'd suggest checking if it is possible to just run the game at a higher FOV.
But will that give CM mode any more depth... probably not, at least not much - infinity is still infinity and that's pretty limited in CM. It might have an impact on things closer to the camera... but you may not be able to move the camera close enough to the subject to get that effect (in photography a common mistake is assuming that an ultra-wide angle lens will let you "fit more in the frame" - technically true, but that line of thinking tends to just lead to empty photos).
If we knew of a way to make that work we would have done it already - that's entirely in the hands of the driver. Maybe there is a setting or API to allow this that we don't know of, but we haven't found any.
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 am trying to implement the auto-depth crosshair fix. But I am stuck at basically first step.
How do I find out if the depth buffer is enabled during a shader execution?
Actually I want to copy it from a different shader like here:
But I am at a total loss... First of all:
- The hash can be of a vertex or pixel shader? or requires a special shader type?
- I don't understand this: "ResourceDepthBuffer = ps-t0" who is t0? Is it texture target zero? Do I need to use the Frame Analysis for this?
I have used the ShaderUsage file and I got this:
This is the pixel shader used by the HUD vertex shader (that I want to correct). I looked at the vertex shader and don't see a <DepthTarget handle=0000000013F766D0>a98c980a</DepthTarget> bound there...
But for example I want to use a shader like this (that has the DepthTarget bound) to copy the Depth Buffer. How exactly do I go on about it?
Do I need to go inside the shader and generate an output variable and then put the DepthTexture inside or??
Any help is appreciated.
Edit:
I was wondering if I can use a shader that defines this:
where register t1 is basically the DepthBuffer Texture. I could then say something like this:
It should work no?
I am still very interested in the first approach though;) If I didn't came across this shader, how would one go about to extract the information. (Frame Analysis, ShaderUsage.txt )?
Big thank you in advance!
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)
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)
Regarding S3D for windowed mode in Dx11 games I was just surprised that it works with 3D vision discover. I thought it wouldn't work per se. So it's even more annoying that the shutter mode can't be activated.
My original display name is 3d4dd - for some reason Nvidia changed it..?!