3Dmigoto now open-source...
  18 / 141    
@bo3b/DarkStarSword Big sorry....is working fine!!....i made a mistake in xpadder when i binding the keys to my xbox controller. Test in my keyboard and is working perfect.....great feature!!!!!
@bo3b/DarkStarSword

Big sorry....is working fine!!....i made a mistake in xpadder when i binding the keys to my xbox controller. Test in my keyboard and is working perfect.....great feature!!!!!

MY WEB

Helix Mod - Making 3D Better

My 3D Screenshot Gallery

Like my fixes? you can donate to Paypal: dhr.donation@gmail.com

Posted 02/05/2015 01:50 PM   
I was just taking a look at the license for Helifax' OpenGL wrapper (to get permission from my employer to work on it in my own time), and it occurred to me that we probably need to include the 3Dmigoto copyright notice in all fixes that include a copy of it's DLL, due to this clause which is part of the MIT license: [quote]The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.[/quote] The easiest way is probably to have the build system copy it in with a suitable filename (e.g. 3Dmigoto-license.txt). At the moment the copyright notice still only lists Chiri - it doesn't have to be an exhaustive list (smaller contributions are typically acknowledged in changelogs, release notes and/or the commit history), but given how much work bo3b has done on this project I think at least his name should be there as well. [S]I've also raised a concern about a potential viral licensing contamination and GPL license compatibility issue if code from Helifax' wrapper is included in 3Dmigoto, due to the addition of an extra attribution clause that is not in the standard MIT license: [url]https://forums.geforce.com/default/topic/809612/3d-vision/-ogl-3d-vision-wrapper-is-now-open-source-/post/4454715/#4454715[/url][/S] Edit: All resolved now
I was just taking a look at the license for Helifax' OpenGL wrapper (to get permission from my employer to work on it in my own time), and it occurred to me that we probably need to include the 3Dmigoto copyright notice in all fixes that include a copy of it's DLL, due to this clause which is part of the MIT license:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

The easiest way is probably to have the build system copy it in with a suitable filename (e.g. 3Dmigoto-license.txt).

At the moment the copyright notice still only lists Chiri - it doesn't have to be an exhaustive list (smaller contributions are typically acknowledged in changelogs, release notes and/or the commit history), but given how much work bo3b has done on this project I think at least his name should be there as well.



I've also raised a concern about a potential viral licensing contamination and GPL license compatibility issue if code from Helifax' wrapper is included in 3Dmigoto, due to the addition of an extra attribution clause that is not in the standard MIT license:

https://forums.geforce.com/default/topic/809612/3d-vision/-ogl-3d-vision-wrapper-is-now-open-source-/post/4454715/#4454715
Edit: All resolved now

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

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

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

Posted 02/09/2015 06:20 AM   
3Dmigoto hit some parse errors in Lichdom Battlemage, which prevents certain shaders from being dumped as HLSL (including the hand vertex shader - for now I've fixed the halo on that in the pixel shader instead): [code] $ grep error d3d11_log.txt |sort -u error parsing shader> 3 Error parsing buffer offset: cb0[1].w error parsing shader> 3 Error parsing buffer offset: cb0[1].xyzw error parsing shader> 3 Error parsing buffer offset: cb0[5].xyw error parsing shader> Error parsing output signature: // SV_Depth 0 N/A oDepth DEPTH float YES error parsing shader> Missing constant buffer name: cb7[r0.w+1].xyzw error parsing shader> Missing constant buffer name: cb7[r0.x+1].xyzw error parsing shader> Missing constant buffer name: cb7[r0.y+1].xyzw error parsing shader> Missing constant buffer name: cb7[r0.z+1].xyzw error parsing shader> Unknown data type: float2x4 [/code] Here's some shaders dumped with export_shaders=1 that had these errors: ea2e0756662dfa88-vs.txt (hand vertex shader) - unknown data type float2x4 and Missing constant buffer name errors: [code] // // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 // // // Buffer Definitions: // // cbuffer PER_INSTANCE // { // // float4 Ambient; // Offset: 0 Size: 16 [unused] // row_major float4x4 _TCMMatrixCustom;// Offset: 16 Size: 64 // row_major float4x4 _TCMMatrixBump; // Offset: 80 Size: 64 [unused] // row_major float4x4 _TCGMatrixEnv; // Offset: 144 Size: 64 [unused] // row_major float4x4 _TCMMatrixEnv; // Offset: 208 Size: 64 [unused] // row_major float4x4 _TCGMatrixCustom;// Offset: 272 Size: 64 [unused] // row_major float4x4 _TCGMatrixBump; // Offset: 336 Size: 64 [unused] // row_major float4x4 _TCMMatrixDif; // Offset: 400 Size: 64 // row_major float4x4 _TCMMatrixGloss;// Offset: 464 Size: 64 [unused] // row_major float4x4 _TCGMatrixGloss;// Offset: 528 Size: 64 [unused] // row_major float4x4 _TCGMatrixDif; // Offset: 592 Size: 64 [unused] // // } // // cbuffer STATIC_INSTANCE // { // // row_major float3x4 ObjWorldMatrix; // Offset: 0 Size: 48 // float4 BendInfo; // Offset: 48 Size: 16 [unused] // float4 AmbientOp; // Offset: 80 Size: 16 // // } // // cbuffer PER_FRAME // { // // row_major float4x4 g_VS_ViewProjMatr;// Offset: 0 Size: 64 [unused] // float4 g_VS_WorldViewPos; // Offset: 96 Size: 16 // float4 g_VS_AnimGenParams; // Offset: 128 Size: 16 [unused] // row_major float4x4 g_VS_ViewProjZeroMatr;// Offset: 160 Size: 64 // // } // // cbuffer SKIN_DATA // { // // row_major float2x4 _g_SkinQuat[200];// Offset: 0 Size: 6400 // // } // // cbuffer SHAPE_DATA // { // // float4 _g_ShapeDeformationData[8]; // Offset: 0 Size: 128 // // } // // // Resource Bindings: // // Name Type Format Dim Slot Elements // ------------------------------ ---------- ------- ----------- ---- -------- // PER_INSTANCE cbuffer NA NA 1 1 // STATIC_INSTANCE cbuffer NA NA 2 1 // PER_FRAME cbuffer NA NA 3 1 // SKIN_DATA cbuffer NA NA 7 1 // SHAPE_DATA cbuffer NA NA 8 1 // // // // Input signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // POSITION 0 xyzw 0 NONE float xyz // TEXCOORD 0 xyzw 1 NONE float xyzw // COLOR 0 xyzw 2 NONE float // TANGENT 0 xyzw 3 NONE float // BLENDWEIGHT 0 xyzw 4 NONE float xyzw // BLENDINDICES 0 xyzw 5 NONE float xyzw // COLOR 1 xyzw 6 NONE float w // TEXCOORD 4 xyz 7 NONE float xyz // TEXCOORD 5 xyz 8 NONE float xyz // // // Output signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // SV_Position 0 xyzw 0 POS float xyzw // TEXCOORD 0 xyzw 1 NONE float xyzw // TEXCOORD 1 xyzw 2 NONE float xyzw // TEXCOORD 2 xyzw 3 NONE float xyzw // TEXCOORD 3 xyzw 4 NONE float xyzw // TEXCOORD 4 xyzw 5 NONE float xyzw // vs_5_0 dcl_globalFlags refactoringAllowed dcl_constantbuffer cb1[29], immediateIndexed dcl_constantbuffer cb2[6], immediateIndexed dcl_constantbuffer cb3[14], immediateIndexed dcl_constantbuffer cb7[400], dynamicIndexed dcl_constantbuffer cb8[8], dynamicIndexed dcl_input v0.xyz dcl_input v1.xyzw dcl_input v4.xyzw dcl_input v5.xyzw dcl_input v6.w dcl_input v7.xyz dcl_input v8.xyz dcl_output_siv o0.xyzw, position dcl_output o1.xyzw dcl_output o2.xyzw dcl_output o3.xyzw dcl_output o4.xyzw dcl_output o5.xyzw dcl_temps 5 mul r0.xyzw, v5.xyzw, l(255.001953, 255.001953, 255.001953, 255.001953) ftoi r0.xyzw, r0.xyzw ishl r0.xyzw, r0.xyzw, l(1, 1, 1, 1) mul r1.xyzw, v4.yyyy, cb7[r0.y + 1].xyzw mad r1.xyzw, cb7[r0.x + 1].xyzw, v4.xxxx, r1.xyzw mad r1.xyzw, cb7[r0.z + 1].xyzw, v4.zzzz, r1.xyzw mad r1.xyzw, cb7[r0.w + 1].xyzw, v4.wwww, r1.xyzw mul r2.xyzw, v4.yyyy, cb7[r0.y + 0].xyzw mad r2.xyzw, cb7[r0.x + 0].xyzw, v4.xxxx, r2.xyzw mad r2.xyzw, cb7[r0.z + 0].xyzw, v4.zzzz, r2.xyzw mad r0.xyzw, cb7[r0.w + 0].xyzw, v4.wwww, r2.xyzw dp4 r2.x, r0.xyzw, r0.xyzw rsq r2.x, r2.x mul r1.xyzw, r1.xyzw, r2.xxxx mul r0.xyzw, r0.xyzw, r2.xxxx mul r2.xyz, r0.xyzx, r1.wwww mad r2.xyz, r0.wwww, r1.xyzx, -r2.xyzx mul r3.xyz, r1.yzxy, r0.zxyz mad r1.xyz, r0.yzxy, r1.zxyz, -r3.xyzx add r1.xyz, r1.xyzx, r2.xyzx mul r1.w, v6.w, l(255.001953) ftoi r1.w, r1.w imin r1.w, r1.w, l(8) mul r2.xyz, v0.xyzx, cb8[r1.w + 0].yyyy mad r2.xyz, v7.xyzx, cb8[r1.w + 0].xxxx, r2.xyzx mad r2.xyz, v8.xyzx, cb8[r1.w + 0].zzzz, r2.xyzx mul r3.xyz, r0.xyzx, r2.zxyz mad r3.xyz, r0.zxyz, r2.xyzx, -r3.xyzx mad r3.xyz, r0.wwww, r2.yzxy, r3.xyzx mul r4.xyz, r0.zxyz, r3.xyzx mad r0.xyz, r0.yzxy, r3.yzxy, -r4.xyzx mad r0.xyz, r0.xyzx, l(2.000000, 2.000000, 2.000000, 0.000000), r2.xyzx mad r0.xyz, r1.xyzx, l(2.000000, 2.000000, 2.000000, 0.000000), r0.xyzx add r1.w, cb2[0].w, -cb3[6].x mov r1.xyz, cb2[0].xyzx mov r0.w, l(1.000000) dp4 r1.x, r1.xyzw, r0.xyzw add r2.w, cb2[1].w, -cb3[6].y mov r2.xyz, cb2[1].xyzx dp4 r1.y, r2.xyzw, r0.xyzw add r2.w, cb2[2].w, -cb3[6].z mov r2.xyz, cb2[2].xyzx dp4 r1.z, r2.xyzw, r0.xyzw mov r1.w, l(1.000000) dp4 r0.x, cb3[10].xyzw, r1.xyzw dp4 r0.y, cb3[11].xyzw, r1.xyzw dp4 r0.z, cb3[12].xyzw, r1.xyzw dp4 r0.w, cb3[13].xyzw, r1.xyzw mov o2.xyzw, r1.xyzw mov o0.xyzw, r0.xyzw mad r0.xy, r0.xyxx, l(1.000000, -1.000000, 0.000000, 0.000000), r0.wwww mov o3.zw, r0.zzzw mul o3.xy, r0.xyxx, l(0.500000, 0.500000, 0.000000, 0.000000) mul r0.xyzw, v1.yyyy, cb1[26].xyzw mad r0.xyzw, v1.xxxx, cb1[25].xyzw, r0.xyzw mad r0.xyzw, v1.zzzz, cb1[27].xyzw, r0.xyzw mad o1.xyzw, v1.wwww, cb1[28].xyzw, r0.xyzw mul r0.xyz, v0.yyyy, cb1[2].xyzx mad r0.xyz, v0.xxxx, cb1[1].xyzx, r0.xyzx mad r0.xyz, v0.zzzz, cb1[3].xyzx, r0.xyzx add o4.xyz, r0.xyzx, cb1[4].xyzx mov o4.w, l(0) mov o5.xyzw, cb2[5].xyzw ret // Approximately 64 instruction slots used [/code] c047e5f8beee1c69-ps.txt - unknown data type float2x4 and "3 Error parsing buffer offset: cb0[1].xyzw": [code] // // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 // // // Buffer Definitions: // // cbuffer PER_BATCH // { // // row_major float2x4 cBitmapColorTransform;// Offset: 0 Size: 32 // float cPremultiplyAlpha; // Offset: 32 Size: 4 // // } // // // Resource Bindings: // // Name Type Format Dim Slot Elements // ------------------------------ ---------- ------- ----------- ---- -------- // PER_BATCH cbuffer NA NA 0 1 // // // // Input signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // SV_Position 0 xyzw 0 POS float // COLOR 0 xyzw 1 NONE float xyzw // // // Output signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // SV_Target 0 xyzw 0 TARGET float xyzw // ps_5_0 dcl_globalFlags refactoringAllowed dcl_constantbuffer cb0[3], immediateIndexed dcl_input_ps linear v1.xyzw dcl_output o0.xyzw dcl_temps 3 ne r0.x, l(0.000000, 0.000000, 0.000000, 0.000000), cb0[2].x mad r1.xyzw, v1.xyzw, cb0[0].xyzw, cb0[1].xyzw mul r2.xyzw, r1.wwww, r1.xyzw movc o0.xyzw, r0.xxxx, r2.xyzw, r1.xyzw ret // Approximately 5 instruction slots used [/code] 12900aba8c94cd8b-ps.txt - error parsing output signature: [code] // // Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111 // // // // Input signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // SV_Position 0 xyzw 0 POS float // TEXCOORD 0 x 1 NONE float x // // // Output signature: // // Name Index Mask Register SysValue Format Used // -------------------- ----- ------ -------- -------- ------- ------ // SV_Target 0 xyzw 0 TARGET float xyzw // SV_Depth 0 N/A oDepth DEPTH float YES // ps_5_0 dcl_globalFlags refactoringAllowed dcl_input_ps linear v1.x dcl_output o0.xyzw dcl_output oDepth mov o0.xyzw, l(0,0,0,0) mov oDepth, v1.x ret // Approximately 3 instruction slots used [/code]
3Dmigoto hit some parse errors in Lichdom Battlemage, which prevents certain shaders from being dumped as HLSL (including the hand vertex shader - for now I've fixed the halo on that in the pixel shader instead):
$ grep error d3d11_log.txt |sort -u
error parsing shader> 3 Error parsing buffer offset: cb0[1].w
error parsing shader> 3 Error parsing buffer offset: cb0[1].xyzw
error parsing shader> 3 Error parsing buffer offset: cb0[5].xyw
error parsing shader> Error parsing output signature: // SV_Depth 0 N/A oDepth DEPTH float YES
error parsing shader> Missing constant buffer name: cb7[r0.w+1].xyzw
error parsing shader> Missing constant buffer name: cb7[r0.x+1].xyzw
error parsing shader> Missing constant buffer name: cb7[r0.y+1].xyzw
error parsing shader> Missing constant buffer name: cb7[r0.z+1].xyzw
error parsing shader> Unknown data type: float2x4


Here's some shaders dumped with export_shaders=1 that had these errors:

ea2e0756662dfa88-vs.txt (hand vertex shader) - unknown data type float2x4 and Missing constant buffer name errors:
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
//
// Buffer Definitions:
//
// cbuffer PER_INSTANCE
// {
//
// float4 Ambient; // Offset: 0 Size: 16 [unused]
// row_major float4x4 _TCMMatrixCustom;// Offset: 16 Size: 64
// row_major float4x4 _TCMMatrixBump; // Offset: 80 Size: 64 [unused]
// row_major float4x4 _TCGMatrixEnv; // Offset: 144 Size: 64 [unused]
// row_major float4x4 _TCMMatrixEnv; // Offset: 208 Size: 64 [unused]
// row_major float4x4 _TCGMatrixCustom;// Offset: 272 Size: 64 [unused]
// row_major float4x4 _TCGMatrixBump; // Offset: 336 Size: 64 [unused]
// row_major float4x4 _TCMMatrixDif; // Offset: 400 Size: 64
// row_major float4x4 _TCMMatrixGloss;// Offset: 464 Size: 64 [unused]
// row_major float4x4 _TCGMatrixGloss;// Offset: 528 Size: 64 [unused]
// row_major float4x4 _TCGMatrixDif; // Offset: 592 Size: 64 [unused]
//
// }
//
// cbuffer STATIC_INSTANCE
// {
//
// row_major float3x4 ObjWorldMatrix; // Offset: 0 Size: 48
// float4 BendInfo; // Offset: 48 Size: 16 [unused]
// float4 AmbientOp; // Offset: 80 Size: 16
//
// }
//
// cbuffer PER_FRAME
// {
//
// row_major float4x4 g_VS_ViewProjMatr;// Offset: 0 Size: 64 [unused]
// float4 g_VS_WorldViewPos; // Offset: 96 Size: 16
// float4 g_VS_AnimGenParams; // Offset: 128 Size: 16 [unused]
// row_major float4x4 g_VS_ViewProjZeroMatr;// Offset: 160 Size: 64
//
// }
//
// cbuffer SKIN_DATA
// {
//
// row_major float2x4 _g_SkinQuat[200];// Offset: 0 Size: 6400
//
// }
//
// cbuffer SHAPE_DATA
// {
//
// float4 _g_ShapeDeformationData[8]; // Offset: 0 Size: 128
//
// }
//
//
// Resource Bindings:
//
// Name Type Format Dim Slot Elements
// ------------------------------ ---------- ------- ----------- ---- --------
// PER_INSTANCE cbuffer NA NA 1 1
// STATIC_INSTANCE cbuffer NA NA 2 1
// PER_FRAME cbuffer NA NA 3 1
// SKIN_DATA cbuffer NA NA 7 1
// SHAPE_DATA cbuffer NA NA 8 1
//
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// POSITION 0 xyzw 0 NONE float xyz
// TEXCOORD 0 xyzw 1 NONE float xyzw
// COLOR 0 xyzw 2 NONE float
// TANGENT 0 xyzw 3 NONE float
// BLENDWEIGHT 0 xyzw 4 NONE float xyzw
// BLENDINDICES 0 xyzw 5 NONE float xyzw
// COLOR 1 xyzw 6 NONE float w
// TEXCOORD 4 xyz 7 NONE float xyz
// TEXCOORD 5 xyz 8 NONE float xyz
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Position 0 xyzw 0 POS float xyzw
// TEXCOORD 0 xyzw 1 NONE float xyzw
// TEXCOORD 1 xyzw 2 NONE float xyzw
// TEXCOORD 2 xyzw 3 NONE float xyzw
// TEXCOORD 3 xyzw 4 NONE float xyzw
// TEXCOORD 4 xyzw 5 NONE float xyzw
//
vs_5_0
dcl_globalFlags refactoringAllowed
dcl_constantbuffer cb1[29], immediateIndexed
dcl_constantbuffer cb2[6], immediateIndexed
dcl_constantbuffer cb3[14], immediateIndexed
dcl_constantbuffer cb7[400], dynamicIndexed
dcl_constantbuffer cb8[8], dynamicIndexed
dcl_input v0.xyz
dcl_input v1.xyzw
dcl_input v4.xyzw
dcl_input v5.xyzw
dcl_input v6.w
dcl_input v7.xyz
dcl_input v8.xyz
dcl_output_siv o0.xyzw, position
dcl_output o1.xyzw
dcl_output o2.xyzw
dcl_output o3.xyzw
dcl_output o4.xyzw
dcl_output o5.xyzw
dcl_temps 5
mul r0.xyzw, v5.xyzw, l(255.001953, 255.001953, 255.001953, 255.001953)
ftoi r0.xyzw, r0.xyzw
ishl r0.xyzw, r0.xyzw, l(1, 1, 1, 1)
mul r1.xyzw, v4.yyyy, cb7[r0.y + 1].xyzw
mad r1.xyzw, cb7[r0.x + 1].xyzw, v4.xxxx, r1.xyzw
mad r1.xyzw, cb7[r0.z + 1].xyzw, v4.zzzz, r1.xyzw
mad r1.xyzw, cb7[r0.w + 1].xyzw, v4.wwww, r1.xyzw
mul r2.xyzw, v4.yyyy, cb7[r0.y + 0].xyzw
mad r2.xyzw, cb7[r0.x + 0].xyzw, v4.xxxx, r2.xyzw
mad r2.xyzw, cb7[r0.z + 0].xyzw, v4.zzzz, r2.xyzw
mad r0.xyzw, cb7[r0.w + 0].xyzw, v4.wwww, r2.xyzw
dp4 r2.x, r0.xyzw, r0.xyzw
rsq r2.x, r2.x
mul r1.xyzw, r1.xyzw, r2.xxxx
mul r0.xyzw, r0.xyzw, r2.xxxx
mul r2.xyz, r0.xyzx, r1.wwww
mad r2.xyz, r0.wwww, r1.xyzx, -r2.xyzx
mul r3.xyz, r1.yzxy, r0.zxyz
mad r1.xyz, r0.yzxy, r1.zxyz, -r3.xyzx
add r1.xyz, r1.xyzx, r2.xyzx
mul r1.w, v6.w, l(255.001953)
ftoi r1.w, r1.w
imin r1.w, r1.w, l(8)
mul r2.xyz, v0.xyzx, cb8[r1.w + 0].yyyy
mad r2.xyz, v7.xyzx, cb8[r1.w + 0].xxxx, r2.xyzx
mad r2.xyz, v8.xyzx, cb8[r1.w + 0].zzzz, r2.xyzx
mul r3.xyz, r0.xyzx, r2.zxyz
mad r3.xyz, r0.zxyz, r2.xyzx, -r3.xyzx
mad r3.xyz, r0.wwww, r2.yzxy, r3.xyzx
mul r4.xyz, r0.zxyz, r3.xyzx
mad r0.xyz, r0.yzxy, r3.yzxy, -r4.xyzx
mad r0.xyz, r0.xyzx, l(2.000000, 2.000000, 2.000000, 0.000000), r2.xyzx
mad r0.xyz, r1.xyzx, l(2.000000, 2.000000, 2.000000, 0.000000), r0.xyzx
add r1.w, cb2[0].w, -cb3[6].x
mov r1.xyz, cb2[0].xyzx
mov r0.w, l(1.000000)
dp4 r1.x, r1.xyzw, r0.xyzw
add r2.w, cb2[1].w, -cb3[6].y
mov r2.xyz, cb2[1].xyzx
dp4 r1.y, r2.xyzw, r0.xyzw
add r2.w, cb2[2].w, -cb3[6].z
mov r2.xyz, cb2[2].xyzx
dp4 r1.z, r2.xyzw, r0.xyzw
mov r1.w, l(1.000000)
dp4 r0.x, cb3[10].xyzw, r1.xyzw
dp4 r0.y, cb3[11].xyzw, r1.xyzw
dp4 r0.z, cb3[12].xyzw, r1.xyzw
dp4 r0.w, cb3[13].xyzw, r1.xyzw
mov o2.xyzw, r1.xyzw
mov o0.xyzw, r0.xyzw
mad r0.xy, r0.xyxx, l(1.000000, -1.000000, 0.000000, 0.000000), r0.wwww
mov o3.zw, r0.zzzw
mul o3.xy, r0.xyxx, l(0.500000, 0.500000, 0.000000, 0.000000)
mul r0.xyzw, v1.yyyy, cb1[26].xyzw
mad r0.xyzw, v1.xxxx, cb1[25].xyzw, r0.xyzw
mad r0.xyzw, v1.zzzz, cb1[27].xyzw, r0.xyzw
mad o1.xyzw, v1.wwww, cb1[28].xyzw, r0.xyzw
mul r0.xyz, v0.yyyy, cb1[2].xyzx
mad r0.xyz, v0.xxxx, cb1[1].xyzx, r0.xyzx
mad r0.xyz, v0.zzzz, cb1[3].xyzx, r0.xyzx
add o4.xyz, r0.xyzx, cb1[4].xyzx
mov o4.w, l(0)
mov o5.xyzw, cb2[5].xyzw
ret
// Approximately 64 instruction slots used


c047e5f8beee1c69-ps.txt - unknown data type float2x4 and "3 Error parsing buffer offset: cb0[1].xyzw":
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
//
// Buffer Definitions:
//
// cbuffer PER_BATCH
// {
//
// row_major float2x4 cBitmapColorTransform;// Offset: 0 Size: 32
// float cPremultiplyAlpha; // Offset: 32 Size: 4
//
// }
//
//
// Resource Bindings:
//
// Name Type Format Dim Slot Elements
// ------------------------------ ---------- ------- ----------- ---- --------
// PER_BATCH cbuffer NA NA 0 1
//
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Position 0 xyzw 0 POS float
// COLOR 0 xyzw 1 NONE float xyzw
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Target 0 xyzw 0 TARGET float xyzw
//
ps_5_0
dcl_globalFlags refactoringAllowed
dcl_constantbuffer cb0[3], immediateIndexed
dcl_input_ps linear v1.xyzw
dcl_output o0.xyzw
dcl_temps 3
ne r0.x, l(0.000000, 0.000000, 0.000000, 0.000000), cb0[2].x
mad r1.xyzw, v1.xyzw, cb0[0].xyzw, cb0[1].xyzw
mul r2.xyzw, r1.wwww, r1.xyzw
movc o0.xyzw, r0.xxxx, r2.xyzw, r1.xyzw
ret
// Approximately 5 instruction slots used


12900aba8c94cd8b-ps.txt - error parsing output signature:
//
// Generated by Microsoft (R) HLSL Shader Compiler 9.29.952.3111
//
//
//
// Input signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Position 0 xyzw 0 POS float
// TEXCOORD 0 x 1 NONE float x
//
//
// Output signature:
//
// Name Index Mask Register SysValue Format Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_Target 0 xyzw 0 TARGET float xyzw
// SV_Depth 0 N/A oDepth DEPTH float YES
//
ps_5_0
dcl_globalFlags refactoringAllowed
dcl_input_ps linear v1.x
dcl_output o0.xyzw
dcl_output oDepth
mov o0.xyzw, l(0,0,0,0)
mov oDepth, v1.x
ret
// Approximately 3 instruction slots used

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

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

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

Posted 02/10/2015 12:52 AM   
[quote="DarkStarSword"]At the moment the copyright notice still only lists Chiri - it doesn't have to be an exhaustive list (smaller contributions are typically acknowledged in changelogs, release notes and/or the commit history), but given how much work bo3b has done on this project I think at least his name should be there as well.[/quote] This would be OK, but I really do not want to drop another file into the output build just for license stuff. It's just not that important. The only reason I went with an MIT license was because it was easy in Github, and the logical easiest one. Chiri actually didn't care if it had a license at all, and I was going to go with the WTFPL, but Github didn't support it. Don't get me wrong, the software is worth doing, or I wouldn't spend the time. But I have no illusion that it's used by more than a tiny handful of people, and hence the license is not worth much attention. I've left the copyright for Chiri, because of his extremely generous contribution of providing the source. The copyright is mostly incompatible with the idea of the MIT license anyway, Chiri really wanted it with no restrictions whatsoever, and I only added the copyright because the license required it. The only reason I added a license was because my reading indicated that having no license at all puts it into some sort of limbo, and I didn't want to discourage anyone from using it for whatever they wanted. Like all laws, we need to balance what it's worth, with what it costs. I just don't see that the license has any value here at all. Even if someone takes the code and makes a million bucks, that's OK with me, and OK with Chiri. But, as a major contributor, if you have a preference to how it should be set up I'm willing.
DarkStarSword said:At the moment the copyright notice still only lists Chiri - it doesn't have to be an exhaustive list (smaller contributions are typically acknowledged in changelogs, release notes and/or the commit history), but given how much work bo3b has done on this project I think at least his name should be there as well.

This would be OK, but I really do not want to drop another file into the output build just for license stuff. It's just not that important. The only reason I went with an MIT license was because it was easy in Github, and the logical easiest one. Chiri actually didn't care if it had a license at all, and I was going to go with the WTFPL, but Github didn't support it.

Don't get me wrong, the software is worth doing, or I wouldn't spend the time. But I have no illusion that it's used by more than a tiny handful of people, and hence the license is not worth much attention.

I've left the copyright for Chiri, because of his extremely generous contribution of providing the source. The copyright is mostly incompatible with the idea of the MIT license anyway, Chiri really wanted it with no restrictions whatsoever, and I only added the copyright because the license required it. The only reason I added a license was because my reading indicated that having no license at all puts it into some sort of limbo, and I didn't want to discourage anyone from using it for whatever they wanted.


Like all laws, we need to balance what it's worth, with what it costs. I just don't see that the license has any value here at all. Even if someone takes the code and makes a million bucks, that's OK with me, and OK with Chiri.

But, as a major contributor, if you have a preference to how it should be set up I'm willing.

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

Posted 02/10/2015 08:39 AM   
[quote="DarkStarSword"]3Dmigoto hit some parse errors in Lichdom Battlemage, which prevents certain shaders from being dumped as HLSL (including the hand vertex shader - for now I've fixed the halo on that in the pixel shader instead): [code] $ grep error d3d11_log.txt |sort -u error parsing shader> 3 Error parsing buffer offset: cb0[1].w error parsing shader> 3 Error parsing buffer offset: cb0[1].xyzw error parsing shader> 3 Error parsing buffer offset: cb0[5].xyw error parsing shader> Error parsing output signature: // SV_Depth 0 N/A oDepth DEPTH float YES error parsing shader> Missing constant buffer name: cb7[r0.w+1].xyzw error parsing shader> Missing constant buffer name: cb7[r0.x+1].xyzw error parsing shader> Missing constant buffer name: cb7[r0.y+1].xyzw error parsing shader> Missing constant buffer name: cb7[r0.z+1].xyzw error parsing shader> Unknown data type: float2x4 [/code][/quote] OK, good to know. These are shaders that you need for a fix I assume? I'll take a look and see if I can get it past the parse stage at least. Failing at parse is bad because we don't get anything we can even hand-fix. The float2x4 doesn't surprise me, that's a rare data type that is probably not supported just yet. The other errors are probably because of the +1 on the index. Sometimes the compiler generates code that indexes into another field, which is just weird. So for example two params with foo.xy and bar.xy, it will sometimes use foo[2] to get to the second x instead of bar.x. It makes the parsing really weird. The missing output of SV_Depth is one I've known about, and just dragged my feet on fixing. I'll take a look.
DarkStarSword said:3Dmigoto hit some parse errors in Lichdom Battlemage, which prevents certain shaders from being dumped as HLSL (including the hand vertex shader - for now I've fixed the halo on that in the pixel shader instead):
$ grep error d3d11_log.txt |sort -u
error parsing shader> 3 Error parsing buffer offset: cb0[1].w
error parsing shader> 3 Error parsing buffer offset: cb0[1].xyzw
error parsing shader> 3 Error parsing buffer offset: cb0[5].xyw
error parsing shader> Error parsing output signature: // SV_Depth 0 N/A oDepth DEPTH float YES
error parsing shader> Missing constant buffer name: cb7[r0.w+1].xyzw
error parsing shader> Missing constant buffer name: cb7[r0.x+1].xyzw
error parsing shader> Missing constant buffer name: cb7[r0.y+1].xyzw
error parsing shader> Missing constant buffer name: cb7[r0.z+1].xyzw
error parsing shader> Unknown data type: float2x4


OK, good to know. These are shaders that you need for a fix I assume?

I'll take a look and see if I can get it past the parse stage at least. Failing at parse is bad because we don't get anything we can even hand-fix.


The float2x4 doesn't surprise me, that's a rare data type that is probably not supported just yet.

The other errors are probably because of the +1 on the index. Sometimes the compiler generates code that indexes into another field, which is just weird. So for example two params with foo.xy and bar.xy, it will sometimes use foo[2] to get to the second x instead of bar.x. It makes the parsing really weird.

The missing output of SV_Depth is one I've known about, and just dragged my feet on fixing. I'll take a 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

Posted 02/10/2015 08:49 AM   
[quote="bo3b"]This would be OK, but I really do not want to drop another file into the output build just for license stuff. It's just not that important.[/quote]Fair enough. Personally I don't care too much if the license.txt is released as part of the build or not - it seems more important for it to stay with the source code than the compiled DLLs. I was only raising this concern as the license seems to require it, but if everyone working on the project is ok with it not being included in the releases that's fine with me. One thing we might want to fix is the copyright information in the .rc files that gets embedded inside the DLLs (unless doing so breaks something?) - at the moment it says copyright Microsoft, which is clearly wrong. The rest of this post is a bit long-winded - there's nothing else really important to 3Dmigoto (TL;DR: The MIT license is a fine choice), but it might be an interesting read to people for a bit of background on open source licensing. [quote]The only reason I went with an MIT license was because it was easy in Github, and the logical easiest one. Chiri actually didn't care if it had a license at all, and I was going to go with the WTFPL, but Github didn't support it.[/quote]You can actually use any license with github - they provide templates for the more widely accepted open source licenses, but you can select none and add your own if you like (or even use no license at all, but in that case it will be covered by standard copyright, which is probably not what you want). Having said that I do think it's better to go with one of the widely accepted open source licenses - the open source community has developed many of these with legal advice, so you're less likely to run into unexpected issues with them (though this can still happen - like the license incompatibility between the AGPLv1 and the GPLv2), and they all include standard disclaimers to limit your liability and give you some legal protection against people who would abuse your generosity. [quote]I've left the copyright for Chiri, because of his extremely generous contribution of providing the source.[/quote]That's fine - the project wide license.txt is not required to be an exhaustive list, and usually just lists the most significant copyright holder(s) for the project. We might consider adding copyright notices to each (new) source file though, which is standard practice in many open source projects and allows better granularity of copyright notices for projects with multiple contributors. At the end of the day though - these notices are just to help people identify the copyright holders, but the real copyright holder for a given line of code is whoever authored it, and the commit history is the best place to look that up. [quote]The copyright is mostly incompatible with the idea of the MIT license anyway, Chiri really wanted it with no restrictions whatsoever, and I only added the copyright because the license required it. The only reason I added a license was because my reading indicated that having no license at all puts it into some sort of limbo, and I didn't want to discourage anyone from using it for whatever they wanted.[/quote]Copyright is automatic in many countries (including Australia where I live), so releasing it without copyright doesn't make sense. You may be able to explicitly relinquish copyright (depending on your country) and donate it to the public domain, but the problem is that other people's contributions will add their copyright on to it, and unless they also relinquish their copyright it is once again protected by copyright law, but now potentially the contributor's copyright rather than the original author - so this is open to abuse and generally a bad idea. This is why open source software retains copyright and uses licenses to grant rights and freedoms that are restricted by standard copyright. Copyright isn't incompatible with this licensing - open source licenses *rely* on copyright to have any legal standing whatsoever. Contributions to open source projects are generally accepted to be licensed under the same license as the project itself (unless an exception is explicitly made), so everyone is clear on what they can and can't do with it, and the potential for abuse is minimised (how much it is minimised depends on the license). One thing to realise is that everyone who contributes retains their own copyright to any work they have contributed regardless of whether their name is in the project wide license.txt file or not. The exception here is projects that require copyright assignment from their contributors, but that's generally only used by certain organisations and even then is considered somewhat controversial due to the potential for abuse (e.g. copyright may be forcefully transferred to an unknown third party if the organisation goes bankrupt or is bought out, which has happened to multiple projects now). [quote]Like all laws, we need to balance what it's worth, with what it costs. I just don't see that the license has any value here at all. Even if someone takes the code and makes a million bucks, that's OK with me, and OK with Chiri.[/quote]In fact, people can go ahead and make money from open source software with a more restrictive license like GPL - the difference is that GPL is designed such that they are required to give any improvements they make back to the community and to ensure they that can't take away other people's rights, while with MIT they can do pretty much whatever they like with it without having to give anything back, so long as they retain the original copyright notice. I think MIT is a fine choice for 3Dmigoto, but here's some food for thought: The WINE project (which allows Windows programs to run under Linux and Mac) was originally released under the MIT license. They have since switched to the LGPL after certain commercial companies took their work, improved upon it and started selling it as a product. The issue wasn't so much that someone was making money out of it, but rather that they had done so without contributing those improvements back to the original community.
bo3b said:This would be OK, but I really do not want to drop another file into the output build just for license stuff. It's just not that important.
Fair enough. Personally I don't care too much if the license.txt is released as part of the build or not - it seems more important for it to stay with the source code than the compiled DLLs. I was only raising this concern as the license seems to require it, but if everyone working on the project is ok with it not being included in the releases that's fine with me.

One thing we might want to fix is the copyright information in the .rc files that gets embedded inside the DLLs (unless doing so breaks something?) - at the moment it says copyright Microsoft, which is clearly wrong.


The rest of this post is a bit long-winded - there's nothing else really important to 3Dmigoto (TL;DR: The MIT license is a fine choice), but it might be an interesting read to people for a bit of background on open source licensing.

The only reason I went with an MIT license was because it was easy in Github, and the logical easiest one. Chiri actually didn't care if it had a license at all, and I was going to go with the WTFPL, but Github didn't support it.
You can actually use any license with github - they provide templates for the more widely accepted open source licenses, but you can select none and add your own if you like (or even use no license at all, but in that case it will be covered by standard copyright, which is probably not what you want). Having said that I do think it's better to go with one of the widely accepted open source licenses - the open source community has developed many of these with legal advice, so you're less likely to run into unexpected issues with them (though this can still happen - like the license incompatibility between the AGPLv1 and the GPLv2), and they all include standard disclaimers to limit your liability and give you some legal protection against people who would abuse your generosity.

I've left the copyright for Chiri, because of his extremely generous contribution of providing the source.
That's fine - the project wide license.txt is not required to be an exhaustive list, and usually just lists the most significant copyright holder(s) for the project. We might consider adding copyright notices to each (new) source file though, which is standard practice in many open source projects and allows better granularity of copyright notices for projects with multiple contributors. At the end of the day though - these notices are just to help people identify the copyright holders, but the real copyright holder for a given line of code is whoever authored it, and the commit history is the best place to look that up.

The copyright is mostly incompatible with the idea of the MIT license anyway, Chiri really wanted it with no restrictions whatsoever, and I only added the copyright because the license required it. The only reason I added a license was because my reading indicated that having no license at all puts it into some sort of limbo, and I didn't want to discourage anyone from using it for whatever they wanted.
Copyright is automatic in many countries (including Australia where I live), so releasing it without copyright doesn't make sense. You may be able to explicitly relinquish copyright (depending on your country) and donate it to the public domain, but the problem is that other people's contributions will add their copyright on to it, and unless they also relinquish their copyright it is once again protected by copyright law, but now potentially the contributor's copyright rather than the original author - so this is open to abuse and generally a bad idea.

This is why open source software retains copyright and uses licenses to grant rights and freedoms that are restricted by standard copyright. Copyright isn't incompatible with this licensing - open source licenses *rely* on copyright to have any legal standing whatsoever. Contributions to open source projects are generally accepted to be licensed under the same license as the project itself (unless an exception is explicitly made), so everyone is clear on what they can and can't do with it, and the potential for abuse is minimised (how much it is minimised depends on the license).

One thing to realise is that everyone who contributes retains their own copyright to any work they have contributed regardless of whether their name is in the project wide license.txt file or not. The exception here is projects that require copyright assignment from their contributors, but that's generally only used by certain organisations and even then is considered somewhat controversial due to the potential for abuse (e.g. copyright may be forcefully transferred to an unknown third party if the organisation goes bankrupt or is bought out, which has happened to multiple projects now).

Like all laws, we need to balance what it's worth, with what it costs. I just don't see that the license has any value here at all. Even if someone takes the code and makes a million bucks, that's OK with me, and OK with Chiri.
In fact, people can go ahead and make money from open source software with a more restrictive license like GPL - the difference is that GPL is designed such that they are required to give any improvements they make back to the community and to ensure they that can't take away other people's rights, while with MIT they can do pretty much whatever they like with it without having to give anything back, so long as they retain the original copyright notice.

I think MIT is a fine choice for 3Dmigoto, but here's some food for thought: The WINE project (which allows Windows programs to run under Linux and Mac) was originally released under the MIT license. They have since switched to the LGPL after certain commercial companies took their work, improved upon it and started selling it as a product. The issue wasn't so much that someone was making money out of it, but rather that they had done so without contributing those improvements back to the original community.

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

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

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

Posted 02/10/2015 11:39 AM   
[quote="bo3b"]OK, good to know. These are shaders that you need for a fix I assume?[/quote] I'm not sure yet. I've hit one that did need a fix (the hand vertex shader I mentioned), but I was able to apply the fix in the two related pixel shaders instead. I know that a bunch of other surfaces have halos that need fixing, so I wouldn't be surprised if I run into more of the same type later on. For the sake of prioritising things - I'm guessing that the float2x4 and missing constant buffer name errors will be more important than the error parsing buffer offset or SV_Depth issue, but I won't know for sure until I fix more of the game.
bo3b said:OK, good to know. These are shaders that you need for a fix I assume?


I'm not sure yet. I've hit one that did need a fix (the hand vertex shader I mentioned), but I was able to apply the fix in the two related pixel shaders instead. I know that a bunch of other surfaces have halos that need fixing, so I wouldn't be surprised if I run into more of the same type later on.

For the sake of prioritising things - I'm guessing that the float2x4 and missing constant buffer name errors will be more important than the error parsing buffer offset or SV_Depth issue, but I won't know for sure until I fix more of the game.

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

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

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

Posted 02/10/2015 11:48 AM   
Latest update is 0.99.40 at: [url]https://github.com/bo3b/3Dmigoto/releases[/url] This version includes DarkStarSword's F10 to reload d3dx.ini without requiring game restart. Also includes my latest change to support auto-repeat for shader hunting. Speed of repeat can be changed in d3dx.ini in the Hunting section. There is a trade-off between how fast you can auto cycle through shaders, but then still be able to single step once you find them.
Latest update is 0.99.40 at: https://github.com/bo3b/3Dmigoto/releases


This version includes DarkStarSword's F10 to reload d3dx.ini without requiring game restart.

Also includes my latest change to support auto-repeat for shader hunting.

Speed of repeat can be changed in d3dx.ini in the Hunting section. There is a trade-off between how fast you can auto cycle through shaders, but then still be able to single step once you find them.

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

Posted 02/11/2015 08:36 AM   
[quote="bo3b"]Latest update is 0.99.40 at: [url]https://github.com/bo3b/3Dmigoto/releases[/url] This version includes DarkStarSword's F10 to reload d3dx.ini without requiring game restart. Also includes my latest change to support auto-repeat for shader hunting. Speed of repeat can be changed in d3dx.ini in the Hunting section. There is a trade-off between how fast you can auto cycle through shaders, but then still be able to single step once you find them.[/quote] Great stuff. I am waaaaaay behind on all the updates you guys are doing to this, I've not been able to do any work for a couple of weeks. When I get back to FC4 (who knows when...) I'll pull this one down and try it out. Does the default d3dx.ini have lots of nice comments describing all the new features?
bo3b said:Latest update is 0.99.40 at: https://github.com/bo3b/3Dmigoto/releases


This version includes DarkStarSword's F10 to reload d3dx.ini without requiring game restart.

Also includes my latest change to support auto-repeat for shader hunting.

Speed of repeat can be changed in d3dx.ini in the Hunting section. There is a trade-off between how fast you can auto cycle through shaders, but then still be able to single step once you find them.

Great stuff. I am waaaaaay behind on all the updates you guys are doing to this, I've not been able to do any work for a couple of weeks. When I get back to FC4 (who knows when...) I'll pull this one down and try it out. Does the default d3dx.ini have lots of nice comments describing all the new features?

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

Posted 02/11/2015 09:05 PM   
[quote="mike_ar69"]Great stuff. I am waaaaaay behind on all the updates you guys are doing to this, I've not been able to do any work for a couple of weeks. When I get back to FC4 (who knows when...) I'll pull this one down and try it out. Does the default d3dx.ini have lots of nice comments describing all the new features?[/quote] Heh! With a new architecture for keyboard handling it's been a lot easier to add things we've wanted for a long time like that auto-repeat. I'm hopeful that will remove an annoyance for shader hunting. The d3dx.ini does have updated documentation for the key handling setup. It's different than the syntax used for HelixMod, but similar ideas. If you or others think it would be better to use the HelixMod syntax for key handling for consistency, we can do that. We didn't go that route initially because I don't really care for Helix's tweaky syntax there, and wanted something more clear. There would be value in keeping the same syntax everywhere of course. DarkStarSword also just added XBox controller support for both hunting and game playing, so we'll no longer need to use Xpadder. No documentation on XBox use just yet, we need to decide whether to use Flugan's syntax or not. Latest version is 0.99.41.
mike_ar69 said:Great stuff. I am waaaaaay behind on all the updates you guys are doing to this, I've not been able to do any work for a couple of weeks. When I get back to FC4 (who knows when...) I'll pull this one down and try it out. Does the default d3dx.ini have lots of nice comments describing all the new features?

Heh! With a new architecture for keyboard handling it's been a lot easier to add things we've wanted for a long time like that auto-repeat. I'm hopeful that will remove an annoyance for shader hunting.

The d3dx.ini does have updated documentation for the key handling setup. It's different than the syntax used for HelixMod, but similar ideas. If you or others think it would be better to use the HelixMod syntax for key handling for consistency, we can do that. We didn't go that route initially because I don't really care for Helix's tweaky syntax there, and wanted something more clear. There would be value in keeping the same syntax everywhere of course.


DarkStarSword also just added XBox controller support for both hunting and game playing, so we'll no longer need to use Xpadder. No documentation on XBox use just yet, we need to decide whether to use Flugan's syntax or not.


Latest version is 0.99.41.

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

Posted 02/12/2015 02:37 AM   
Hi bo3b - please don't change anything on my account, I can learn two things :-) I am very excited about it though, great work from you and DarkStarSword implementing all this stuff.
Hi bo3b - please don't change anything on my account, I can learn two things :-) I am very excited about it though, great work from you and DarkStarSword implementing all this stuff.

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

Posted 02/12/2015 04:32 AM   
Latest update of 3Dmigoto is available at: [url]https://github.com/bo3b/3Dmigoto/releases/tag/0.99.45-alpha[/url] This includes all of the recent changes, including 1) XBox controller support for both hunting and playing 2) new delay and release_delay parameters for KEY presets 3) Info on how to use the new key presets in the default .ini files. 4) Auto-repeat on shader hunting keys, with repeat_rate as a user choice. And, a very nice change that was prompted by DarkStarSword- actual version numbers in the DLLs. If you do properties on the files, you'll now see a computer added version number. This should make keeping track of the different versions easier.
Latest update of 3Dmigoto is available at:

https://github.com/bo3b/3Dmigoto/releases/tag/0.99.45-alpha


This includes all of the recent changes, including
1) XBox controller support for both hunting and playing
2) new delay and release_delay parameters for KEY presets
3) Info on how to use the new key presets in the default .ini files.
4) Auto-repeat on shader hunting keys, with repeat_rate as a user choice.

And, a very nice change that was prompted by DarkStarSword- actual version numbers in the DLLs. If you do properties on the files, you'll now see a computer added version number. This should make keeping track of the different versions easier.

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

Posted 02/16/2015 09:39 AM   
[quote="DarkStarSword"]3Dmigoto hit some parse errors in Lichdom Battlemage, which prevents certain shaders from being dumped as HLSL (including the hand vertex shader - for now I've fixed the halo on that in the pixel shader instead): [code] $ grep error d3d11_log.txt |sort -u error parsing shader> 3 Error parsing buffer offset: cb0[1].w error parsing shader> 3 Error parsing buffer offset: cb0[1].xyzw error parsing shader> 3 Error parsing buffer offset: cb0[5].xyw error parsing shader> Error parsing output signature: // SV_Depth 0 N/A oDepth DEPTH float YES error parsing shader> Missing constant buffer name: cb7[r0.w+1].xyzw error parsing shader> Missing constant buffer name: cb7[r0.x+1].xyzw error parsing shader> Missing constant buffer name: cb7[r0.y+1].xyzw error parsing shader> Missing constant buffer name: cb7[r0.z+1].xyzw error parsing shader> Unknown data type: float2x4 [/code] <snip>[/quote] OK, I just pushed up a fix for the float2x4 matrices that should work. I did a spot check of 4 shaders with WinMerge, and the shaders recompile properly. That makes Lichdom Decompile some 1700 shaders, with about 22 errors remaining, nearly all the SV_Depth problem. Presently only top-of-tree, will pick it up in next build. Let me know if anyone needs it earlier.
DarkStarSword said:3Dmigoto hit some parse errors in Lichdom Battlemage, which prevents certain shaders from being dumped as HLSL (including the hand vertex shader - for now I've fixed the halo on that in the pixel shader instead):
$ grep error d3d11_log.txt |sort -u
error parsing shader> 3 Error parsing buffer offset: cb0[1].w
error parsing shader> 3 Error parsing buffer offset: cb0[1].xyzw
error parsing shader> 3 Error parsing buffer offset: cb0[5].xyw
error parsing shader> Error parsing output signature: // SV_Depth 0 N/A oDepth DEPTH float YES
error parsing shader> Missing constant buffer name: cb7[r0.w+1].xyzw
error parsing shader> Missing constant buffer name: cb7[r0.x+1].xyzw
error parsing shader> Missing constant buffer name: cb7[r0.y+1].xyzw
error parsing shader> Missing constant buffer name: cb7[r0.z+1].xyzw
error parsing shader> Unknown data type: float2x4


<snip>

OK, I just pushed up a fix for the float2x4 matrices that should work. I did a spot check of 4 shaders with WinMerge, and the shaders recompile properly.

That makes Lichdom Decompile some 1700 shaders, with about 22 errors remaining, nearly all the SV_Depth problem.


Presently only top-of-tree, will pick it up in next build. Let me know if anyone needs it earlier.

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

Posted 02/17/2015 05:27 AM   
I've pushed up an implementation of type=cycle key bindings, which will be in the next release. It feels like the key binding support is almost complete at this point, except for maybe a few small touch ups. Does anyone have a pressing use case or feature request that is not covered by the new key binding support? With type=cycle, you can specify lists of x, y, z, w, separation, convergence and transition to cycle between. Delay cannot be cycled at the moment because I implemented it in a different place (same reason delay only works with type=hold - if there's demand I might revisit that). Here's an example that might be used to make the UI depth adjustable on a single key, with transitions: [code] [Key1] Key = grave Type = cycle x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995 transition = 300,100 [/code] In this case the x list has 11 values, while the transition list only has 2. The final elements of short lists are repeated, so this will evaluate to (as printed in the log): [code] Cycle 1: x=0 transition=300 Cycle 2: x=0.1 transition=100 Cycle 3: x=0.2 transition=100 Cycle 4: x=0.3 transition=100 Cycle 5: x=0.4 transition=100 Cycle 6: x=0.5 transition=100 Cycle 7: x=0.6 transition=100 Cycle 8: x=0.7 transition=100 Cycle 9: x=0.8 transition=100 Cycle 10: x=0.9 transition=100 Cycle 11: x=0.995 transition=100 [/code] It is possible to explicitly omit a value from a list to avoid it getting set on a given cycle, by leaving an entry blank (e.g. x=1,2,,3,4). This is most useful at the end of a short list if you don't want the final value to be repeated, as in: [code] [Key2] Key = left_control type = cycle x = 0, 0.25, 0.5, 0.75, 0.995 transition = 100,, [/code] Which will evaluate to: [code] Cycle 1: x=0 transition=100 Cycle 2: x=0.25 Cycle 3: x=0.5 Cycle 4: x=0.75 Cycle 5: x=0.995 [/code]
I've pushed up an implementation of type=cycle key bindings, which will be in the next release. It feels like the key binding support is almost complete at this point, except for maybe a few small touch ups. Does anyone have a pressing use case or feature request that is not covered by the new key binding support?



With type=cycle, you can specify lists of x, y, z, w, separation, convergence and transition to cycle between. Delay cannot be cycled at the moment because I implemented it in a different place (same reason delay only works with type=hold - if there's demand I might revisit that).

Here's an example that might be used to make the UI depth adjustable on a single key, with transitions:

[Key1]
Key = grave
Type = cycle
x = 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 0.995
transition = 300,100

In this case the x list has 11 values, while the transition list only has 2. The final elements of short lists are repeated, so this will evaluate to (as printed in the log):

Cycle 1: x=0 transition=300
Cycle 2: x=0.1 transition=100
Cycle 3: x=0.2 transition=100
Cycle 4: x=0.3 transition=100
Cycle 5: x=0.4 transition=100
Cycle 6: x=0.5 transition=100
Cycle 7: x=0.6 transition=100
Cycle 8: x=0.7 transition=100
Cycle 9: x=0.8 transition=100
Cycle 10: x=0.9 transition=100
Cycle 11: x=0.995 transition=100


It is possible to explicitly omit a value from a list to avoid it getting set on a given cycle, by leaving an entry blank (e.g. x=1,2,,3,4). This is most useful at the end of a short list if you don't want the final value to be repeated, as in:

[Key2]
Key = left_control
type = cycle
x = 0, 0.25, 0.5, 0.75, 0.995
transition = 100,,

Which will evaluate to:
Cycle 1: x=0 transition=100
Cycle 2: x=0.25
Cycle 3: x=0.5
Cycle 4: x=0.75
Cycle 5: x=0.995

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

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

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

Posted 02/17/2015 04:18 PM   
I find it difficult to fit this inside my existing code at this moment. I will wait and see how it used in reality. Here the example is hud depth but I see it better written permanently in the ini file as it would save the value between play sessions. Obviously it has more uses. I have delay on all buttons but I only see specific need on hold and toggle. I also have not looked into how whitespace is handled in default parsing I'm doing. type = cycle vs type=cycle One of these Key sections would crash my current implementation unless I'm mistaken. Should probably make sure any cycle section is ignored just for now. By the way leaving the last entry empty looks like transition=100, not transition=100,, cycle obviously has much more parsing. I assume cycle loops actually making the transition from last to first the biggest. Or the first keypress when we don't know where we are. Are we happy with this syntax? It is pretty flexible and concise. Another special case would be specifying elements at the end. transition=...,100,300 But that would be a weird special case. Looking at my code it does not look good. Delays and transition handling being huge.
I find it difficult to fit this inside my existing code at this moment. I will wait and see how it used in reality. Here the example is hud depth but I see it better written permanently in the ini file as it would save the value between play sessions. Obviously it has more uses.

I have delay on all buttons but I only see specific need on hold and toggle.
I also have not looked into how whitespace is handled in default parsing I'm doing.

type = cycle
vs
type=cycle

One of these Key sections would crash my current implementation unless I'm mistaken.
Should probably make sure any cycle section is ignored just for now.

By the way leaving the last entry empty looks like
transition=100,
not
transition=100,,

cycle obviously has much more parsing.
I assume cycle loops actually making the transition from last to first the biggest.
Or the first keypress when we don't know where we are.

Are we happy with this syntax? It is pretty flexible and concise.
Another special case would be specifying elements at the end.
transition=...,100,300
But that would be a weird special case.

Looking at my code it does not look good. Delays and transition handling being huge.

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

donations: ulfjalmbrant@hotmail.com

Posted 02/17/2015 07:46 PM   
  18 / 141    
Scroll To Top