This is not really 3D related, but I'm trying to do a HUD toggle for Infinite Warfare. I've managed to make all HUD shaders toggle except one, it went "boop" when I marked it so assume it didn't export correctly.
Anyway here's the shader in question, would really appreciate if someone could help me fix it (if that's even possible?)
// ---- Created with 3Dmigoto v1.2.43 on Mon Nov 07 21:06:24 2016
Texture2D<float4> t4 : register(t4);
[quote="Jan-Itor"]Anyway here's the shader in question, would really appreciate if someone could help me fix it (if that's even possible?)
[/quote]
The problem is in lines 180 and 181. It's trying to use v3.wz, but v3 is defined as float2 (it can only have x and y). Change those lines to
[code]
r1.xy = ddx_fine(w3.yx);
r1.zw = ddy_fine(w3.yx);
[/code]
Try that.
[quote="masterotaku"][quote="Jan-Itor"]Anyway here's the shader in question, would really appreciate if someone could help me fix it (if that's even possible?)
[/quote]
The problem is in lines 180 and 181. It's trying to use v3.wz, but v3 is defined as float2 (it can only have x and y). Change those lines to
[code]
r1.xy = ddx_fine(w3.yx);
r1.zw = ddy_fine(w3.yx);
[/code]
Try that.
[/quote]
That worked, thanks a lot!
Hello,
I'm starting to use 3Dmigoto and run into some shaders that are available as assembly only.
Looking into existing fixes I found some "reasm" files and copied the declarations
[code]
dcl_resource_texture2d (float,float,float,float) t125
ld_indexable(texture2d)(float,float,float,float) r9.xyzw, l(0, 0, 0, 0), t125.xyzw
[/code]
into the asm shader. The "dcl_temps" directive was increased from 9 to 10.
The rest of the shader is fixed similar as in Helixmod.
If I now start the game, the fixed shader is not loaded and the log files shows the following error:
[code]
error X3000: unrecognized identifier 'dcl_globalFlags'
[/code]
If I remove the errornous line, I the the following:
[code]
error X3000: unrecognized identifier 'dcl_constantbuffer'
[/code]
From that I guess that 3Dmigoto tries to compile a HLSL shader instead of asm.
What is the correct way to use asm shaders with 3Dmigoto?
I'm starting to use 3Dmigoto and run into some shaders that are available as assembly only.
Looking into existing fixes I found some "reasm" files and copied the declarations
HLSL files are named:
xxxxxxxxxxxxxxxx-ys_replace.txt
Assembly files are named:
xxxxxxxxxxxxxxxx-ys.txt
The reasm files were from the early days of the assembler to allow us to check that it actually assembled what we wrote, but that code was removed from 3DMigoto after we got cmd_Decompiler*, so maybe that is why it thinks they are HLSL (they weren't really supposed to be shipped, but a bunch of fixes included them anyway).
* The assembler has a number of gotchas if your code looks like it was written by a human instead of a machine - if something isn't behaving as you expect, use cmd_Decompiler to assemble and disassemble it then compare that to what you wrote looking for missing instructions. cmd_Decompiler is on the 3DMigoto releases page.
HLSL files are named:
xxxxxxxxxxxxxxxx-ys_replace.txt
Assembly files are named:
xxxxxxxxxxxxxxxx-ys.txt
The reasm files were from the early days of the assembler to allow us to check that it actually assembled what we wrote, but that code was removed from 3DMigoto after we got cmd_Decompiler*, so maybe that is why it thinks they are HLSL (they weren't really supposed to be shipped, but a bunch of fixes included them anyway).
* The assembler has a number of gotchas if your code looks like it was written by a human instead of a machine - if something isn't behaving as you expect, use cmd_Decompiler to assemble and disassemble it then compare that to what you wrote looking for missing instructions. cmd_Decompiler is on the 3DMigoto releases page.
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
Trying to use it in Dishonored 2, want to get rid of some shaders, specifically white trail effect on weapon swings because why not? Maybe some other shaders too.
But when I try to start the game, this shows up:
D3D11CreateDeviceAndSwapChain FAILED with error (-214702809). Please check your GPU is compatible with DirectX 11.1. Also, if you're under Windows 7, please check you've installed the Windows Platform Update
I use a single GTX 1080
Anyone have any tips?
Also tried reverting to an older version, version 1.1.14, and a new error message appeared that said
"failed to request directX 11.1 device"
Trying to use it in Dishonored 2, want to get rid of some shaders, specifically white trail effect on weapon swings because why not? Maybe some other shaders too.
But when I try to start the game, this shows up:
D3D11CreateDeviceAndSwapChain FAILED with error (-214702809). Please check your GPU is compatible with DirectX 11.1. Also, if you're under Windows 7, please check you've installed the Windows Platform Update
I use a single GTX 1080
Anyone have any tips?
Also tried reverting to an older version, version 1.1.14, and a new error message appeared that said
[quote="DarkStarSword"]Try enabling allow_create_device=2[/quote]
How? And what version of 3dmigoto should I use when doing this?
Do I add the line "allow_create_device=2" somewhere in the d3dx ini?
EDIT: I think I figured it out. Added it right at the top under the systems setting, and it showed up in the d3d11 log.
But it didn't fix anything
In general always use the latest version of 3DMigoto unless you have a good reason to do otherwise (and if you do find you need to use an old version, let us know because that means there has been a regression). There's documentation in the template d3dx.ini about the allow_ options - try the other combinations that it recommends to see if any of them make a difference. If nothing works, enable calls=1, debug=1 and unbuffered=1 under [Logging] and send us the resulting d3d11_log.txt file.
In general always use the latest version of 3DMigoto unless you have a good reason to do otherwise (and if you do find you need to use an old version, let us know because that means there has been a regression). There's documentation in the template d3dx.ini about the allow_ options - try the other combinations that it recommends to see if any of them make a difference. If nothing works, enable calls=1, debug=1 and unbuffered=1 under [Logging] and send us the resulting d3d11_log.txt file.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
[quote="DarkStarSword"]HLSL files are named:
xxxxxxxxxxxxxxxx-ys_replace.txt
Assembly files are named:
xxxxxxxxxxxxxxxx-ys.txt[/quote]
Thanks, DarkStarSword. It works now.
[quote="DarkStarSword"]In general always use the latest version of 3DMigoto unless you have a good reason to do otherwise (and if you do find you need to use an old version, let us know because that means there has been a regression). There's documentation in the template d3dx.ini about the allow_ options - try the other combinations that it recommends to see if any of them make a difference. If nothing works, enable calls=1, debug=1 and unbuffered=1 under [Logging] and send us the resulting d3d11_log.txt file.[/quote]
Ok, here
http://textuploader.com/d5fl2
DarkStarSword said:In general always use the latest version of 3DMigoto unless you have a good reason to do otherwise (and if you do find you need to use an old version, let us know because that means there has been a regression). There's documentation in the template d3dx.ini about the allow_ options - try the other combinations that it recommends to see if any of them make a difference. If nothing works, enable calls=1, debug=1 and unbuffered=1 under [Logging] and send us the resulting d3d11_log.txt file.
I observed some strange behaviour in the 3Dmigoto assembler:
In my fix, I have to copy a constant buffer (for FOV) from the parent VS to the asm pixel shader. The target register is cb13 and frame analysis shows that the copying works. If I try to access the new cb from asm, the line seems to be silently ignored. There are no errors in the log.
In the fix, the x-correction has to be multiplied by 10*FOV. According to frame analysis, cb13[1].x contains about 0.15.
This is the code I used:
[code]
...
dcl_constantbuffer cb13[214], immediateIndexed
dcl_resource_texture2d (float,float,float,float) t125
ld_indexable(texture2d)(float,float,float,float) r9.xyzw, l(0, 0, 0, 0), t125.xyzw
mul r10.x, cb13[1].x, l(10)
...
// Later, the fix is multiplied with r10.x
[/code]
If a set r10.x to 1.5 with
[code]mov r10.x, l(1.5)[/code]everything works (for a single FOV).
During further experiments, I found some more lines that don't work as well, eg:
[code]
mov r10.x, l(0.15)
mov r10.y, l(10)
mul r10.x, r10.x, r10.y // r10.x should contain 1.5 but fix shows no effect
// or
mov r10.xyzw, l(0.15, 10, 0, 0)
mul r10.x, r10.x, r10.y // r10.x should contain 1.5 but fix shows no effect
[/code]
I read about various assembler bugs [url=https://github.com/bo3b/3Dmigoto/issues/36]here[/url], so I unindented all lines but without success. Have I found a new bug or did I missed some other asm gotcha ?
I observed some strange behaviour in the 3Dmigoto assembler:
In my fix, I have to copy a constant buffer (for FOV) from the parent VS to the asm pixel shader. The target register is cb13 and frame analysis shows that the copying works. If I try to access the new cb from asm, the line seems to be silently ignored. There are no errors in the log.
In the fix, the x-correction has to be multiplied by 10*FOV. According to frame analysis, cb13[1].x contains about 0.15.
mul r10.x, cb13[1].x, l(10)
...
// Later, the fix is multiplied with r10.x
If a set r10.x to 1.5 with
mov r10.x, l(1.5)
everything works (for a single FOV).
During further experiments, I found some more lines that don't work as well, eg:
mov r10.x, l(0.15)
mov r10.y, l(10)
mul r10.x, r10.x, r10.y // r10.x should contain 1.5 but fix shows no effect
// or
mov r10.xyzw, l(0.15, 10, 0, 0)
mul r10.x, r10.x, r10.y // r10.x should contain 1.5 but fix shows no effect
I read about various assembler bugs here, so I unindented all lines but without success. Have I found a new bug or did I missed some other asm gotcha ?
[quote="Wolfmeister101"][quote="DarkStarSword"]In general always use the latest version of 3DMigoto unless you have a good reason to do otherwise (and if you do find you need to use an old version, let us know because that means there has been a regression). There's documentation in the template d3dx.ini about the allow_ options - try the other combinations that it recommends to see if any of them make a difference. If nothing works, enable calls=1, debug=1 and unbuffered=1 under [Logging] and send us the resulting d3d11_log.txt file.[/quote]
Ok, here
http://textuploader.com/d5fl2[/quote]
Thanks, I see the problem - this will need an update to 3DMigoto to allow another code path, and I have a feeling this may open up a bunch of previously untested code paths that have likely bit-rotted away. @Bo3b - I'm heading off to bed shortly, so if you were keen on looking at this don't wait for me. It might be worth grabbing this game for the shared accounts as one Bo3b and I can use for testing the platform update code paths.
DarkStarSword said:In general always use the latest version of 3DMigoto unless you have a good reason to do otherwise (and if you do find you need to use an old version, let us know because that means there has been a regression). There's documentation in the template d3dx.ini about the allow_ options - try the other combinations that it recommends to see if any of them make a difference. If nothing works, enable calls=1, debug=1 and unbuffered=1 under [Logging] and send us the resulting d3d11_log.txt file.
Thanks, I see the problem - this will need an update to 3DMigoto to allow another code path, and I have a feeling this may open up a bunch of previously untested code paths that have likely bit-rotted away. @Bo3b - I'm heading off to bed shortly, so if you were keen on looking at this don't wait for me. It might be worth grabbing this game for the shared accounts as one Bo3b and I can use for testing the platform update code paths.
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="mx-2"]I observed some strange behaviour in the 3Dmigoto assembler:[/quote]Yep, the assembler is pretty special that way ;-)
[quote]In my fix, I have to copy a constant buffer (for FOV) from the parent VS to the asm pixel shader. The target register is cb13 and frame analysis shows that the copying works.[/quote]While not relevant to your problem at hand, be aware that cb12 in the vertex shader is used by the 3D Vision driver (it is how it passes separation and convergence to any shader it has modified), and if you try to use it it will appear to work and even show up in the frame analysis dumps, but the GPU will get a completely different constant buffer. Hence, I always use cb13, cb11, cb10, etc. skipping cb12. This is also the cause of one of the problems in Ark: Survival Evolved as the sky effects use cb12 (easy to fix with 3DMigoto by reassigning it to another constant buffer).
[quote]If I try to access the new cb from asm, the line seems to be silently ignored. There are no errors in the log.[/quote]Yeah, the assembler either works, silently drops an instruction (try a typo in an opcode), crashes the game (try using too few parameters in an instruction), or enters an infinite loop (try using a bracket in an indented comment) hanging the game (of course the shader itself may contain an infinite loop crashing the GPU/game, but that one is not an assembler issue). It doesn't have any logging or produce any errors - we ultimately would like to replace it with one designed to handle human input more robustly, but the current one works so long as you are careful, so... not a high priority.
[quote]In the fix, the x-correction has to be multiplied by 10*FOV. According to frame analysis, cb13[1].x contains about 0.15.
This is the code I used:[/quote]
[code]
mul r10.x, cb13[1].x, l(10)
[/code]
[/quote]There's your problem - in DX11 assembly l(10) and l(10.0) are very different things and it is important not to mix them up - l(10) would produce an integer representation of 10 that when interpreted as a float would be 1.4e-44, which is definitely not what you want. Sometimes we use l(0) where we technically should have used l(0.0), but that is a special case as both will produce 0x00000000.
I ran that through cmd_Decompiler (cmd_Decompiler -a foo.txt; cmd_Decompiler -d foo.shdr; diff -u foo.txt foo.asm) and you can see what happened:
[code]
mul r10.x, cb13[1].x, l(1.401298464E-044)
[/code]
mx-2 said:I observed some strange behaviour in the 3Dmigoto assembler:
Yep, the assembler is pretty special that way ;-)
In my fix, I have to copy a constant buffer (for FOV) from the parent VS to the asm pixel shader. The target register is cb13 and frame analysis shows that the copying works.
While not relevant to your problem at hand, be aware that cb12 in the vertex shader is used by the 3D Vision driver (it is how it passes separation and convergence to any shader it has modified), and if you try to use it it will appear to work and even show up in the frame analysis dumps, but the GPU will get a completely different constant buffer. Hence, I always use cb13, cb11, cb10, etc. skipping cb12. This is also the cause of one of the problems in Ark: Survival Evolved as the sky effects use cb12 (easy to fix with 3DMigoto by reassigning it to another constant buffer).
If I try to access the new cb from asm, the line seems to be silently ignored. There are no errors in the log.
Yeah, the assembler either works, silently drops an instruction (try a typo in an opcode), crashes the game (try using too few parameters in an instruction), or enters an infinite loop (try using a bracket in an indented comment) hanging the game (of course the shader itself may contain an infinite loop crashing the GPU/game, but that one is not an assembler issue). It doesn't have any logging or produce any errors - we ultimately would like to replace it with one designed to handle human input more robustly, but the current one works so long as you are careful, so... not a high priority.
In the fix, the x-correction has to be multiplied by 10*FOV. According to frame analysis, cb13[1].x contains about 0.15.
This is the code I used:
mul r10.x, cb13[1].x, l(10)
There's your problem - in DX11 assembly l(10) and l(10.0) are very different things and it is important not to mix them up - l(10) would produce an integer representation of 10 that when interpreted as a float would be 1.4e-44, which is definitely not what you want. Sometimes we use l(0) where we technically should have used l(0.0), but that is a special case as both will produce 0x00000000.
I ran that through cmd_Decompiler (cmd_Decompiler -a foo.txt; cmd_Decompiler -d foo.shdr; diff -u foo.txt foo.asm) and you can see what happened:
mul r10.x, cb13[1].x, l(1.401298464E-044)
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
[quote="DarkStarSword"][quote="Wolfmeister101"]Ok, here
http://textuploader.com/d5fl2[/quote]
Thanks, I see the problem - this will need an update to 3DMigoto to allow another code path, and I have a feeling this may open up a bunch of previously untested code paths that have likely bit-rotted away. @Bo3b - I'm heading off to bed shortly, so if you were keen on looking at this don't wait for me. It might be worth grabbing this game for the shared accounts as one Bo3b and I can use for testing the platform update code paths.
[/quote]
Can you try with 3DMigoto 1.2.46 with the new allow_platform_update=1 option?
I have done literally no testing on this - it is just a quick change that you can try before I hit the sack, so it wouldn't surprise me at all if it doesn't work or something else breaks - please test and report back.
Thanks, I see the problem - this will need an update to 3DMigoto to allow another code path, and I have a feeling this may open up a bunch of previously untested code paths that have likely bit-rotted away. @Bo3b - I'm heading off to bed shortly, so if you were keen on looking at this don't wait for me. It might be worth grabbing this game for the shared accounts as one Bo3b and I can use for testing the platform update code paths.
Can you try with 3DMigoto 1.2.46 with the new allow_platform_update=1 option?
I have done literally no testing on this - it is just a quick change that you can try before I hit the sack, so it wouldn't surprise me at all if it doesn't work or something else breaks - please test and report back.
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 here's the shader in question, would really appreciate if someone could help me fix it (if that's even possible?)
1080 Ti - i7 5820k - 16Gb RAM - Win 10 version 1607 - ASUS VG236H (1920x1080@120Hz)
The problem is in lines 180 and 181. It's trying to use v3.wz, but v3 is defined as float2 (it can only have x and y). Change those lines to
Try that.
CPU: Intel Core i7 7700K @ 4.9GHz
Motherboard: Gigabyte Aorus GA-Z270X-Gaming 5
RAM: GSKILL Ripjaws Z 16GB 3866MHz CL18
GPU: MSI GeForce RTX 2080Ti Gaming X Trio
Monitor: Asus PG278QR
Speakers: Logitech Z506
Donations account: masterotakusuko@gmail.com
That worked, thanks a lot!
1080 Ti - i7 5820k - 16Gb RAM - Win 10 version 1607 - ASUS VG236H (1920x1080@120Hz)
I'm starting to use 3Dmigoto and run into some shaders that are available as assembly only.
Looking into existing fixes I found some "reasm" files and copied the declarations
into the asm shader. The "dcl_temps" directive was increased from 9 to 10.
The rest of the shader is fixed similar as in Helixmod.
If I now start the game, the fixed shader is not loaded and the log files shows the following error:
If I remove the errornous line, I the the following:
From that I guess that 3Dmigoto tries to compile a HLSL shader instead of asm.
What is the correct way to use asm shaders with 3Dmigoto?
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix
xxxxxxxxxxxxxxxx-ys_replace.txt
Assembly files are named:
xxxxxxxxxxxxxxxx-ys.txt
The reasm files were from the early days of the assembler to allow us to check that it actually assembled what we wrote, but that code was removed from 3DMigoto after we got cmd_Decompiler*, so maybe that is why it thinks they are HLSL (they weren't really supposed to be shipped, but a bunch of fixes included them anyway).
* The assembler has a number of gotchas if your code looks like it was written by a human instead of a machine - if something isn't behaving as you expect, use cmd_Decompiler to assemble and disassemble it then compare that to what you wrote looking for missing instructions. cmd_Decompiler is on the 3DMigoto releases page.
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
But when I try to start the game, this shows up:
D3D11CreateDeviceAndSwapChain FAILED with error (-214702809). Please check your GPU is compatible with DirectX 11.1. Also, if you're under Windows 7, please check you've installed the Windows Platform Update
I use a single GTX 1080
Anyone have any tips?
Also tried reverting to an older version, version 1.1.14, and a new error message appeared that said
"failed to request directX 11.1 device"
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
How? And what version of 3dmigoto should I use when doing this?
Do I add the line "allow_create_device=2" somewhere in the d3dx ini?
EDIT: I think I figured it out. Added it right at the top under the systems setting, and it showed up in the d3d11 log.
But it didn't fix anything
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
Thanks, DarkStarSword. It works now.
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix
Ok, here
http://textuploader.com/d5fl2
In my fix, I have to copy a constant buffer (for FOV) from the parent VS to the asm pixel shader. The target register is cb13 and frame analysis shows that the copying works. If I try to access the new cb from asm, the line seems to be silently ignored. There are no errors in the log.
In the fix, the x-correction has to be multiplied by 10*FOV. According to frame analysis, cb13[1].x contains about 0.15.
This is the code I used:
If a set r10.x to 1.5 with
everything works (for a single FOV).
During further experiments, I found some more lines that don't work as well, eg:
I read about various assembler bugs here, so I unindented all lines but without success. Have I found a new bug or did I missed some other asm gotcha ?
My 3D fixes with Helixmod for the Risen series on GitHub
Bo3b's School for Shaderhackers - starting point for your first 3D fix
Thanks, I see the problem - this will need an update to 3DMigoto to allow another code path, and I have a feeling this may open up a bunch of previously untested code paths that have likely bit-rotted away. @Bo3b - I'm heading off to bed shortly, so if you were keen on looking at this don't wait for me. It might be worth grabbing this game for the shared accounts as one Bo3b and I can use for testing the platform update code paths.
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
While not relevant to your problem at hand, be aware that cb12 in the vertex shader is used by the 3D Vision driver (it is how it passes separation and convergence to any shader it has modified), and if you try to use it it will appear to work and even show up in the frame analysis dumps, but the GPU will get a completely different constant buffer. Hence, I always use cb13, cb11, cb10, etc. skipping cb12. This is also the cause of one of the problems in Ark: Survival Evolved as the sky effects use cb12 (easy to fix with 3DMigoto by reassigning it to another constant buffer).
Yeah, the assembler either works, silently drops an instruction (try a typo in an opcode), crashes the game (try using too few parameters in an instruction), or enters an infinite loop (try using a bracket in an indented comment) hanging the game (of course the shader itself may contain an infinite loop crashing the GPU/game, but that one is not an assembler issue). It doesn't have any logging or produce any errors - we ultimately would like to replace it with one designed to handle human input more robustly, but the current one works so long as you are careful, so... not a high priority.
There's your problem - in DX11 assembly l(10) and l(10.0) are very different things and it is important not to mix them up - l(10) would produce an integer representation of 10 that when interpreted as a float would be 1.4e-44, which is definitely not what you want. Sometimes we use l(0) where we technically should have used l(0.0), but that is a special case as both will produce 0x00000000.
I ran that through cmd_Decompiler (cmd_Decompiler -a foo.txt; cmd_Decompiler -d foo.shdr; diff -u foo.txt foo.asm) and you can see what happened:
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
Can you try with 3DMigoto 1.2.46 with the new allow_platform_update=1 option?
I have done literally no testing on this - it is just a quick change that you can try before I hit the sack, so it wouldn't surprise me at all if it doesn't work or something else breaks - please test and report back.
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