Welcome, Guest.
Username: Password: Remember me

TOPIC: 3.1

3.1 1 year 5 months ago #101

OtisInf wrote:
@thalixte: weird! I load your save file, but everything keeps on working here... No matter what angle I take, or where I move the player ... I also downgraded every gfx setting to 'low' as you suggested that the # of vertices dropped below a given threshold so I thought perhaps it's the gfx settings I have (everything maxed) but... nope 1920x1200... works like a charm. Will try other resolutions now but I don't know what triggers it on your part...

(edit) windowed mode, 1440x900 or so, no problem either... :/ very odd. ..

Will now install the photomode mod to see if I can reproduce it without gerhalt's ass in the way :)

(edit) I remembered I could just use Ansel and I can't reproduce it with that either. Flying around, like you in your video, same spot, using displaydepth, not a problem at all, right depth buffer is chosen every time, looking at a clear sky, all OK... really weird.

Ansel simply disables reshade effects. I use a TW3 mod (PhotoMode 2inOne for Debug Console Enabler) to enable the flight mode (with "F1" key).

Really strange, indeed... I play both TW3 and ACO in 1440p...

It seems that the buffer detection fails when sizeinfo.width and sizeinfo.height return 0. It might be related to the depthstencil_size depth_counter_tracker::get_depth_stencil_size method, not returning the right value.

However, i found a workaround to the pb on my config. I made a slight change in the depth_counter_tracker.cpp method named ID3D11DepthStencilView* depth_counter_tracker::get_best_depth_stencil, like this:
ID3D11DepthStencilView* depth_counter_tracker::get_best_depth_stencil(std::unordered_map<ID3D11DepthStencilView*, depthstencil_size> const& depthstencils, UINT width, UINT height)
{
	depthstencil_counter_info best_info = { 0 };
	ID3D11DepthStencilView *best_match = nullptr;
	float aspect_ratio = ((float)width) / ((float)height);

	for (auto it : _counters_per_used_depthstencil)
	{
		const auto depthstencil = it.first;
		auto &depthstencil_info = it.second;
		
		if (depthstencil_info.drawcall_count == 0)
		{
			continue;
		}
		auto sizeinfo = get_depth_stencil_size(depthstencils, depthstencil);
		bool size_mismatch = false; 
		
		LOG(INFO) << "Returning sizeinfo.width " << sizeinfo.width;
		LOG(INFO) << "Returning sizeinfo.height " << sizeinfo.height;
		
		// if the size of the depth stencil has the size of the window, we'll look at its counters. If it doesn't we'll try some heuristics, like
		// aspect ratio equivalence or whether the height is 1 off, which is sometimes the case in some games. 
               // ****** slight modification: check if sizeinfo.width and sizeinfo.height are returned ******
		if (sizeinfo.width > 0 && sizeinfo.height > 0)
		{
			if (sizeinfo.width != width)
			{
				size_mismatch = true;
			}
			if (sizeinfo.height != height)
			{
				// check if height is uneven, some games round depthsize height to an even number.
				if (sizeinfo.height != (height - 1) && sizeinfo.height != (height + 1))
				{
					// not a matching height
					size_mismatch = true;
				}
			}
			if (size_mismatch)
			{
				// check aspect ratio. 
				float stencilaspectratio = ((float)sizeinfo.width) / ((float)sizeinfo.height);
				if (fabs(stencilaspectratio - aspect_ratio) > 0.1f)
				{
					// still no match, not a good fit
					continue;
				}
			}
			
			if (depthstencil_info.drawcall_count >= best_info.drawcall_count)
			{
				best_match = depthstencil;
				best_info = depthstencil_info;
				LOG(INFO) << "Match found !!!";
			}
		}
	}
	return best_match;
}

With this, no more buffer detection fails, except in one case: in ACO, if i return to desktop, then i revert back to the game. For a reason i ignore, the sizeinfo retrieval fails. It does not happen with TW3.

I added some logs to check it, and here is what it returns for ACO in this specific case:
2018-01-02T21:31:40:401 [03832] | INFO  | Redirecting 'IDXGISwapChain::SetFullscreenState(00000001A92EE7D0, FALSE, 0000000000000000)' ...
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:559 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:40:858 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:31:41:164 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:31:41:447 [03832] | INFO  | Returning sizeinfo.width 0

I should have this, when it works:
2018-01-02T21:30:41:724 [03832] | INFO  | Redirecting 'IDXGISwapChain::SetFullscreenState(00000001A92EE7D0, FALSE, 0000000000000000)' ...
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 512
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 512
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 1024
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 1024
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 64
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 64
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 2048
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 2048
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 0
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 0
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 2144
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 1208
2018-01-02T21:30:41:973 [03832] | INFO  | Match found !!!
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 64
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 64
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 1280
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 720
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 64
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 64
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 1072
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 604
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.width 2560
2018-01-02T21:30:41:973 [03832] | INFO  | Returning sizeinfo.height 1440
2018-01-02T21:30:42:327 [03832] | INFO  | Returning sizeinfo.width 2048
2018-01-02T21:30:42:327 [03832] | INFO  | Returning sizeinfo.height 2048
2018-01-02T21:30:42:327 [03832] | INFO  | Returning sizeinfo.width 2144
2018-01-02T21:30:42:327 [03832] | INFO  | Returning sizeinfo.height 1208
2018-01-02T21:30:42:327 [03832] | INFO  | Match found !!!

I tested Mass Effect Andromeda (with TAA on), and it works well on it, even if i go back to desktop, then return to the game:




(edit) I have a Maxwell Titan, but not a Pascal one, and a gsync monitor.

(edit) Two other videos from ACO showing the buffer detection fail with the original code, so you can try to reproduce it on ACO: ACO videos
Last Edit: 1 year 5 months ago by thalixte.
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus

3.1 1 year 5 months ago #102

thalixte wrote:
OtisInf wrote:
@thalixte: weird! I load your save file, but everything keeps on working here... No matter what angle I take, or where I move the player ... I also downgraded every gfx setting to 'low' as you suggested that the # of vertices dropped below a given threshold so I thought perhaps it's the gfx settings I have (everything maxed) but... nope 1920x1200... works like a charm. Will try other resolutions now but I don't know what triggers it on your part...

(edit) windowed mode, 1440x900 or so, no problem either... :/ very odd. ..

Will now install the photomode mod to see if I can reproduce it without gerhalt's ass in the way :)

(edit) I remembered I could just use Ansel and I can't reproduce it with that either. Flying around, like you in your video, same spot, using displaydepth, not a problem at all, right depth buffer is chosen every time, looking at a clear sky, all OK... really weird.

Ansel simply disables reshade effects. I use a TW3 mod (PhotoMode 2inOne for Debug Console Enabler) to enable the flight mode (with "F1" key).
Yes I know it well, but it took more effort (as I've finished TW3 some time ago ;)) ansel only disables depth buffer when taking a screenshot (as it uses tile-based rendering, even for native res shots, for the rest it's just a camera manipulation system so it uses the same framebuffer), when flying around the display depth shader worked fine and I couldn't detect any problems whatsoever.
Really strange, indeed... I play both TW3 and ACO in 1440p...
It seems that the buffer detection fails when sizeinfo.width and sizeinfo.height return 0. It might be related to the depthstencil_size depth_counter_tracker::get_depth_stencil_size method, not returning the right value.
What's so strange about this is that width and height are the texture width/height from the D3D11_TEXTURE2D_DESC struct, which are never 0 (range is 1-max_based_on_feature_level), see: msdn.microsoft.com/en-us/library/windows...476253(v=vs.85).aspx). Perhaps this is a driver issue, no idea, but something's off. I use windows 8.1 x64, latest nvidia drivers
However, i found a workaround to the pb on my config. I made a slight change in the depth_counter_tracker.cpp method named ID3D11DepthStencilView* depth_counter_tracker::get_best_depth_stencil, like this:

(snip)

With this, no more buffer detection fails, except in one case: in ACO, if i return to desktop, then i revert back to the game. For a reason i ignore, the sizeinfo retrieval fails. It does not happen with TW3.
As in: it then never recovers? Or after 30 frames? (as there's a delay). Checking for 0 could be a valuable workaround, however adding code for something that has its cause elsewhere is never a good idea. that said, I'll see if I can find evidence on my system if width/height are 0 as well in some cases...

I do see I can get rid of the sizeinfo struct there so I at least will make that change.

Thanks for testing it on more games btw! :)

(edit) I put a breakpoint with a conditional after the texture retrieval, but it never reports either width or height being 0 in ACO, alt-tabbing or not, looking up to the sky...

Perhaps crosire has an idea, but other than that, I don't know what causes this. I'll ask him in the PR if the workaround is required.
Last Edit: 1 year 5 months ago by OtisInf.
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus, thalixte

3.1 1 year 5 months ago #103

OtisInf wrote:
As in: it then never recovers? Or after 30 frames? (as there's a delay). Checking for 0 could be a valuable workaround, however adding code for something that has its cause elsewhere is never a good idea. that said, I'll see if I can find evidence on my system if width/height are 0 as well in some cases...

No, it never recovers, except if i change the graphics settings, but to do so, i must disable the shader. Obviously, it do not happens on the other games i have tested...

(edit) Ok, tested your last commit on ACO and TW3, and no more problems... It works perfectly. Thks a lot !! ;)

If i understand how it works, may i suggest you a very slight modification in ID3D11DepthStencilView* depth_counter_tracker::get_best_depth_stencil(UINT width, UINT height): if the retrieval of texture_desc fails with resource->QueryInterface(&texture), it is not necessary to run the code above, so, i would suggest:
depthstencil->GetResource(&resource);
if (!FAILED(resource->QueryInterface(&texture)))
{
	texture->GetDesc(&texture_desc);
}
else continue;
Is it right for you ?
Last Edit: 1 year 5 months ago by thalixte.
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus, OtisInf

3.1 1 year 5 months ago #104

Ah you weren't using the latest build! I already wondered wtf was wrong haha :) Ok, that's a relief, glad it's not something with the code :)

Your change proposal is a good catch! it's indeed a dumb mistake I made. I'll make the necessary changes and push to the PR so it gets merged too :) Thanks for testing and feedback! :)
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus

3.1 1 year 5 months ago #105

OtisInf wrote:
Ah you weren't using the latest build! I already wondered wtf was wrong haha :) Ok, that's a relief, glad it's not something with the code :)

Your change proposal is a good catch! it's indeed a dumb mistake I made. I'll make the necessary changes and push to the PR so it gets merged too :) Thanks for testing and feedback! :)

Maybe you're right :blush: , but i'm glad to tell you that your latest build has resolved all my issues ;)
Again, thks for all. I think you will make some gamers happy with those modifications on Reshade. I think, for instance, of the SuperDepth3d shader, that will work with almost every game, if the buffer data retrieval is solved with Reshade (VR in ACO, yesssss !!!):



Last Edit: 1 year 5 months ago by thalixte.
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus, OtisInf

3.1 1 year 5 months ago #106

Quick question, is it possible to replace the depth buffer with a reserved value like -1 or whatever outside [0,1] range to allow for checking in shader if buffer is invalid? Or for example, add a warning ingame that the correct depth buffer hasn't been found? I get quite a lot of messages about DoF not working, MXAO not working, blaming the shader all the time.
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus

3.1 1 year 5 months ago #107

Marty McFly wrote:
Quick question, is it possible to replace the depth buffer with a reserved value like -1 or whatever outside [0,1] range to allow for checking in shader if buffer is invalid? Or for example, add a warning ingame that the correct depth buffer hasn't been found? I get quite a lot of messages about DoF not working, MXAO not working, blaming the shader all the time.
I second this. Not just for reasons above, but because sometimes using the display-depth shader you get all black or all white, and I don't know if the depth buffer hasn't been found, or it -has- been found but I need to tweak logarithmic/reversed/setting far distance etc to get it working. Would simply save time knowing if it couldn't be found in the first place.
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus

3.1 1 year 5 months ago #108

Marty McFly wrote:
Quick question, is it possible to replace the depth buffer with a reserved value like -1 or whatever outside [0,1] range to allow for checking in shader if buffer is invalid? Or for example, add a warning ingame that the correct depth buffer hasn't been found? I get quite a lot of messages about DoF not working, MXAO not working, blaming the shader all the time.
Games often use multiple depth stencil buffers. E.g. in AC:Origins there were sometimes 24 or more per frame, with various sizes. Reshade did a good job picking the right one out of that set which had the output frame's depth buffer but in some cases this went wrong for reasons already discussed here (like in AC:O) and other code was needed. I too thought about checking the depth buffer and simply check whether it's empty and skip it if it is. That however requires a read of the texture to CPU, which will always be slow(er): compute/pixelshader renders value(s) to a render target which is then read back using CopyResource. This can be a small texture of course, we just need 1 value back (is it empty or not). the value read back is then used to either accept the buffer or not.

there might be a radical different way tho: move everything to the GPU: reshade first runs shader which renders to its output the depth info from the texture that contains data, it renders to the depth buffer texture used by all other shaders (so basically copying it). This is also slower than what we have today btw but could mean an alternative.

tho I doubt that will solve all problems regarding users who blame the wrong thing: e.g. in a game like TombRaider (2013), the game clears the depth buffer before Present, so there's no info in the buffers (there are 2, both are empty), nothing can preserve that. Telling them 'the depth buffer is empty' will mean as much to them as "ahy45r022hgfh shfd!", i.e.: nothing, as a lot of them don't know what a depth buffer is, nor that it's essential for some shaders.
Last Edit: 1 year 5 months ago by OtisInf.
The topic has been locked.
The following user(s) said Thank You: crosire, Aelius Maximus

3.1 1 year 5 months ago #109

OtisInf wrote:
tho I doubt that will solve all problems regarding users who blame the wrong thing: e.g. in a game like TombRaider (2013), the game clears the depth buffer before Present, so there's no info in the buffers (there are 2, both are empty), nothing can preserve that. Telling them 'the depth buffer is empty' will mean as much to them as "ahy45r022hgfh shfd!", i.e.: nothing, as a lot of them don't know what a depth buffer is, nor that it's essential for some shaders.

So, the buffer detection you implemented will not work for every game, what a pity ! But it will for the majority i guess. I don't think there are a big number of games that clear the depthbuffer before the end of the frame rendering.

So, maybe i will tell something really stupid, but i remember that dxd9 GeDoSaTo injector had the ability to inject its own shaders, not only at the end of frame rendering, but also during the frame rendering, as it is explained here (PC Gamer Durante's article on geDoSaTo). So, in this case, it would be possible to retrieve depth buffer data before they are removed by the game engine...
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus

3.1 1 year 5 months ago #110

thalixte wrote:
OtisInf wrote:
tho I doubt that will solve all problems regarding users who blame the wrong thing: e.g. in a game like TombRaider (2013), the game clears the depth buffer before Present, so there's no info in the buffers (there are 2, both are empty), nothing can preserve that. Telling them 'the depth buffer is empty' will mean as much to them as "ahy45r022hgfh shfd!", i.e.: nothing, as a lot of them don't know what a depth buffer is, nor that it's essential for some shaders.

So, the buffer detection you implemented will not work for every game, what a pity ! But it will for the majority i guess. I don't think there are a big number of games that clear the depthbuffer before the end of the frame rendering.
indeed, it just picks the buffer, if it's empty that's not determinable. If the game clears it, then it won't be helpful to pick any buffer, it's just empty. Some engines also render several parts to different buffers and blend the results together (e.g. assassin's creed 3 did this in e.g. cutscenes: the backgrounds were in the main depth buffer but the character was often not in the depth buffer, suggesting it was rendered off screen and the result then blended with the background in the main output buffer. this only works if there's nothing in front of the character, but that's often the case with cutscenes. )
So, maybe i will tell something really stupid, but i remember that dxd9 GeDoSaTo injector had the ability to inject its own shaders, not only at the end of frame rendering, but also during the frame rendering, as it is explained here (PC Gamer Durante's article on geDoSaTo). So, in this case, it would be possible to retrieve depth buffer data before they are removed by the game engine...
d3d9 is different tho, I think he detected the switch to an orthogonal viewport (for hud rendering) and thus ran the shaders right before that, but that's guessing. Reshade could intercept the call to D3D11DeviceContext::ClearDepthStencilView and e.g. postpone it till after the reshade shaders have run, IF the view to clear is the chosen depth buffer of the previous frame. But this likely has side effects: perhaps the game clears the depth buffer for other reasons (not every pass uses the depth buffer after all). so all in all, it's not a simple problem :)
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus

3.1 1 year 5 months ago #111

OtisInf wrote:
there might be a radical different way tho: move everything to the GPU: reshade first runs shader which renders to its output the depth info from the texture that contains data, it renders to the depth buffer texture used by all other shaders (so basically copying it). This is also slower than what we have today btw but could mean an alternative.

As far as I know, this is what ENBSeries does. I read multiple times on enbdev that Boris creates his own buffer so I assume he assembles his own one from various accessible as Skyrim has a shitload of different ones.

Also, about HUD masking, are there any identifiers like switch to orthogonal viewport or similar that are always true for when HUD is drawn (but for other occurences as well)? If so, maybe add a switch that cycles through all of them until the right one is found. Current ini layout would allow for such a game specific value. I know you're looking for a way that works on all games automatically but even the depth linearizing requires user interaction.
Last Edit: 1 year 5 months ago by Marty McFly.
The topic has been locked.

3.1 1 year 5 months ago #112

I don't want to say anything bad, after all, my friend recommended me this program, but... it's not that I don't trust my friends, but I try to scan any new programs/files with VirusTotal. The results were 5/60 antiviruses found Shelma trojan. All are not really good antivirus solutions, but... to double check, can you give me any guarantee at all that the installer, program(s), DLLs, or any other files contained in the program or that go with the program, have no malware of any type (viruses, trojans, worms... you name it)?
The topic has been locked.

3.1 1 year 5 months ago #113

Yeah. It's open source: github.com/crosire/reshade.
Cheers, crosire =)
The topic has been locked.

3.1 1 year 5 months ago #114

I want to learn coding, but as of right now - open source means only that I can view and edit the source code. But I can't differentiate "a" from "b" in coding. As follows, why do the antiviruses find the trojan in that case? I understand, the ones that did find are not trustworthy ones:
CAT-QuickHeal: Trojan.Shelma
CrowdStrike Falcon: malicious_confidence_60% (D)
Fortinet: W32/Shelma.VNW!tr
MAX: malware (ai score=99)
ViRobot: Trojan.Win32.Z.Shelma.4160512

and the ones I really trust didn't find any malware at all: Kaspersky, Avira, Avast, NOD32 - so, I would assume there is no virus. Just wanted to double check. I guess, thanks.
The topic has been locked.

3.1 1 year 5 months ago #115

Because it's a false positive. AntiVirus software is not perfect, they make mistakes. For some reason the signature of the setup tool has similarities to an existing malware application, which is why some raise the alarm. A few of the big ones initially complained too, but were since notified, so that their labs checked ReShade, deemed it safe and therefore the detection was fixed so they don't find malware anymore (since there is none).
Cheers, crosire =)
The topic has been locked.

3.1 1 year 5 months ago #116

I've stumbled upon an irritating bug or something. But it happens on both my friends computer and mine with Reshade 3.1. The problem is that sometimes a .ini preset just disappears and no settings are saved, this never happened before. It also happens sometimes when I change from configuration mode to performance mode. Really irritating. Anyone familiar with this behavior?

Kind regards!
The topic has been locked.

3.1 1 year 5 months ago #117

*cough* WHAT?

Just released Nvidia 390.65 drivers. Apart from a security fix for the meltdown/spectre debacle, there's also this:

Gaming Technology
Adds support for NVIDIA Freestyle which lets you apply post-processing filters to your games while you play.


http://us.download.nvidia.com/Windows/390.65/390.65-win10-win8-win7-desktop-release-notes.pdf

Some of these look like they're Reshade shaders (Clarity, HDR toning...)

The topic has been locked.
The following user(s) said Thank You: Aelius Maximus

3.1 1 year 5 months ago #118

crosire wrote:
Because it's a false positive. AntiVirus software is not perfect, they make mistakes. For some reason the signature of the setup tool has similarities to an existing malware application, which is why some raise the alarm. A few of the big ones initially complained too, but were since notified, so that their labs checked ReShade, deemed it safe and therefore the detection was fixed so they don't find malware anymore (since there is none).

Crosire,

First of all, thk U for this fantastic tool ;) ! I have just two little questions:
  • Do you plan to change the release version of reshade after your last commits to the master branch on github, that included the lastest updates from OtisInf, and to make it available on the reshade site (or, maybe it is already the case) ?
  • Are you working with nvidia folks to provide freestyle, or is it an nvidia exclusive implementation ?

Also, would it be possible for you to merge branch master into openvr ?

Bya advance, thks a lot ...
Last Edit: 1 year 5 months ago by thalixte.
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus

3.1 1 year 5 months ago #119

Martigen wrote:
Some of these look like they're Reshade shaders (Clarity, HDR toning...)
All code is used with explicit permission by the authors (and was actually partly written specifically for FreeStyle). Nothing wrong here.

thalixte wrote:
First of all, thk U for this fantastic tool ;) ! I have just two little questions
1) Yeah. Soon™.
2) I am involved with NVIDIA, yes.
3) Sure, I will merge over once the next release is ready.
Cheers, crosire =)
Last Edit: 1 year 5 months ago by crosire.
The topic has been locked.
The following user(s) said Thank You: Aelius Maximus, thalixte

3.1 1 year 5 months ago #120

crosire wrote:
2) I am involved with NVIDIA, yes.
Cool, could you ask them to not use tiled based rendering when they take a screenshot that has the same resolution as the backbuffer? :) Because it looks like they do now which means they kill off the depth buffer and the effects that rely on it ;)

Marty McFly wrote:
As far as I know, this is what ENBSeries does. I read multiple times on enbdev that Boris creates his own buffer so I assume he assembles his own one from various accessible as Skyrim has a shitload of different ones.
Not sure that's what he does tho. All you need to do is create a texture from the depthbuffer and add a sampler on it (afaik that's what reshade does) and I doubt boris does something else. (but it might be he does something different. the AO in ENB is so terribly slow that it can't be he does something efficient)
Also, about HUD masking, are there any identifiers like switch to orthogonal viewport or similar that are always true for when HUD is drawn (but for other occurences as well)? If so, maybe add a switch that cycles through all of them until the right one is found. Current ini layout would allow for such a game specific value. I know you're looking for a way that works on all games automatically but even the depth linearizing requires user interaction.
In general rendering a HUD is using orthogonal projection so when the projection matrix is switched to an orthogonal projection matrix, it's assumable HUD elements are rendered. But it can also be elements from the game are rendered, so I don't think it's a 100% guaranteed thing, but surely something to look into. HUD toggles based on shaderhashes are doable but you first have to determine the shader hashes for a game and that can be a tedious process without tooling (3d migoto helps, but not always).
Last Edit: 1 year 5 months ago by OtisInf.
The topic has been locked.
The following user(s) said Thank You: thalixte