Since I have no idea what an actual fix would be I've been toying around with other values available in d3dx.ini
putting those shaders at fixed convergence like 0 makes the ground not so floaty but the right / left images are so far away from each other it hurts the eyes ;p using separation doesnt seem to help either nor the mix of the two...
I think that this ground shader is really fucked up :D
Since I have no idea what an actual fix would be I've been toying around with other values available in d3dx.ini
putting those shaders at fixed convergence like 0 makes the ground not so floaty but the right / left images are so far away from each other it hurts the eyes ;p using separation doesnt seem to help either nor the mix of the two...
I think that this ground shader is really fucked up :D
so out of curiosity I've tried to dump all the VS that are available once I load a map, out of 43 only 13 are done with high pitch sound meaning no error all the rest gives back low pitch sound...
looking at the log file there seem to be those CB'x' parameters occurring in all cases.
etc... those are just few but all that failed have starts with CB
Im able to disable all those that are fine easily with 'zeroing' whatever is associated with the
SV_Position0.
regardless of if they generate an error or not Im able to disable all by adding them in d3dx.ini tho still im I ever would like to have a 'fix' it cant be related to simply disabling the shader as its the ground that is broken...
OK, cool, you are off to a good start on fixing the ground. Just for reference since you are new to it, it is often this confusing and bizarre and 1/3 busted. That's normal for games where we haven't looked at the game engine before.
Right at the moment, you are seeing Decompiler issues with that PS. Basically the HLSL representation is generated wrong, so the code won't actually compile. This is regrettable, but the Decompilation of assembly is a hard problem. It's getting better over time as I fix bugs, but this sort of thing is going to happen.
For this one, let me take a look at doing a hand fix for it, as the key shader you need. This technique is me looking at the code and understanding what broke, and providing a hand-built version that will work. This helps me fix the bug in the Decompiler, because I get to see what went wrong.
I think the PS is the right spot to disable the ground effect, so let me see if I can build a hand-fixed shader for you.
The fundamental part of the hacking is to experiment. So, in this case for example, I suggested disabling all three outputs. It might be that we can disable just a single piece of that (like o1 or o2) instead of the whole thing.
I don't quite understand the floating ground problem based on some of your screenshots, so if it's some sort of decal, this disable will work. If it's the entire ground, we'll need something else, something more complicated probably (like Mike's Total War floating ground fix).
Edit: So what happened here is the SHLight variable is fully initialized in the code, and the Decompiler doesn't presently know how to handle that giant array initializer. This is bad because I can't just do a couple of tweaks and get it compiling, it missed every variable from there on, which is too many to do by hand (all offsets need to be calculated).
So... I can add this initializer handler, which will take me several days, or you can try the ASM version of the file instead, since we support that too. Dump the ASM file, and drop it into the ShaderFixes folder by itself, and then you can experiment on that. Very much like the original HelixMod instructions, you set outputs to zero constants, different syntax.
OK, cool, you are off to a good start on fixing the ground. Just for reference since you are new to it, it is often this confusing and bizarre and 1/3 busted. That's normal for games where we haven't looked at the game engine before.
Right at the moment, you are seeing Decompiler issues with that PS. Basically the HLSL representation is generated wrong, so the code won't actually compile. This is regrettable, but the Decompilation of assembly is a hard problem. It's getting better over time as I fix bugs, but this sort of thing is going to happen.
For this one, let me take a look at doing a hand fix for it, as the key shader you need. This technique is me looking at the code and understanding what broke, and providing a hand-built version that will work. This helps me fix the bug in the Decompiler, because I get to see what went wrong.
I think the PS is the right spot to disable the ground effect, so let me see if I can build a hand-fixed shader for you.
The fundamental part of the hacking is to experiment. So, in this case for example, I suggested disabling all three outputs. It might be that we can disable just a single piece of that (like o1 or o2) instead of the whole thing.
I don't quite understand the floating ground problem based on some of your screenshots, so if it's some sort of decal, this disable will work. If it's the entire ground, we'll need something else, something more complicated probably (like Mike's Total War floating ground fix).
Edit: So what happened here is the SHLight variable is fully initialized in the code, and the Decompiler doesn't presently know how to handle that giant array initializer. This is bad because I can't just do a couple of tweaks and get it compiling, it missed every variable from there on, which is too many to do by hand (all offsets need to be calculated).
So... I can add this initializer handler, which will take me several days, or you can try the ASM version of the file instead, since we support that too. Dump the ASM file, and drop it into the ShaderFixes folder by itself, and then you can experiment on that. Very much like the original HelixMod instructions, you set outputs to zero constants, different syntax.
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
Im afraid the ground is a more complex problem as was Mike's TW fix, the floating ground is probably not the most accurate thing you could say its more as if everything thats on the ground appear to be floating over it.
this is the ground using CM mode where it renders somewhat properly
http://photos.3dvisionlive.com/tehace/image/56486300e7e5648557000070/
and here is with the real3d where it appears to not be on the same plane as the rest of the objects
http://photos.3dvisionlive.com/tehace/image/564862dee7e5642266000258/
some of those screenshots I have in this album http://photos.3dvisionlive.com/tehace/album/51798ae65ec346375a000049/ have the ground rendered properly but it must have been changed at some point as I've checked the exact same spots on the same map and its broken. I've also tried different settings to see if that has any effect but it didnt. I remember some of the maps (very few) were rendered correctly so it was my first guess to try and find those, dump the ground shaders from them and compare them to those that render incorrectly but I havent found any map that render the ground properly now...
Im sorry but I dont even have an idea what ASM is... google found me this https://github.com/bo3b/3Dmigoto/issues/28 but all I understand from it is that ASM is different than HLSL ;)
Also found some ASM mentions within 3dmigoto going open source topic, but it doesnt enlighten me much aside from the fact that its possible :( Flugan also already added his Assembler to the project, and we are going to hook it up shortly. This is significant because we could not previously Assemble the ASM version of shaders, we could only do the HLSL.
+ this http://reshade.me/forum/suggestions/474-helix-3dmigoto-compat-shader-tex-dump-injection
I think that I'm able to follow specific instructions and than play around with things once they work, other than that I feel like im rather useless.
Im afraid the ground is a more complex problem as was Mike's TW fix, the floating ground is probably not the most accurate thing you could say its more as if everything thats on the ground appear to be floating over it.
some of those screenshots I have in this album http://photos.3dvisionlive.com/tehace/album/51798ae65ec346375a000049/ have the ground rendered properly but it must have been changed at some point as I've checked the exact same spots on the same map and its broken. I've also tried different settings to see if that has any effect but it didnt. I remember some of the maps (very few) were rendered correctly so it was my first guess to try and find those, dump the ground shaders from them and compare them to those that render incorrectly but I havent found any map that render the ground properly now...
Im sorry but I dont even have an idea what ASM is... google found me this https://github.com/bo3b/3Dmigoto/issues/28 but all I understand from it is that ASM is different than HLSL ;)
Also found some ASM mentions within 3dmigoto going open source topic, but it doesnt enlighten me much aside from the fact that its possible :( Flugan also already added his Assembler to the project, and we are going to hook it up shortly. This is significant because we could not previously Assemble the ASM version of shaders, we could only do the HLSL.
@tehace, for the ground you can try using others settings if make things better...changing AA, even test without AA, also other settings for the ground quality, tesselation (if the game have), texture quality..... that ground looks really strange.
@tehace, for the ground you can try using others settings if make things better...changing AA, even test without AA, also other settings for the ground quality, tesselation (if the game have), texture quality..... that ground looks really strange.
[quote="tehace"]Im afraid the ground is a more complex problem as was Mike's TW fix, the floating ground is probably not the most accurate thing you could say its more as if everything thats on the ground appear to be floating over it.
this is the ground using CM mode where it renders somewhat properly
http://photos.3dvisionlive.com/tehace/image/56486300e7e5648557000070/
and here is with the real3d where it appears to not be on the same plane as the rest of the objects
http://photos.3dvisionlive.com/tehace/image/564862dee7e5642266000258/
some of those screenshots I have in this album http://photos.3dvisionlive.com/tehace/album/51798ae65ec346375a000049/ have the ground rendered properly but it must have been changed at some point as I've checked the exact same spots on the same map and its broken. I've also tried different settings to see if that has any effect but it didnt. I remember some of the maps (very few) were rendered correctly so it was my first guess to try and find those, dump the ground shaders from them and compare them to those that render incorrectly but I havent found any map that render the ground properly now...
Im sorry but I dont even have an idea what ASM is... google found me this https://github.com/bo3b/3Dmigoto/issues/28 but all I understand from it is that ASM is different than HLSL ;)
Also found some ASM mentions within 3dmigoto going open source topic, but it doesnt enlighten me much aside from the fact that its possible :( Flugan also already added his Assembler to the project, and we are going to hook it up shortly. This is significant because we could not previously Assemble the ASM version of shaders, we could only do the HLSL.
+ this http://reshade.me/forum/suggestions/474-helix-3dmigoto-compat-shader-tex-dump-injection
I think that I'm able to follow specific instructions and than play around with things once they work, other than that I feel like im rather useless. [/quote]
Ah, I was wondering why sometimes it looked OK and sometimes not. Is it possible to reverse the problem? In other words, move the objects down to the ground, instead of moving the ground up? Hard to say though because they seem like they are in the right spot relative to the depth, just wrong height. Like x axis is fine, but z axis is wrong.
For the lack of understanding the pieces- this is why you need to go through the wiki.bo3b.net lessons, and actually do the lessons, not skim them. I promise that after doing the lessons you will understand all of these pieces, including the ASM.
You are currently trying to run before you walk, and one of my main reasons for putting the effort into those lessons is so that we can all use the same vocabulary, have the same background. That way we also don't have to keep repeating ourselves.
tehace said:Im afraid the ground is a more complex problem as was Mike's TW fix, the floating ground is probably not the most accurate thing you could say its more as if everything thats on the ground appear to be floating over it.
some of those screenshots I have in this album http://photos.3dvisionlive.com/tehace/album/51798ae65ec346375a000049/ have the ground rendered properly but it must have been changed at some point as I've checked the exact same spots on the same map and its broken. I've also tried different settings to see if that has any effect but it didnt. I remember some of the maps (very few) were rendered correctly so it was my first guess to try and find those, dump the ground shaders from them and compare them to those that render incorrectly but I havent found any map that render the ground properly now...
Im sorry but I dont even have an idea what ASM is... google found me this https://github.com/bo3b/3Dmigoto/issues/28 but all I understand from it is that ASM is different than HLSL ;)
Also found some ASM mentions within 3dmigoto going open source topic, but it doesnt enlighten me much aside from the fact that its possible :( Flugan also already added his Assembler to the project, and we are going to hook it up shortly. This is significant because we could not previously Assemble the ASM version of shaders, we could only do the HLSL.
I think that I'm able to follow specific instructions and than play around with things once they work, other than that I feel like im rather useless.
Ah, I was wondering why sometimes it looked OK and sometimes not. Is it possible to reverse the problem? In other words, move the objects down to the ground, instead of moving the ground up? Hard to say though because they seem like they are in the right spot relative to the depth, just wrong height. Like x axis is fine, but z axis is wrong.
For the lack of understanding the pieces- this is why you need to go through the wiki.bo3b.net lessons, and actually do the lessons, not skim them. I promise that after doing the lessons you will understand all of these pieces, including the ASM.
You are currently trying to run before you walk, and one of my main reasons for putting the effort into those lessons is so that we can all use the same vocabulary, have the same background. That way we also don't have to keep repeating ourselves.
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
@bo3b ok I'll try to do that over the week. All the other objects seem to be rendered properly and if you disable the shadows in the config file the game would be 100% in playable state if it wasnt for the messed up ground, in COH1 it was all fine with the right profile.
@daspawn yeah, thanks. I guess it was probably already mentioned but unfortunately my setup does not support tridef.
@DHR I have edited the lua config to have everything on low/off and it doesnt influence how the ground is rendered.
Not sure if this is important but if you look at the CM mode (which actually look decent up to a point)
http://photos.3dvisionlive.com/tehace/image/5649e6f8e7e5641220000028/
it seem that everything is rendered in 2d to a certain height, on that screenshot up to the point where the buildings with the numbers 60 50 70 are - its just plain field and this 'viewport' is always rendered that way. Than over this the rest seem to be rendered really well in fake3d.
or here right where the soldiers are standing in the middle of the base
http://photos.3dvisionlive.com/tehace/image/5649e901e7e564d74000002d/
or here the bigger tree near is also that 'flat'
http://photos.3dvisionlive.com/tehace/image/5649e932e7e564c34a00002e/
while here its the same tree that looks good when moved out
http://photos.3dvisionlive.com/tehace/image/5649e922e7e564643b000020/
but now the farm looks 'flat' and so on.
I seemed to be able to break this with the result like this
http://photos.3dvisionlive.com/tehace/image/5645e312e7e564880d00027e/
but I doeesnt seem to be able to reproduce it I have no idea what I did and it only happened once for me.
@bo3b ok I'll try to do that over the week. All the other objects seem to be rendered properly and if you disable the shadows in the config file the game would be 100% in playable state if it wasnt for the messed up ground, in COH1 it was all fine with the right profile.
@daspawn yeah, thanks. I guess it was probably already mentioned but unfortunately my setup does not support tridef.
@DHR I have edited the lua config to have everything on low/off and it doesnt influence how the ground is rendered.
it seem that everything is rendered in 2d to a certain height, on that screenshot up to the point where the buildings with the numbers 60 50 70 are - its just plain field and this 'viewport' is always rendered that way. Than over this the rest seem to be rendered really well in fake3d.
here is the code in question I guess I could not have chosen a worse start lol
Hi - I looked at this and the VS you posted and this looks like a common pattern. I have not tried it, so I might be wrong, but what is going on is the VS is sending out the World coord in o3, then it's being used in the PS in the variable v3, in particular it is being multiplied by one of the shadow matrices cb0[73-75]. This will be wrong. So the variable v3 needs correcting. I put some code below in the PS, but to be honest its probably better to fix it in the VS as the same VS will probably feed several PS.
Let me know if this does anything. Oh, yeah, and there are some errors in the HLSL, the header information is chopped off.
r0.xy = v3.xz; //From the VS, v3 is the WORLD COORD. But this shader is in stereo space, so the World Coord will be wrong. So we need to fix it.
r0.z = 1;
Yes, at the moment, the Decompiler is choking on that big array initializer. So, the remaining parts are lost. Only way to fix this shader at the moment is to use the Assembler.
Should be possible to use Mike's suggestion, but insert that as Assembly code instead.
Yes, at the moment, the Decompiler is choking on that big array initializer. So, the remaining parts are lost. Only way to fix this shader at the moment is to use the Assembler.
Should be possible to use Mike's suggestion, but insert that as Assembly code instead.
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
I feel a bit stupid but I have no idea what do you mean by 'but insert that as Assembly code instead'. I still havent gone trough all of your lessons so im most likely missing some information to be able to process that properly.
I did put that code in the PS for the ground and I dont seem to be having any errors when loading that shader (d3d11_log.txt seem to be free of errors). Unfortunately the ground is still rendered as it was.
I've tried
[code]r20.x += stereo.x*(r20.w - stereo.y);[/code]
but with error [code]F:\SteamLibrary\steamapps\common\Company of Heroes 2\wrapper1349(19,14-59): error X3017: cannot implicitly convert from 'const float4' to 'const float4[7]'[/code]
Than when I try to change it back to -= and reload the shaders it gives me the same error.
At one point I had the nvapi_log.txt containing
[code]Tue Nov 17 16:28:34 2015
- Stereo_CreateHandleFromIUnknown called with device = 066447A8. Result = 0
Tue Nov 17 16:28:35 2015
- Stereo_CreateHandleFromIUnknown called with device = 1CFFF820. Result = 0
Tue Nov 17 16:29:42 2015
- GetSeparation value=8.000000e+001, hex=42a00000
Tue Nov 17 16:29:42 2015
- GetConvergence value=3.823647e+001, hex=4218f224[/code]
but after im starting to get the errors in d3d11_log the nvapi log is 0bytes. Sorting files by date modified shows that shaderusage.txt is being modified but thats probably irrelevant.
I feel a bit stupid but I have no idea what do you mean by 'but insert that as Assembly code instead'. I still havent gone trough all of your lessons so im most likely missing some information to be able to process that properly.
I did put that code in the PS for the ground and I dont seem to be having any errors when loading that shader (d3d11_log.txt seem to be free of errors). Unfortunately the ground is still rendered as it was.
I've tried
r20.x += stereo.x*(r20.w - stereo.y);
but with error
F:\SteamLibrary\steamapps\common\Company of Heroes 2\wrapper1349(19,14-59): error X3017: cannot implicitly convert from 'const float4' to 'const float4[7]'
Than when I try to change it back to -= and reload the shaders it gives me the same error.
At one point I had the nvapi_log.txt containing
Tue Nov 17 16:28:34 2015
- Stereo_CreateHandleFromIUnknown called with device = 066447A8. Result = 0
Tue Nov 17 16:28:35 2015
- Stereo_CreateHandleFromIUnknown called with device = 1CFFF820. Result = 0
Tue Nov 17 16:29:42 2015
- GetSeparation value=8.000000e+001, hex=42a00000
Tue Nov 17 16:29:42 2015
- GetConvergence value=3.823647e+001, hex=4218f224
but after im starting to get the errors in d3d11_log the nvapi log is 0bytes. Sorting files by date modified shows that shaderusage.txt is being modified but thats probably irrelevant.
[quote="tehace"]I feel a bit stupid but I have no idea what do you mean by 'but insert that as Assembly code instead'. I still havent gone trough all of your lessons so im most likely missing some information to be able to process that properly.
[/quote]
Hi - no you are not being stupid, this just means that this game is more complicated to fix... The HLSL files you have been looking at are not being generated correctly, and so cannot be used to fix the problems. There is a separate set of files that can get created in assembly language (this is the same as helixmod uses) and this *can* be fixed. I will look at this for you and create a fix for the same shader that you provided in HLSL earlier.
At this point, it's come full circle to what I said originally - 3DMigoto has too many errors to fix the game effectively. HOWEVER, since I last looked at it, 3Dmigoto now has Flugan's assembly compiler, so that is now an option.
tehace said:I feel a bit stupid but I have no idea what do you mean by 'but insert that as Assembly code instead'. I still havent gone trough all of your lessons so im most likely missing some information to be able to process that properly.
Hi - no you are not being stupid, this just means that this game is more complicated to fix... The HLSL files you have been looking at are not being generated correctly, and so cannot be used to fix the problems. There is a separate set of files that can get created in assembly language (this is the same as helixmod uses) and this *can* be fixed. I will look at this for you and create a fix for the same shader that you provided in HLSL earlier.
At this point, it's come full circle to what I said originally - 3DMigoto has too many errors to fix the game effectively. HOWEVER, since I last looked at it, 3Dmigoto now has Flugan's assembly compiler, so that is now an option.
Ok its been a while so from what I understand I would have to wait for bo3b to fix somehting within 3dmigoto so it properly dump that ground shader. I dont really get how the other "assembly option" would work...
on a side note I have just recently picked up DA:I and Im really blown away on how good the game looks with the 3dfix provided by this community :) I really have no idea how could I go back to gaming on 'flat' screen
Ok its been a while so from what I understand I would have to wait for bo3b to fix somehting within 3dmigoto so it properly dump that ground shader. I dont really get how the other "assembly option" would work...
on a side note I have just recently picked up DA:I and Im really blown away on how good the game looks with the 3dfix provided by this community :) I really have no idea how could I go back to gaming on 'flat' screen
putting those shaders at fixed convergence like 0 makes the ground not so floaty but the right / left images are so far away from each other it hurts the eyes ;p using separation doesnt seem to help either nor the mix of the two...
I think that this ground shader is really fucked up :D
Acer H5360 / BenQ XL2420T + 3D Vision 2 Kit - EVGA GTX 980TI 6GB - i7-3930K@4.0GHz - DX79SI- 16GB RAM@2133 - Win10x64 Home - HTC VIVE
Acer H5360 / BenQ XL2420T + 3D Vision 2 Kit - EVGA GTX 980TI 6GB - i7-3930K@4.0GHz - DX79SI- 16GB RAM@2133 - Win10x64 Home - HTC VIVE
looking at the log file there seem to be those CB'x' parameters occurring in all cases.
etc... those are just few but all that failed have starts with CB
Im able to disable all those that are fine easily with 'zeroing' whatever is associated with the
SV_Position0.
regardless of if they generate an error or not Im able to disable all by adding them in d3dx.ini tho still im I ever would like to have a 'fix' it cant be related to simply disabling the shader as its the ground that is broken...
guess Im fucked with this one :D
Acer H5360 / BenQ XL2420T + 3D Vision 2 Kit - EVGA GTX 980TI 6GB - i7-3930K@4.0GHz - DX79SI- 16GB RAM@2133 - Win10x64 Home - HTC VIVE
Right at the moment, you are seeing Decompiler issues with that PS. Basically the HLSL representation is generated wrong, so the code won't actually compile. This is regrettable, but the Decompilation of assembly is a hard problem. It's getting better over time as I fix bugs, but this sort of thing is going to happen.
For this one, let me take a look at doing a hand fix for it, as the key shader you need. This technique is me looking at the code and understanding what broke, and providing a hand-built version that will work. This helps me fix the bug in the Decompiler, because I get to see what went wrong.
I think the PS is the right spot to disable the ground effect, so let me see if I can build a hand-fixed shader for you.
The fundamental part of the hacking is to experiment. So, in this case for example, I suggested disabling all three outputs. It might be that we can disable just a single piece of that (like o1 or o2) instead of the whole thing.
I don't quite understand the floating ground problem based on some of your screenshots, so if it's some sort of decal, this disable will work. If it's the entire ground, we'll need something else, something more complicated probably (like Mike's Total War floating ground fix).
Edit: So what happened here is the SHLight variable is fully initialized in the code, and the Decompiler doesn't presently know how to handle that giant array initializer. This is bad because I can't just do a couple of tweaks and get it compiling, it missed every variable from there on, which is too many to do by hand (all offsets need to be calculated).
So... I can add this initializer handler, which will take me several days, or you can try the ASM version of the file instead, since we support that too. Dump the ASM file, and drop it into the ShaderFixes folder by itself, and then you can experiment on that. Very much like the original HelixMod instructions, you set outputs to zero constants, different syntax.
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
this is the ground using CM mode where it renders somewhat properly
http://photos.3dvisionlive.com/tehace/image/56486300e7e5648557000070/
and here is with the real3d where it appears to not be on the same plane as the rest of the objects
http://photos.3dvisionlive.com/tehace/image/564862dee7e5642266000258/
some of those screenshots I have in this album http://photos.3dvisionlive.com/tehace/album/51798ae65ec346375a000049/ have the ground rendered properly but it must have been changed at some point as I've checked the exact same spots on the same map and its broken. I've also tried different settings to see if that has any effect but it didnt. I remember some of the maps (very few) were rendered correctly so it was my first guess to try and find those, dump the ground shaders from them and compare them to those that render incorrectly but I havent found any map that render the ground properly now...
Im sorry but I dont even have an idea what ASM is... google found me this https://github.com/bo3b/3Dmigoto/issues/28 but all I understand from it is that ASM is different than HLSL ;)
Also found some ASM mentions within 3dmigoto going open source topic, but it doesnt enlighten me much aside from the fact that its possible :( Flugan also already added his Assembler to the project, and we are going to hook it up shortly. This is significant because we could not previously Assemble the ASM version of shaders, we could only do the HLSL.
+ this http://reshade.me/forum/suggestions/474-helix-3dmigoto-compat-shader-tex-dump-injection
I think that I'm able to follow specific instructions and than play around with things once they work, other than that I feel like im rather useless.
Acer H5360 / BenQ XL2420T + 3D Vision 2 Kit - EVGA GTX 980TI 6GB - i7-3930K@4.0GHz - DX79SI- 16GB RAM@2133 - Win10x64 Home - HTC VIVE
MY WEB
Helix Mod - Making 3D Better
My 3D Screenshot Gallery
Like my fixes? you can donate to Paypal: dhr.donation@gmail.com
Ah, I was wondering why sometimes it looked OK and sometimes not. Is it possible to reverse the problem? In other words, move the objects down to the ground, instead of moving the ground up? Hard to say though because they seem like they are in the right spot relative to the depth, just wrong height. Like x axis is fine, but z axis is wrong.
For the lack of understanding the pieces- this is why you need to go through the wiki.bo3b.net lessons, and actually do the lessons, not skim them. I promise that after doing the lessons you will understand all of these pieces, including the ASM.
You are currently trying to run before you walk, and one of my main reasons for putting the effort into those lessons is so that we can all use the same vocabulary, have the same background. That way we also don't have to keep repeating ourselves.
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
@daspawn yeah, thanks. I guess it was probably already mentioned but unfortunately my setup does not support tridef.
@DHR I have edited the lua config to have everything on low/off and it doesnt influence how the ground is rendered.
Not sure if this is important but if you look at the CM mode (which actually look decent up to a point)
http://photos.3dvisionlive.com/tehace/image/5649e6f8e7e5641220000028/
it seem that everything is rendered in 2d to a certain height, on that screenshot up to the point where the buildings with the numbers 60 50 70 are - its just plain field and this 'viewport' is always rendered that way. Than over this the rest seem to be rendered really well in fake3d.
or here right where the soldiers are standing in the middle of the base
http://photos.3dvisionlive.com/tehace/image/5649e901e7e564d74000002d/
or here the bigger tree near is also that 'flat'
http://photos.3dvisionlive.com/tehace/image/5649e932e7e564c34a00002e/
while here its the same tree that looks good when moved out
http://photos.3dvisionlive.com/tehace/image/5649e922e7e564643b000020/
but now the farm looks 'flat' and so on.
I seemed to be able to break this with the result like this
http://photos.3dvisionlive.com/tehace/image/5645e312e7e564880d00027e/
but I doeesnt seem to be able to reproduce it I have no idea what I did and it only happened once for me.
Acer H5360 / BenQ XL2420T + 3D Vision 2 Kit - EVGA GTX 980TI 6GB - i7-3930K@4.0GHz - DX79SI- 16GB RAM@2133 - Win10x64 Home - HTC VIVE
Hi - I looked at this and the VS you posted and this looks like a common pattern. I have not tried it, so I might be wrong, but what is going on is the VS is sending out the World coord in o3, then it's being used in the PS in the variable v3, in particular it is being multiplied by one of the shadow matrices cb0[73-75]. This will be wrong. So the variable v3 needs correcting. I put some code below in the PS, but to be honest its probably better to fix it in the VS as the same VS will probably feed several PS.
Let me know if this does anything. Oh, yeah, and there are some errors in the HLSL, the header information is chopped off.
Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278
Should be possible to use Mike's suggestion, but insert that as Assembly code instead.
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
I did put that code in the PS for the ground and I dont seem to be having any errors when loading that shader (d3d11_log.txt seem to be free of errors). Unfortunately the ground is still rendered as it was.
I've tried
but with error
Than when I try to change it back to -= and reload the shaders it gives me the same error.
At one point I had the nvapi_log.txt containing
but after im starting to get the errors in d3d11_log the nvapi log is 0bytes. Sorting files by date modified shows that shaderusage.txt is being modified but thats probably irrelevant.
Acer H5360 / BenQ XL2420T + 3D Vision 2 Kit - EVGA GTX 980TI 6GB - i7-3930K@4.0GHz - DX79SI- 16GB RAM@2133 - Win10x64 Home - HTC VIVE
Hi - no you are not being stupid, this just means that this game is more complicated to fix... The HLSL files you have been looking at are not being generated correctly, and so cannot be used to fix the problems. There is a separate set of files that can get created in assembly language (this is the same as helixmod uses) and this *can* be fixed. I will look at this for you and create a fix for the same shader that you provided in HLSL earlier.
At this point, it's come full circle to what I said originally - 3DMigoto has too many errors to fix the game effectively. HOWEVER, since I last looked at it, 3Dmigoto now has Flugan's assembly compiler, so that is now an option.
Rig: Intel i7-8700K @4.7GHz, 16Gb Ram, SSD, GTX 1080Ti, Win10x64, Asus VG278
on a side note I have just recently picked up DA:I and Im really blown away on how good the game looks with the 3dfix provided by this community :) I really have no idea how could I go back to gaming on 'flat' screen
Acer H5360 / BenQ XL2420T + 3D Vision 2 Kit - EVGA GTX 980TI 6GB - i7-3930K@4.0GHz - DX79SI- 16GB RAM@2133 - Win10x64 Home - HTC VIVE