3Dmigoto now open-source...
  127 / 143    
Gah, I think I've spotted the bug - we take a fairly generous guess at how large the replacement shader might need to be before attempting the substitution, but it is possible to underestimate that. In that case PCRE2 tells us how large the buffer needed to be and we are supposed to try again, but I've got a fairly trivial bug here that meant we never did that retry - I'll fix it for the next release. However, @DJ-RK that "generous guess" that 3DMigoto makes should allow the shader to grow to original shader size + replacement text size + 1KB before hitting this - does that sound plausible for your pattern? Let me say that again - the estimate size allows for the full original shader, and the full (literal) replacement text, and an extra 1024 characters on top of that to allow for capture groups to be substituted in (since we don't know their size in advance). If you're hitting this it suggests that either your pattern is pretty boss, or you might be including some of the original text multiple times that you may not have meant to. If the code was working as intended you would have seen this easter egg in the log: [quote] NOTICE: regex replace requires a %u byte buffer NOTICE: We underestimated by %u bytes and have to start over NOTICE: What kind of crazy are you doing to get down this code path? NOTICE: You didn't inject a matrix inverse or two in assembly did you? NOTICE: Once more, with passion! [/quote]I guess 3DMigoto just wasn't in the mood today :-p @Flugan PCRE2 has it's own heap limit, separate from (well, a subset of) the application's heap, but if not set by 3DMigoto or the pattern, it defaults to whatever PCRE2 was configured with at build time, which is: [code] #define HEAP_LIMIT 20000000 [/code] So, no practical limit - if we manage to consume even 1% of that something has gone terribly wrong.
Gah, I think I've spotted the bug - we take a fairly generous guess at how large the replacement shader might need to be before attempting the substitution, but it is possible to underestimate that. In that case PCRE2 tells us how large the buffer needed to be and we are supposed to try again, but I've got a fairly trivial bug here that meant we never did that retry - I'll fix it for the next release.

However, @DJ-RK that "generous guess" that 3DMigoto makes should allow the shader to grow to original shader size + replacement text size + 1KB before hitting this - does that sound plausible for your pattern? Let me say that again - the estimate size allows for the full original shader, and the full (literal) replacement text, and an extra 1024 characters on top of that to allow for capture groups to be substituted in (since we don't know their size in advance). If you're hitting this it suggests that either your pattern is pretty boss, or you might be including some of the original text multiple times that you may not have meant to. If the code was working as intended you would have seen this easter egg in the log:

NOTICE: regex replace requires a %u byte buffer
NOTICE: We underestimated by %u bytes and have to start over
NOTICE: What kind of crazy are you doing to get down this code path?
NOTICE: You didn't inject a matrix inverse or two in assembly did you?
NOTICE: Once more, with passion!
I guess 3DMigoto just wasn't in the mood today :-p


@Flugan PCRE2 has it's own heap limit, separate from (well, a subset of) the application's heap, but if not set by 3DMigoto or the pattern, it defaults to whatever PCRE2 was configured with at build time, which is:

#define HEAP_LIMIT              20000000

So, no practical limit - if we manage to consume even 1% of that something has gone terribly wrong.

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/22/2018 12:14 PM   
0MB of heap limit is pretty small though.
0MB of heap limit is pretty small though.

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/22/2018 12:49 PM   
So yeah, last night I got to trying your suggestions. (*LIMIT_HEAP=d) (where I replaced the d with 1024, 1048576, etc) spat back an error along the lines of "(*VERB) not recognized" or something. (*NO_JIT) didn't spit an error back, but then the shader wouldn't match the pattern anymore. Lastly, just removing the 'ResourceNameInHeader(?s).*' part, and just starting with the pattern got it working. [quote="DarkStarSword"]However, @DJ-RK that "generous guess" that 3DMigoto makes should allow the shader to grow to original shader size + replacement text size + 1KB before hitting this - does that sound plausible for your pattern? Let me say that again - the estimate size allows for the full original shader, and the full (literal) replacement text, and an extra 1024 characters on top of that to allow for capture groups to be substituted in (since we don't know their size in advance).[/quote] Ummm, I wouldn't really think so, but I'll attach the files that you asked for before and maybe you can wager a better guess than I. It's ShaderRegex_PntLights that's the culprit for this. [quote]If you're hitting this it suggests that either your pattern is pretty boss[/quote] Well, I certainly think it's pretty boss, just not THAT boss ;)
So yeah, last night I got to trying your suggestions. (*LIMIT_HEAP=d) (where I replaced the d with 1024, 1048576, etc) spat back an error along the lines of "(*VERB) not recognized" or something. (*NO_JIT) didn't spit an error back, but then the shader wouldn't match the pattern anymore. Lastly, just removing the 'ResourceNameInHeader(?s).*' part, and just starting with the pattern got it working.

DarkStarSword said:However, @DJ-RK that "generous guess" that 3DMigoto makes should allow the shader to grow to original shader size + replacement text size + 1KB before hitting this - does that sound plausible for your pattern? Let me say that again - the estimate size allows for the full original shader, and the full (literal) replacement text, and an extra 1024 characters on top of that to allow for capture groups to be substituted in (since we don't know their size in advance).


Ummm, I wouldn't really think so, but I'll attach the files that you asked for before and maybe you can wager a better guess than I. It's ShaderRegex_PntLights that's the culprit for this.



If you're hitting this it suggests that either your pattern is pretty boss


Well, I certainly think it's pretty boss, just not THAT boss ;)
Attachments

Bad Regex.zip.jpg

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 02/22/2018 04:20 PM   
Ahh, there it is: [code] //${prefix}${pos}.xyzx\n ${prefix}${tmp1}.xyzx\n [/code] You've inserted ${prefix} twice, which will well and truly exceed the 1KB estimate 3DMigoto made. That looks like a mistake - prefix has matched most of the shader including declarations, so if you're going to insert that anywhere it should be before the bulk of the replace text. Also beware that if you use the // comment character you are saying "insert this comment into the shader" - I've done that so I can see (and search for) the result in the d3d11_log.txt, but it doesn't actually serve much practical purpose beyond that, and in this case since prefix is many lines that will only comment out the first line of that and the rest will not be commented. You can also use ini style comments in this section (lines starting with a semicolon) for your own benefit, which will not be inserted into the shader.
Ahh, there it is:

//${prefix}${pos}.xyzx\n
${prefix}${tmp1}.xyzx\n

You've inserted ${prefix} twice, which will well and truly exceed the 1KB estimate 3DMigoto made. That looks like a mistake - prefix has matched most of the shader including declarations, so if you're going to insert that anywhere it should be before the bulk of the replace text.

Also beware that if you use the // comment character you are saying "insert this comment into the shader" - I've done that so I can see (and search for) the result in the d3d11_log.txt, but it doesn't actually serve much practical purpose beyond that, and in this case since prefix is many lines that will only comment out the first line of that and the rest will not be commented. You can also use ini style comments in this section (lines starting with a semicolon) for your own benefit, which will not be inserted into the shader.

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/22/2018 05:24 PM   
[quote="DarkStarSword"][quote="DarkStarSword"][quote="DJ-RK"]Oh, and on the topic of my Ryse fix, for some reason 3DM versions 1.32 and 1.33 cause the left eye to be mostly black, 1.31 was able to get it properly working, but now I keep getting errors about it not being able to compile the included custom shaders.[/quote]Ooh, that sounds like a nasty regression. Those version numbers are missing the second dot - I assume you meant it was broken between 1.3.1 and 1.3.2 (or do you mean 1.2.31 and 1.2.32)? [/quote] Hmmm... what happens if you set load_library_redirect=2 under [System]?[/quote] Tested this and confirmed - the new default for the load library redirect has caused our nvapi wrapper not to be loaded, which means we can't disable CryEngine's 3D Vision Direct mode. Setting load_library_redirect=2 restores the old behaviour so you can use that for now. Edit: Created an issue to track this: https://github.com/bo3b/3Dmigoto/issues/89
DarkStarSword said:
DarkStarSword said:
DJ-RK said:Oh, and on the topic of my Ryse fix, for some reason 3DM versions 1.32 and 1.33 cause the left eye to be mostly black, 1.31 was able to get it properly working, but now I keep getting errors about it not being able to compile the included custom shaders.
Ooh, that sounds like a nasty regression. Those version numbers are missing the second dot - I assume you meant it was broken between 1.3.1 and 1.3.2 (or do you mean 1.2.31 and 1.2.32)?


Hmmm... what happens if you set load_library_redirect=2 under [System]?

Tested this and confirmed - the new default for the load library redirect has caused our nvapi wrapper not to be loaded, which means we can't disable CryEngine's 3D Vision Direct mode. Setting load_library_redirect=2 restores the old behaviour so you can use that for now.

Edit: Created an issue to track this: https://github.com/bo3b/3Dmigoto/issues/89

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/22/2018 05:46 PM   
[center][color="orange"][size="XL"]3Dmigoto 1.3.4[/size][/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases/tag/1.3.4[/url][/color][/center] This [s]is still an experimental release, but[/s] includes a fairly significant bug fix (Edit: 1.3.x is now considered stable): If a fix was shipped with cache_shaders=1, then later an update was shipped that modified some of the shaders and a user installed that over the top of the earlier version (without using uninstall.bat) they could still see some of the outdated shaders in use. A related issue also exists where editing a shader and reloading with F10 will appear to work, but after exiting the game and re-launching 3DMigoto would go back to using a potentially outdated .bin file created via cache_shaders=1 (even if that option has since been disabled). Updating to this version of 3DMigoto will cause all cached .bin files in ShaderFixes to be regenerated on demand, and the timestamps will be set to match the .txt files they were generated from. If you have ever pre-compiled shaders into .bin files prior to shipping a fix to cut down on loading times during the first run they will also be invalidated by this update - for this to work you either need to set the timestamps on the .bin files to match the .txt files (with cygwin: "touch --reference xxx.txt xxx.bin"), or move the text files into a separate folder leaving only .bin files in ShaderFixes (though the practice of only shipping binary shaders is discouraged). This update also now issues a warning if both HLSL and Assembly versions of the same shader exist (including cached versions). This warning can appear on F10 reload, when dumping a shader or when launching the game. In the later case, it will display a message telling the user to use uninstall.bat and reinstall the fix, and is intended to catch cases where an update has changed a shader from HLSL to Assembly (or vice versa) and the user did not do a clean update. The other cases are for the benefit of the shaderhacker. Note that this is not a comprehensive scan of every file - it checks shaders on demand as they are used by the game. The missing case here is of course if an update removes a shader from ShaderFixes that was in a previous version - if that is important that it be removed you must indicate that uninstall.bat is necessary to update the fix, or alternatively you could ship the original unmodified shader instead of removing it. Other changes: [list] [.] Fix "no more memory" error in ShaderRegex with particularly boss substitutions.[/.] [.]Fix ref counting issues in the overlay (Bo3b).[/.] [.]Possibly improve compatibility with certain third party modding tools (Bo3b).[/.] [.]Fix compatibility with certain games that do not create an IDXGIFactory (Bo3b).[/.] [/list]
3Dmigoto 1.3.4

This is still an experimental release, but includes a fairly significant bug fix (Edit: 1.3.x is now considered stable):

If a fix was shipped with cache_shaders=1, then later an update was shipped that modified some of the shaders and a user installed that over the top of the earlier version (without using uninstall.bat) they could still see some of the outdated shaders in use. A related issue also exists where editing a shader and reloading with F10 will appear to work, but after exiting the game and re-launching 3DMigoto would go back to using a potentially outdated .bin file created via cache_shaders=1 (even if that option has since been disabled).

Updating to this version of 3DMigoto will cause all cached .bin files in ShaderFixes to be regenerated on demand, and the timestamps will be set to match the .txt files they were generated from.

If you have ever pre-compiled shaders into .bin files prior to shipping a fix to cut down on loading times during the first run they will also be invalidated by this update - for this to work you either need to set the timestamps on the .bin files to match the .txt files (with cygwin: "touch --reference xxx.txt xxx.bin"), or move the text files into a separate folder leaving only .bin files in ShaderFixes (though the practice of only shipping binary shaders is discouraged).

This update also now issues a warning if both HLSL and Assembly versions of the same shader exist (including cached versions). This warning can appear on F10 reload, when dumping a shader or when launching the game. In the later case, it will display a message telling the user to use uninstall.bat and reinstall the fix, and is intended to catch cases where an update has changed a shader from HLSL to Assembly (or vice versa) and the user did not do a clean update. The other cases are for the benefit of the shaderhacker. Note that this is not a comprehensive scan of every file - it checks shaders on demand as they are used by the game.

The missing case here is of course if an update removes a shader from ShaderFixes that was in a previous version - if that is important that it be removed you must indicate that uninstall.bat is necessary to update the fix, or alternatively you could ship the original unmodified shader instead of removing it.

Other changes:
  • Fix "no more memory" error in ShaderRegex with particularly boss substitutions.

  • Fix ref counting issues in the overlay (Bo3b).

  • Possibly improve compatibility with certain third party modding tools (Bo3b).

  • Fix compatibility with certain games that do not create an IDXGIFactory (Bo3b).

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/22/2018 06:52 PM   
[quote="DarkStarSword"][quote="DarkStarSword"][quote="DarkStarSword"][quote="DJ-RK"]Oh, and on the topic of my Ryse fix, for some reason 3DM versions 1.32 and 1.33 cause the left eye to be mostly black, 1.31 was able to get it properly working, but now I keep getting errors about it not being able to compile the included custom shaders.[/quote]Ooh, that sounds like a nasty regression. Those version numbers are missing the second dot - I assume you meant it was broken between 1.3.1 and 1.3.2 (or do you mean 1.2.31 and 1.2.32)? [/quote]Hmmm... what happens if you set load_library_redirect=2 under [System]?[/quote] Tested this and confirmed - the new default for the load library redirect has caused our nvapi wrapper not to be loaded, which means we can't disable CryEngine's 3D Vision Direct mode. Setting load_library_redirect=2 restores the old behaviour so you can use that for now. Edit: Created an issue to track this: [url]https://github.com/bo3b/3Dmigoto/issues/89[/url][/quote]Thanks for checking that. This was what I was expecting for this scenario. Based on this and other experiences, it seems like we'll want to set the default back to always on. There have been at least 3 different games where this is required, and it causes more problems than it's worth to have it off by default. Much more common than I expected. The one key scenario where it needs to be off is when using proxy, and that is already handled in the code, by setting if off programmaticly. I'll reset the defaults based on your issue #89.
DarkStarSword said:
DarkStarSword said:
DarkStarSword said:
DJ-RK said:Oh, and on the topic of my Ryse fix, for some reason 3DM versions 1.32 and 1.33 cause the left eye to be mostly black, 1.31 was able to get it properly working, but now I keep getting errors about it not being able to compile the included custom shaders.
Ooh, that sounds like a nasty regression. Those version numbers are missing the second dot - I assume you meant it was broken between 1.3.1 and 1.3.2 (or do you mean 1.2.31 and 1.2.32)?
Hmmm... what happens if you set load_library_redirect=2 under [System]?

Tested this and confirmed - the new default for the load library redirect has caused our nvapi wrapper not to be loaded, which means we can't disable CryEngine's 3D Vision Direct mode. Setting load_library_redirect=2 restores the old behaviour so you can use that for now.

Edit: Created an issue to track this: https://github.com/bo3b/3Dmigoto/issues/89
Thanks for checking that. This was what I was expecting for this scenario.

Based on this and other experiences, it seems like we'll want to set the default back to always on. There have been at least 3 different games where this is required, and it causes more problems than it's worth to have it off by default. Much more common than I expected. The one key scenario where it needs to be off is when using proxy, and that is already handled in the code, by setting if off programmaticly.

I'll reset the defaults based on your issue #89.

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/22/2018 09:12 PM   
[quote="DarkStarSword"]Ahh, there it is: [code] //${prefix}${pos}.xyzx\n ${prefix}${tmp1}.xyzx\n [/code] You've inserted ${prefix} twice, which will well and truly exceed the 1KB estimate 3DMigoto made. That looks like a mistake - prefix has matched most of the shader including declarations, so if you're going to insert that anywhere it should be before the bulk of the replace text.[/quote] Bah, must have been tired when I wrote that, that definitely was an error and not my intention... or rather, 2 actually. Missed creating a separate capture group for the line of code where I'm replacing the v2 with a temp, and using that, so that section specifically should have been: [code]//${post1}${pos}.xyzx\n ${post1}${tmp1}.xyzx\n ${post2}[/code] [quote]Also beware that if you use the // comment character you are saying "insert this comment into the shader" - I've done that so I can see (and search for) the result in the d3d11_log.txt, but it doesn't actually serve much practical purpose beyond that[/quote] Yeah, I simply was trying to maintain the idea of commenting out the original line of code that I'm outright replacing a register with. Call me old fashioned. ;) Also, thanks for testing the set load_library_redirect=2. I could have sworn that was one of the first things I tried when it wasn't working, but I'll give it another shot. And, of course, thanks for the latest update you guys, it can never be stated enough just how awesome of a job you have done over the years and how much I am grateful for all your hard work and generous support.
DarkStarSword said:Ahh, there it is:

//${prefix}${pos}.xyzx\n
${prefix}${tmp1}.xyzx\n

You've inserted ${prefix} twice, which will well and truly exceed the 1KB estimate 3DMigoto made. That looks like a mistake - prefix has matched most of the shader including declarations, so if you're going to insert that anywhere it should be before the bulk of the replace text.


Bah, must have been tired when I wrote that, that definitely was an error and not my intention... or rather, 2 actually. Missed creating a separate capture group for the line of code where I'm replacing the v2 with a temp, and using that, so that section specifically should have been:

//${post1}${pos}.xyzx\n
${post1}${tmp1}.xyzx\n
${post2}



Also beware that if you use the // comment character you are saying "insert this comment into the shader" - I've done that so I can see (and search for) the result in the d3d11_log.txt, but it doesn't actually serve much practical purpose beyond that


Yeah, I simply was trying to maintain the idea of commenting out the original line of code that I'm outright replacing a register with. Call me old fashioned. ;)


Also, thanks for testing the set load_library_redirect=2. I could have sworn that was one of the first things I tried when it wasn't working, but I'll give it another shot.

And, of course, thanks for the latest update you guys, it can never be stated enough just how awesome of a job you have done over the years and how much I am grateful for all your hard work and generous support.

3D Gaming Rig: CPU: i7 7700K @ 4.9Ghz | Mobo: Asus Maximus Hero VIII | RAM: Corsair Dominator 16GB | GPU: 2 x GTX 1080 Ti SLI | 3xSSDs for OS and Apps, 2 x HDD's for 11GB storage | PSU: Seasonic X-1250 M2| Case: Corsair C70 | Cooling: Corsair H115i Hydro cooler | Displays: Asus PG278QR, BenQ XL2420TX & BenQ HT1075 | OS: Windows 10 Pro + Windows 7 dual boot

Like my fixes? Dontations can be made to: www.paypal.me/DShanz or rshannonca@gmail.com
Like electronic music? Check out: www.soundcloud.com/dj-ryan-king

Posted 02/23/2018 04:20 AM   
[center][color="orange"][size="XL"]3Dmigoto 1.2.73 < Final Maintenance Release >[/size][/color][/center][center][color="green"][url]https://github.com/bo3b/3Dmigoto/releases/tag/1.2.73[/url][/color][/center] This is a maintenance release, and likely to be the final release in the 1.2.x series. The 1.3.x series is now considered pretty stable, and you should preference using that if at all possible, and if for some reason 1.3 is not working then please report it to us. This release includes the following backports from the 1.3.x series: [list] [.] Fixes long standing bug where cache_shaders=1 could cause users to keep seeing outdated shaders used after an update. See [url=https://forums.geforce.com/default/topic/685657/3d-vision/3dmigoto-now-open-source-/post/5295066/#5295066]this post[/url] for details. Note that this does not include the warning if conflicting HLSL and Assembly shaders are present, due to the lack of overlay notifications in 1.2.x.[/.] [.] Add load_library_redirect flag to d3dx.ini to fix broken proxy loading.[/.] [.] Set permissions on game directory to resolve locked out issues.[/.] [.] Set permissions on dumped shaders to resolve locked out issues.[/.] [.] Fix "no more memory" error in ShaderRegex with particularly boss substitutions.[/.] [/list]
3Dmigoto 1.2.73
< Final Maintenance Release >

This is a maintenance release, and likely to be the final release in the 1.2.x series. The 1.3.x series is now considered pretty stable, and you should preference using that if at all possible, and if for some reason 1.3 is not working then please report it to us.

This release includes the following backports from the 1.3.x series:

  • Fixes long standing bug where cache_shaders=1 could cause users to keep seeing outdated shaders used after an update. See this post for details. Note that this does not include the warning if conflicting HLSL and Assembly shaders are present, due to the lack of overlay notifications in 1.2.x.

  • Add load_library_redirect flag to d3dx.ini to fix broken proxy loading.

  • Set permissions on game directory to resolve locked out issues.

  • Set permissions on dumped shaders to resolve locked out issues.

  • Fix "no more memory" error in ShaderRegex with particularly boss substitutions.

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/23/2018 05:51 AM   
One thing I've been wanting to do for a while is to get some statistics on how much work goes into 3DMigoto - this has largely been for my own benefit (it's nice to know roughly how many tens of thousands of lines of code I've contributed and all), but I thought it might be interesting to share the results with the community as well, especially now that 1.3 is out so the work that went into that is visible. This isn't a competition or anything, but it does highlight how much work Bo3b and I and others have put in to get 3DMigoto to where it is today. This is actually really hard to get accurate statistics on this for a variety of reasons (game fixes in the repository, misattributed commits, third party code, git subtree, multiple authors working on the same part of the code, refactoring work, tool assisted bulk changes, etc. etc. etc. - the list goes on and on), and there are a variety of ways it could be counted - none of which are perfect. I've ended up writing a script to clean up the repository (e.g. removing game fixes and third party code, and fixing up some authorship information) and used gitstats to count everything - this should only be considered a "best effort" and if you can inspect the [url=https://github.com/DarkStarSword/3d-fixes/blob/master/3DMigoto-stats.sh]cleanup script[/url] for yourself if you wish. The actual stats are here: [url]https://darkstarsword.net/3Dmigoto-stats/[/url], and hopefully that will update automatically every day to reflect the latest work in the master branch (if I got that crontab entry right). A couple of highlights: [center] [size="L"][color="orange"]Cumulated Added Lines of Code per Author:[/color][/size] [url=https://darkstarsword.net/3Dmigoto-stats/authors.html#cumulated_added_lines_of_code_per_author] [img]https://darkstarsword.net/3Dmigoto-stats/lines_of_code_by_author.png[/img][/url] [size="L"][color="orange"]Commits per Author:[/color][/size] [url=https://darkstarsword.net/3Dmigoto-stats/authors.html#commits_per_author] [img]https://darkstarsword.net/3Dmigoto-stats/commits_by_author.png[/img][/url] [/center]
One thing I've been wanting to do for a while is to get some statistics on how much work goes into 3DMigoto - this has largely been for my own benefit (it's nice to know roughly how many tens of thousands of lines of code I've contributed and all), but I thought it might be interesting to share the results with the community as well, especially now that 1.3 is out so the work that went into that is visible. This isn't a competition or anything, but it does highlight how much work Bo3b and I and others have put in to get 3DMigoto to where it is today.

This is actually really hard to get accurate statistics on this for a variety of reasons (game fixes in the repository, misattributed commits, third party code, git subtree, multiple authors working on the same part of the code, refactoring work, tool assisted bulk changes, etc. etc. etc. - the list goes on and on), and there are a variety of ways it could be counted - none of which are perfect. I've ended up writing a script to clean up the repository (e.g. removing game fixes and third party code, and fixing up some authorship information) and used gitstats to count everything - this should only be considered a "best effort" and if you can inspect the cleanup script for yourself if you wish.

The actual stats are here: https://darkstarsword.net/3Dmigoto-stats/, and hopefully that will update automatically every day to reflect the latest work in the master branch (if I got that crontab entry right).

A couple of highlights:

Cumulated Added Lines of Code per Author:

Image



Commits per Author:

Image

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/23/2018 09:05 AM   
Plenty left to do before this is usable, but you can draw your own conclusions from this screenshot: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/74677/[/img]
Plenty left to do before this is usable, but you can draw your own conclusions from this screenshot:

Image

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/24/2018 11:11 AM   
Nice work :)
Nice work :)

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/24/2018 11:56 AM   
I'm so tired I'm going to fall asleep any moment now, but progress update - I now have 3DMigoto working with Windows Store apps (using Rise of the Tomb Raider to test), including logging, overlay and hunting via an XBox controller (our keyboard input API doesn't work in the Windows Store containers, nor do the beeps). There is still further work that needs to happen before this is ready to ship - in particular it needs to be able to work from a slightly awkward directory since the containers can access almost nothing in the filesystem by default, and I'll need to polish up the injector/installer. The method I'm using does not require the system DirectX to be replaced, nor does it require developer mode or side loading to be enabled, but it does require 3DMigoto (or at least the injector) to be installed along with a code signing certificate - not sure how likely (or expensive) it is to get that signed by MS or Verisign or whoever, so I'll likely just ship a certificate you have to install (at least to begin with). 3D screenshots don't seem to work in Windows Store apps, so here's just one eye with pink hunting mode: [img]https://forums.geforce.com/cmd/default/download-comment-attachment/74678/[/img]
I'm so tired I'm going to fall asleep any moment now, but progress update - I now have 3DMigoto working with Windows Store apps (using Rise of the Tomb Raider to test), including logging, overlay and hunting via an XBox controller (our keyboard input API doesn't work in the Windows Store containers, nor do the beeps). There is still further work that needs to happen before this is ready to ship - in particular it needs to be able to work from a slightly awkward directory since the containers can access almost nothing in the filesystem by default, and I'll need to polish up the injector/installer. The method I'm using does not require the system DirectX to be replaced, nor does it require developer mode or side loading to be enabled, but it does require 3DMigoto (or at least the injector) to be installed along with a code signing certificate - not sure how likely (or expensive) it is to get that signed by MS or Verisign or whoever, so I'll likely just ship a certificate you have to install (at least to begin with).

3D screenshots don't seem to work in Windows Store apps, so here's just one eye with pink hunting mode:

Image

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/24/2018 09:25 PM   
Awesome work as usual DSS
Awesome work as usual DSS

Gigabyte RTX2080TI Gaming OC, I7-6700k ~ 4.4Ghz, 3x BenQ XL2420T, BenQ TK800, LG 55EG960V (3D OLED), Samsung 850 EVO SSD, Crucial M4 SSD, 3D vision kit, Xpand x104 glasses, Corsair HX1000i, Win 10 pro 64/Win 7 64https://www.3dmark.com/fs/9529310

Posted 02/24/2018 10:34 PM   
Great! I have Phantom Dust installed since months ago and I wanted to do something about it (2D bloom effects, one broken effect in battle, I want to put HUD into depth, etc). I'll keep an eye on this and wait patiently until it's done :).
Great! I have Phantom Dust installed since months ago and I wanted to do something about it (2D bloom effects, one broken effect in battle, I want to put HUD into depth, etc). I'll keep an eye on this and wait patiently until it's done :).

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

Posted 02/24/2018 10:36 PM   
  127 / 143    
Scroll To Top