[quote="DarkStarSword"]I worked out the pattern to fix the shadows, so this game is now looking very promising :)[/quote]
You might already be doing this but would it be possible to document these patterns somewhere please? Kinda like issue type e.g. halo; then common patterns and examples of what to look for and how to change to fix them?
Bo3b, Helifax and your good self have often just shown the pattern, then demonstrated the method required to fix or tweak. You all have also added brief comments to the code that explain in simple terms what the added lines do; this is also helpful even if it is just drawing attention to the line of code!
Anyhoo - thanks!
DarkStarSword said:I worked out the pattern to fix the shadows, so this game is now looking very promising :)
You might already be doing this but would it be possible to document these patterns somewhere please? Kinda like issue type e.g. halo; then common patterns and examples of what to look for and how to change to fix them?
Bo3b, Helifax and your good self have often just shown the pattern, then demonstrated the method required to fix or tweak. You all have also added brief comments to the code that explain in simple terms what the added lines do; this is also helpful even if it is just drawing attention to the line of code!
[quote="DarkStarSword"][quote="Oomek"]I have the bad feeling that it's not something that can be overcome. Please tell me I'm wrong.[/quote]I'd have to study it to see what they are doing. You can get information about it in several ways:
- Dump out the textures with frame analysis and compare them to see what's different
- Look for the texture hashes in ShaderUsage.txt (only updated when dumping a shader), and look for the info about the hash (type=Texture2D...) and any operations 3DMigoto noticed being performed on it that might have invalidated the hash.
- Use Frame analysis' logging support to see how the textures are used throughout the frame
The track_texture_updates feature is to keep the texture hashes synchronised with their contents, but only when they are updated from the CPU - it will not update a texture hash if the GPU changed it (and we probably wouldn't want to either since these are mostly render targets where we don't want to match their contents).
If you find that the textures hold several lights and they are always consistently in the same place you could also check the texture coordinates in the shader. If they hold several lights but their placement can change dynamically things get... quite a bit more challenging.
Point is, I can't answer without knowing more.[/quote]
It's weird you know. Sometimes one hash is bound to just one texture, sometimes to few of them. I'll try what you suggested.
I've aloso got one trick left up my sleeve. Since i've got an alpha channel free i can use it as a brightness modifier. It will be necessary though to edit all the textures i'm after, so I'll do it if other methods fail.
Oomek said:I have the bad feeling that it's not something that can be overcome. Please tell me I'm wrong.
I'd have to study it to see what they are doing. You can get information about it in several ways:
- Dump out the textures with frame analysis and compare them to see what's different
- Look for the texture hashes in ShaderUsage.txt (only updated when dumping a shader), and look for the info about the hash (type=Texture2D...) and any operations 3DMigoto noticed being performed on it that might have invalidated the hash.
- Use Frame analysis' logging support to see how the textures are used throughout the frame
The track_texture_updates feature is to keep the texture hashes synchronised with their contents, but only when they are updated from the CPU - it will not update a texture hash if the GPU changed it (and we probably wouldn't want to either since these are mostly render targets where we don't want to match their contents).
If you find that the textures hold several lights and they are always consistently in the same place you could also check the texture coordinates in the shader. If they hold several lights but their placement can change dynamically things get... quite a bit more challenging.
Point is, I can't answer without knowing more.
It's weird you know. Sometimes one hash is bound to just one texture, sometimes to few of them. I'll try what you suggested.
I've aloso got one trick left up my sleeve. Since i've got an alpha channel free i can use it as a brightness modifier. It will be necessary though to edit all the textures i'm after, so I'll do it if other methods fail.
[quote="Flugan"]I wonder if there are hash collitions as crc has fewer slots than md5. Probably not some textures are just identical but used in different fasions.[/quote] Even the number consisting of 8 hexadecimal characters have quite a huge range of values, so its unlikely, but unfortunately probable. I haven't analyzed that hash calculating function, so I cannot exclude that scenario.
Flugan said:I wonder if there are hash collitions as crc has fewer slots than md5. Probably not some textures are just identical but used in different fasions.
Even the number consisting of 8 hexadecimal characters have quite a huge range of values, so its unlikely, but unfortunately probable. I haven't analyzed that hash calculating function, so I cannot exclude that scenario.
[quote="andysonofbob"][quote="DarkStarSword"]I worked out the pattern to fix the shadows, so this game is now looking very promising :)[/quote]
You might already be doing this but would it be possible to document these patterns somewhere please? Kinda like issue type e.g. halo; then common patterns and examples of what to look for and how to change to fix them?
Bo3b, Helifax and your good self have often just shown the pattern, then demonstrated the method required to fix or tweak. You all have also added brief comments to the code that explain in simple terms what the added lines do; this is also helpful even if it is just drawing attention to the line of code!
Anyhoo - thanks![/quote]
We haven't gotten to documenting this sort of deeper level stuff. It was my plan to do that in a next set of ShaderHacker courses, but haven't been able to get to it. It's fairly time consuming to make clear material, so it's an opportunity cost.
The first few are pretty straightforward, halos, skybox, HUD. Shadows are the most interesting part, and the best documentation we have is DarkStarSword's comments as a great spot to start.
[url]https://forums.geforce.com/default/topic/766890/3d-vision/bo3bs-school-for-shaderhackers/post/4715553/#4715553[/url]
DarkStarSword said:I worked out the pattern to fix the shadows, so this game is now looking very promising :)
You might already be doing this but would it be possible to document these patterns somewhere please? Kinda like issue type e.g. halo; then common patterns and examples of what to look for and how to change to fix them?
Bo3b, Helifax and your good self have often just shown the pattern, then demonstrated the method required to fix or tweak. You all have also added brief comments to the code that explain in simple terms what the added lines do; this is also helpful even if it is just drawing attention to the line of code!
Anyhoo - thanks!
We haven't gotten to documenting this sort of deeper level stuff. It was my plan to do that in a next set of ShaderHacker courses, but haven't been able to get to it. It's fairly time consuming to make clear material, so it's an opportunity cost.
The first few are pretty straightforward, halos, skybox, HUD. Shadows are the most interesting part, and the best documentation we have is DarkStarSword's comments as a great spot to start.
[quote="Oomek"][quote="Flugan"]I wonder if there are hash collitions as crc has fewer slots than md5. Probably not some textures are just identical but used in different fasions.[/quote] Even the number consisting of 8 hexadecimal characters have quite a huge range of values, so its unlikely, but unfortunately probable. I haven't analyzed that hash calculating function, so I cannot exclude that scenario.[/quote]
Before switching to crc32c, I analyzed this is depth using two games, including GTA5 where the old function was a measurable performance bottleneck. 200,000 some textures.
I put in special debug code (still in code history on GitHub), to look specifically for collisions. The only ones that collided were 'empty' type hashes, things that did not include rectangles, or were otherwise missing header information, and ones that were the same patterns, like all grey, all black.
I also did the inverse experiment to build confidence, which was to run the same test code against the old fnv_64 crc, and I got essentially the same results as viewed with WinMerge compare. Numerous sort of 'junk' collisions, no real collisions.
I also researched how the function distributes its values, and found a great website that tested the distribution. You will read a bunch of rubbish on the net about how crc32 is not well distributed- from people who didn't actually try any experiments. crc32c in particular is well distributed over the 32 bit space.
We naturally cannot rule out collisions, but in my judgment this is definitely not probable.
Flugan said:I wonder if there are hash collitions as crc has fewer slots than md5. Probably not some textures are just identical but used in different fasions.
Even the number consisting of 8 hexadecimal characters have quite a huge range of values, so its unlikely, but unfortunately probable. I haven't analyzed that hash calculating function, so I cannot exclude that scenario.
Before switching to crc32c, I analyzed this is depth using two games, including GTA5 where the old function was a measurable performance bottleneck. 200,000 some textures.
I put in special debug code (still in code history on GitHub), to look specifically for collisions. The only ones that collided were 'empty' type hashes, things that did not include rectangles, or were otherwise missing header information, and ones that were the same patterns, like all grey, all black.
I also did the inverse experiment to build confidence, which was to run the same test code against the old fnv_64 crc, and I got essentially the same results as viewed with WinMerge compare. Numerous sort of 'junk' collisions, no real collisions.
I also researched how the function distributes its values, and found a great website that tested the distribution. You will read a bunch of rubbish on the net about how crc32 is not well distributed- from people who didn't actually try any experiments. crc32c in particular is well distributed over the 32 bit space.
We naturally cannot rule out collisions, but in my judgment this is definitely not probable.
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
@Flugan, since you were asking about it while I was debugging problems on Windows 10 I migrated 3DMigoto to the VS2015 tool chain and the Windows 10 SDK (the Win 8 SDK was giving me trouble on Win10, and this one is bundled with VS2015). It's in the vs2015 topic branch if you wanted to try it out.
Notably the decompiler was failing on a bunch of shaders in MGSVGZ that were working fine when built with VS2013 + Win8 SDK, so until that is resolved (and if all developers are happy to migrate and it's undergone a lot more thorough testing) it won't be merged into master, but it might be something you can use to at least compile it for yourself.
You can always merge updates from master into the topic branch (or rebase it on master after updates with the usual warnings about rebasing anything that has been made public that other people might have based work on), and cherry pick individual commits from the topic branch back into master.
@Flugan, since you were asking about it while I was debugging problems on Windows 10 I migrated 3DMigoto to the VS2015 tool chain and the Windows 10 SDK (the Win 8 SDK was giving me trouble on Win10, and this one is bundled with VS2015). It's in the vs2015 topic branch if you wanted to try it out.
Notably the decompiler was failing on a bunch of shaders in MGSVGZ that were working fine when built with VS2013 + Win8 SDK, so until that is resolved (and if all developers are happy to migrate and it's undergone a lot more thorough testing) it won't be merged into master, but it might be something you can use to at least compile it for yourself.
You can always merge updates from master into the topic branch (or rebase it on master after updates with the usual warnings about rebasing anything that has been made public that other people might have based work on), and cherry pick individual commits from the topic branch back into master.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
[quote="bo3b"][quote="andysonofbob"][quote="DarkStarSword"]I worked out the pattern to fix the shadows, so this game is now looking very promising :)[/quote]
You might already be doing this but would it be possible to document these patterns somewhere please? Kinda like issue type e.g. halo; then common patterns and examples of what to look for and how to change to fix them?
Bo3b, Helifax and your good self have often just shown the pattern, then demonstrated the method required to fix or tweak. You all have also added brief comments to the code that explain in simple terms what the added lines do; this is also helpful even if it is just drawing attention to the line of code!
Anyhoo - thanks![/quote]
We haven't gotten to documenting this sort of deeper level stuff. It was my plan to do that in a next set of ShaderHacker courses, but haven't been able to get to it. It's fairly time consuming to make clear material, so it's an opportunity cost.
The first few are pretty straightforward, halos, skybox, HUD. Shadows are the most interesting part, and the best documentation we have is DarkStarSword's comments as a great spot to start.
[url]https://forums.geforce.com/default/topic/766890/3d-vision/bo3bs-school-for-shaderhackers/post/4715553/#4715553[/url][/quote]
I've been meaning to check in with you on this actually - I've got a bunch of examples for fixing all sorts of effects and variations in my git history that I can dig up and it might be nice to add a page on the wiki linking to these. Is this the type of thing you would like to see on the 'List of Glitches' page (which I don't have edit access for currently)? Probably with sub-pages for each effect if there are multiple examples/variations. Alternatively I see you already grabbed some of the examples I posted, so I could expand that page:
http://wiki.bo3b.net/index.php?title=DarkStarSword_example_fixes
DarkStarSword said:I worked out the pattern to fix the shadows, so this game is now looking very promising :)
You might already be doing this but would it be possible to document these patterns somewhere please? Kinda like issue type e.g. halo; then common patterns and examples of what to look for and how to change to fix them?
Bo3b, Helifax and your good self have often just shown the pattern, then demonstrated the method required to fix or tweak. You all have also added brief comments to the code that explain in simple terms what the added lines do; this is also helpful even if it is just drawing attention to the line of code!
Anyhoo - thanks!
We haven't gotten to documenting this sort of deeper level stuff. It was my plan to do that in a next set of ShaderHacker courses, but haven't been able to get to it. It's fairly time consuming to make clear material, so it's an opportunity cost.
The first few are pretty straightforward, halos, skybox, HUD. Shadows are the most interesting part, and the best documentation we have is DarkStarSword's comments as a great spot to start.
I've been meaning to check in with you on this actually - I've got a bunch of examples for fixing all sorts of effects and variations in my git history that I can dig up and it might be nice to add a page on the wiki linking to these. Is this the type of thing you would like to see on the 'List of Glitches' page (which I don't have edit access for currently)? Probably with sub-pages for each effect if there are multiple examples/variations. Alternatively I see you already grabbed some of the examples I posted, so I could expand that page:
[quote="DarkStarSword"][quote="bo3b"][quote="andysonofbob"][quote="DarkStarSword"]I worked out the pattern to fix the shadows, so this game is now looking very promising :)[/quote]
You might already be doing this but would it be possible to document these patterns somewhere please? Kinda like issue type e.g. halo; then common patterns and examples of what to look for and how to change to fix them?
Bo3b, Helifax and your good self have often just shown the pattern, then demonstrated the method required to fix or tweak. You all have also added brief comments to the code that explain in simple terms what the added lines do; this is also helpful even if it is just drawing attention to the line of code!
Anyhoo - thanks![/quote]
We haven't gotten to documenting this sort of deeper level stuff. It was my plan to do that in a next set of ShaderHacker courses, but haven't been able to get to it. It's fairly time consuming to make clear material, so it's an opportunity cost.
The first few are pretty straightforward, halos, skybox, HUD. Shadows are the most interesting part, and the best documentation we have is DarkStarSword's comments as a great spot to start.
[url]https://forums.geforce.com/default/topic/766890/3d-vision/bo3bs-school-for-shaderhackers/post/4715553/#4715553[/url][/quote]
I've been meaning to check in with you on this actually - I've got a bunch of examples for fixing all sorts of effects and variations in my git history that I can dig up and it might be nice to add a page on the wiki linking to these. Is this the type of thing you would like to see on the 'List of Glitches' page (which I don't have edit access for currently)? Probably with sub-pages for each effect if there are multiple examples/variations. Alternatively I see you already grabbed some of the examples I posted, so I could expand that page:
http://wiki.bo3b.net/index.php?title=DarkStarSword_example_fixes[/quote]
Yep, if you wanted to make some sample pages, I'd say go for it. I've been saving off some stuff piecemeal, mostly for notes purposes when I'd get around to it.
A bunch of these pages are sort of placeholders, incomplete. I added you as an administrator, so you can edit them directly however.
If you want to edit List of glitches, that would be fine, or adding your own pages.
I can do the easy stuff, but shadows are still not my forte. And since shadows are nearly always the first thing people ask about, maybe you can take your notes and write up something for shadows? Anyway, anything you prefer works for me.
DarkStarSword said:I worked out the pattern to fix the shadows, so this game is now looking very promising :)
You might already be doing this but would it be possible to document these patterns somewhere please? Kinda like issue type e.g. halo; then common patterns and examples of what to look for and how to change to fix them?
Bo3b, Helifax and your good self have often just shown the pattern, then demonstrated the method required to fix or tweak. You all have also added brief comments to the code that explain in simple terms what the added lines do; this is also helpful even if it is just drawing attention to the line of code!
Anyhoo - thanks!
We haven't gotten to documenting this sort of deeper level stuff. It was my plan to do that in a next set of ShaderHacker courses, but haven't been able to get to it. It's fairly time consuming to make clear material, so it's an opportunity cost.
The first few are pretty straightforward, halos, skybox, HUD. Shadows are the most interesting part, and the best documentation we have is DarkStarSword's comments as a great spot to start.
I've been meaning to check in with you on this actually - I've got a bunch of examples for fixing all sorts of effects and variations in my git history that I can dig up and it might be nice to add a page on the wiki linking to these. Is this the type of thing you would like to see on the 'List of Glitches' page (which I don't have edit access for currently)? Probably with sub-pages for each effect if there are multiple examples/variations. Alternatively I see you already grabbed some of the examples I posted, so I could expand that page:
http://wiki.bo3b.net/index.php?title=DarkStarSword_example_fixes
Yep, if you wanted to make some sample pages, I'd say go for it. I've been saving off some stuff piecemeal, mostly for notes purposes when I'd get around to it.
A bunch of these pages are sort of placeholders, incomplete. I added you as an administrator, so you can edit them directly however.
If you want to edit List of glitches, that would be fine, or adding your own pages.
I can do the easy stuff, but shadows are still not my forte. And since shadows are nearly always the first thing people ask about, maybe you can take your notes and write up something for shadows? Anyway, anything you prefer works for me.
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
That is to be expected since it has to rehash the textures every time the game updates them, therefore it should only be enabled in games where it is needed. There isn't an easy answer with our current design - the only way to improve that is to not rehash textures that couldn't possibly be relevant. I could do that if we had separate description and content hashes and only rehash the contents if the description matches, but currently they are combined in a single hash so I can't know that answer until after I've spend the CPU cycles to hash the contents again. I might well make this change, but there's too many fixes using texture hashes so I'd need to do so in a way that doesn't break them.
That is to be expected since it has to rehash the textures every time the game updates them, therefore it should only be enabled in games where it is needed. There isn't an easy answer with our current design - the only way to improve that is to not rehash textures that couldn't possibly be relevant. I could do that if we had separate description and content hashes and only rehash the contents if the description matches, but currently they are combined in a single hash so I can't know that answer until after I've spend the CPU cycles to hash the contents again. I might well make this change, but there's too many fixes using texture hashes so I'd need to do so in a way that doesn't break them.
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
I'm not git savvy enough to collaborate with branches on git pushing and pulling commits.
If 2015 at one point is stable it could migrate to that platform.
Currently my goal is to get a working VS2013 environment as 400 errors is not good enough.
I havn't done much work on it yet but my guess is that much is due to missing paths.
I might have Win10 SDK and Win8.1 SDK but no Win8 or Win7 SDK I really havn't tested much yet.
The problem with the environment probably persists in the VS2015 test branch as 3DMigoto uses compiler46 while Flugan wrapper has always used compiler47 which is preloaded onto at least Win8.1 if not Win8.
What is the demand for ISGN and OSGN for assembler? It would be preferable to be able to compile 3DMigoto but not strictly necessary. At this point I have only done research but not started coding. It seems managable but string handling and string offsets needs to be taken care of in the binary blob.
I'm not git savvy enough to collaborate with branches on git pushing and pulling commits.
If 2015 at one point is stable it could migrate to that platform.
Currently my goal is to get a working VS2013 environment as 400 errors is not good enough.
I havn't done much work on it yet but my guess is that much is due to missing paths.
I might have Win10 SDK and Win8.1 SDK but no Win8 or Win7 SDK I really havn't tested much yet.
The problem with the environment probably persists in the VS2015 test branch as 3DMigoto uses compiler46 while Flugan wrapper has always used compiler47 which is preloaded onto at least Win8.1 if not Win8.
What is the demand for ISGN and OSGN for assembler? It would be preferable to be able to compile 3DMigoto but not strictly necessary. At this point I have only done research but not started coding. It seems managable but string handling and string offsets needs to be taken care of in the binary blob.
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?
[quote]What is the demand for ISGN and OSGN for assembler? It would be preferable to be able to compile 3DMigoto but not strictly necessary. At this point I have only done research but not started coding. It seems managable but string handling and string offsets needs to be taken care of in the binary blob.[/quote]It's not a huge demand yet - so far whenever we have needed to add additional inputs & outputs we have been able to use HLSL shaders. I did want this for autofixes where I don't want to have to trust the decompiler for shaders that I have not personally verified (plus the assembler is a *lot* faster than the compiler), but that was mostly for the view-space style Unity lighting fix where I pass the FOV that is derived, copied or hardcoded (depending on what effects are enabled in the game at that moment) in the vertex shader to the pixel shaders - the new world-space version of the fix doesn't pass values like that so I won't need it there.
Besides which, I still need to port shadertool to DX11 before I can even think about doing any of those autofixes on the assembly shaders (I've written hlsltool, but seeing how many small differences show up thanks to the decompiler does not inspire me with much confidence to use it to implement the new-style Unity autofix given just how many shaders that adjusts (many thousands), though I may still do that in the short term to see how it goes).
What is the demand for ISGN and OSGN for assembler? It would be preferable to be able to compile 3DMigoto but not strictly necessary. At this point I have only done research but not started coding. It seems managable but string handling and string offsets needs to be taken care of in the binary blob.
It's not a huge demand yet - so far whenever we have needed to add additional inputs & outputs we have been able to use HLSL shaders. I did want this for autofixes where I don't want to have to trust the decompiler for shaders that I have not personally verified (plus the assembler is a *lot* faster than the compiler), but that was mostly for the view-space style Unity lighting fix where I pass the FOV that is derived, copied or hardcoded (depending on what effects are enabled in the game at that moment) in the vertex shader to the pixel shaders - the new world-space version of the fix doesn't pass values like that so I won't need it there.
Besides which, I still need to port shadertool to DX11 before I can even think about doing any of those autofixes on the assembly shaders (I've written hlsltool, but seeing how many small differences show up thanks to the decompiler does not inspire me with much confidence to use it to implement the new-style Unity autofix given just how many shaders that adjusts (many thousands), though I may still do that in the short term to see how it goes).
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
Bug report:
I finally found the reason why 3DM sometimes crashes the game during hunting.
The cause was simply some Polish unicode characters I used in the first comented line like: ąęśćżłóń
I finally found the reason why 3DM sometimes crashes the game during hunting.
The cause was simply some Polish unicode characters I used in the first comented line like: ąęśćżłóń
Tell me one thing please.
is there any performance impact when copying large constant buffers between shaders or they are only pointers to the same location?
Tell me one thing please.
is there any performance impact when copying large constant buffers between shaders or they are only pointers to the same location?
You might already be doing this but would it be possible to document these patterns somewhere please? Kinda like issue type e.g. halo; then common patterns and examples of what to look for and how to change to fix them?
Bo3b, Helifax and your good self have often just shown the pattern, then demonstrated the method required to fix or tweak. You all have also added brief comments to the code that explain in simple terms what the added lines do; this is also helpful even if it is just drawing attention to the line of code!
Anyhoo - thanks!
Lord, grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference.-------------------Vitals: Windows 10 64bit, Ryzen 5 2600x, GTX 1070, 16GB, 3D Vision, CV1
Handy Driver DiscussionHelix Mod - community fixes Bo3b's Shaderhacker School - How to fix 3D in games3dsolutionsgaming.com - videos, reviews and 3D fixes
It's weird you know. Sometimes one hash is bound to just one texture, sometimes to few of them. I'll try what you suggested.
I've aloso got one trick left up my sleeve. Since i've got an alpha channel free i can use it as a brightness modifier. It will be necessary though to edit all the textures i'm after, so I'll do it if other methods fail.
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
We haven't gotten to documenting this sort of deeper level stuff. It was my plan to do that in a next set of ShaderHacker courses, but haven't been able to get to it. It's fairly time consuming to make clear material, so it's an opportunity cost.
The first few are pretty straightforward, halos, skybox, HUD. Shadows are the most interesting part, and the best documentation we have is DarkStarSword's comments as a great spot to start.
https://forums.geforce.com/default/topic/766890/3d-vision/bo3bs-school-for-shaderhackers/post/4715553/#4715553
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
Before switching to crc32c, I analyzed this is depth using two games, including GTA5 where the old function was a measurable performance bottleneck. 200,000 some textures.
I put in special debug code (still in code history on GitHub), to look specifically for collisions. The only ones that collided were 'empty' type hashes, things that did not include rectangles, or were otherwise missing header information, and ones that were the same patterns, like all grey, all black.
I also did the inverse experiment to build confidence, which was to run the same test code against the old fnv_64 crc, and I got essentially the same results as viewed with WinMerge compare. Numerous sort of 'junk' collisions, no real collisions.
I also researched how the function distributes its values, and found a great website that tested the distribution. You will read a bunch of rubbish on the net about how crc32 is not well distributed- from people who didn't actually try any experiments. crc32c in particular is well distributed over the 32 bit space.
We naturally cannot rule out collisions, but in my judgment this is definitely not probable.
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
Notably the decompiler was failing on a bunch of shaders in MGSVGZ that were working fine when built with VS2013 + Win8 SDK, so until that is resolved (and if all developers are happy to migrate and it's undergone a lot more thorough testing) it won't be merged into master, but it might be something you can use to at least compile it for yourself.
You can always merge updates from master into the topic branch (or rebase it on master after updates with the usual warnings about rebasing anything that has been made public that other people might have based work on), and cherry pick individual commits from the topic branch back into master.
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
I've been meaning to check in with you on this actually - I've got a bunch of examples for fixing all sorts of effects and variations in my git history that I can dig up and it might be nice to add a page on the wiki linking to these. Is this the type of thing you would like to see on the 'List of Glitches' page (which I don't have edit access for currently)? Probably with sub-pages for each effect if there are multiple examples/variations. Alternatively I see you already grabbed some of the examples I posted, so I could expand that page:
http://wiki.bo3b.net/index.php?title=DarkStarSword_example_fixes
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
Yep, if you wanted to make some sample pages, I'd say go for it. I've been saving off some stuff piecemeal, mostly for notes purposes when I'd get around to it.
A bunch of these pages are sort of placeholders, incomplete. I added you as an administrator, so you can edit them directly however.
If you want to edit List of glitches, that would be fine, or adding your own pages.
I can do the easy stuff, but shadows are still not my forte. And since shadows are nearly always the first thing people ask about, maybe you can take your notes and write up something for shadows? Anyway, anything you prefer works for me.
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
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
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
If 2015 at one point is stable it could migrate to that platform.
Currently my goal is to get a working VS2013 environment as 400 errors is not good enough.
I havn't done much work on it yet but my guess is that much is due to missing paths.
I might have Win10 SDK and Win8.1 SDK but no Win8 or Win7 SDK I really havn't tested much yet.
The problem with the environment probably persists in the VS2015 test branch as 3DMigoto uses compiler46 while Flugan wrapper has always used compiler47 which is preloaded onto at least Win8.1 if not Win8.
What is the demand for ISGN and OSGN for assembler? It would be preferable to be able to compile 3DMigoto but not strictly necessary. At this point I have only done research but not started coding. It seems managable but string handling and string offsets needs to be taken care of in the binary blob.
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
Besides which, I still need to port shadertool to DX11 before I can even think about doing any of those autofixes on the assembly shaders (I've written hlsltool, but seeing how many small differences show up thanks to the decompiler does not inspire me with much confidence to use it to implement the new-style Unity autofix given just how many shaders that adjusts (many thousands), though I may still do that in the short term to see how it goes).
2x Geforce GTX 980 in SLI provided by NVIDIA, i7 6700K 4GHz CPU, Asus 27" VG278HE 144Hz 3D Monitor, BenQ W1070 3D Projector, 120" Elite Screens YardMaster 2, 32GB Corsair DDR4 3200MHz RAM, Samsung 850 EVO 500G SSD, 4x750GB HDD in RAID5, Gigabyte Z170X-Gaming 7 Motherboard, Corsair Obsidian 750D Airflow Edition Case, Corsair RM850i PSU, HTC Vive, Win 10 64bit
Alienware M17x R4 w/ built in 3D, Intel i7 3740QM, GTX 680m 2GB, 16GB DDR3 1600MHz RAM, Win7 64bit, 1TB SSD, 1TB HDD, 750GB HDD
Pre-release 3D fixes, shadertool.py and other goodies: http://github.com/DarkStarSword/3d-fixes
Support me on Patreon: https://www.patreon.com/DarkStarSword or PayPal: https://www.paypal.me/DarkStarSword
I finally found the reason why 3DM sometimes crashes the game during hunting.
The cause was simply some Polish unicode characters I used in the first comented line like: ąęśćżłóń
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64
is there any performance impact when copying large constant buffers between shaders or they are only pointers to the same location?
EVGA GeForce GTX 980 SC
Core i5 2500K
MSI Z77A-G45
8GB DDR3
Windows 10 x64