Welcome, Guest.
Username: Password: Remember me
Forgot your password? Forgot your username? Create an account!

TOPIC: Seemingly arbitrary bugs?

Seemingly arbitrary bugs? 8 months 4 weeks ago #1

I'm currently developing a shader which requires me to blur the image first.
However, there have been some weird bugs plagging me for a while.

In DX9, in areas where depth returns 0, the screen blacks out, and outside of those, it flickers a lot. From what I can tell, that means one of the textures is not being rendered properly.
The awkward part though, is that the only fix I've found for this is to reload the shader. No changes to variables or code, nor changing where I look, just reload a few times. Eventually, it starts working again, if not instantly. This happens only once in a while, which makes it even weirder.

In DX11, it never displays this issue. However, I've recently messed with matrices and the vertex shader in hopes of improving performance (which sadly didn't), and that created another weird glitch: one of the textures just spazzes out depending on where I look, and does so intermittently. Reloading the shader does not fix it. So, what fixed it? Changed:
position = float4(xy * float2(2.0, -2.0) + float2(-1.0, 1.0), 0.0, 1);
to
position = float4(xy * float2(2.0, -2.0) + float2(-1.0, 1.0), 0.0, 1. + 10e-7);

I never use SV_Position for anything, nor change it anywhere else. And this glitch is exclusive to DX11 (not sure if it also happens in DX10).

Any idea what's going on?
Last Edit: 8 months 3 weeks ago by ShoterXX. Reason: EDIT: fixed.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 4 weeks ago #2

I have had similar bugs with infinity literals or NaNs in the code, check for divisions though 0 under certain circumstances and so on. Can you post the entire shader code maybe? It's difficult to give tips without seeing the code itself.
Last Edit: 8 months 4 weeks ago by Marty McFly.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 4 weeks ago #3

Sure.

pastebin.com/n6C2b5qD

pastebin.com/z2Qn9EZ9

Feel free to comment on "do" and "don't"s you may find.
Last Edit: 8 months 4 weeks ago by ShoterXX.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 4 weeks ago #4

Have you tried to reduce the usage of TEXCOORD ? (you don't need to interpolate zw anyways)

I've bumped into some weird stuffs when having 3+ texcoord before (presumably some sort of register overflow? ), either in reshaderFX, or in enb FX11/FX9 on gtx680.
hardly any document or discussion on this problem then the supposedly 8 or 32 limit...those ppl in gamedev would probably just gonna tell you to load up PIX to check.(which is actually a viable option though.)

(though, SMAA does use more then 4 texcoord register...making the whole thing even weirder...)
Last Edit: 8 months 4 weeks ago by kingeric1992.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 4 weeks ago #5

I noticed strange bugs when using a lot of texcoords and not using all registers, like assigning a float2 to texcoord1, 2, assigning a float3 to texcoord3 etc.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 3 weeks ago #6

moving the matrix to PS fixed everything. case close.

edit: fond a legit way of fixing the issue.

In vertex shader, use
static const float2 xy_c[3] = { float2(0.0, 0.0), float2(0.0, 2.0), float2(2.0, 0.0)};
        xy = xy_c[id];
instead of
xy.x = (id == 2) ? 2.0 : 0.0;
xy.y = (id == 1) ? 2.0 : 0.0; 
//or any form of "==" as you were doing
will fix any precision issue from "=="
(which is a don't for shader programming, or try asint() with double to increase the precision)
Last Edit: 8 months 3 weeks ago by kingeric1992.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 3 weeks ago #7

Sorry about the lack of replies, but I've been bedridden for a while now :/
Still am, but I'm also getting sick of doing nothing at all...

SO, tested most of the stuff said here... and not much, really. Not even the fix that I mentioned myself, that only disguises part of the problem.

DX9 bug still occurs regardless. I think this may have to do with initializations somewhere, but I just can't find a fix.

As for DX11, I tested around a bit, and it seems to happen when the framerate is higher.
Since the performance improvements were nil, and after testing suggested solutions but having mixed results (flickering still happens, one way or the other), I rolled back to before messing around with vertex shaders and matrices. That resolved that issue, but... I realized that there was still some slight blur problems.

I was negating the effect of the pingpong between frames (oops), making it uneven. After fixing that, I ended up with yet another issue... the blur itself was flickering. After more testing, it seems like the pingpong uniform is not changing correctly, making it harder to blend properly, since it should swap direction every frame, but seems to miss some. (Note that flickering should occur, but at the ratio I'm using, it's not noticeable, which wasn't the case.)
So, I created a 1x1 texture, and swap it at the beggining of every frame. That fixed the issue, though not optimally.

And that's about it so far.
Last Edit: 8 months 3 weeks ago by ShoterXX.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 3 weeks ago #8

first, here's what I've gather so far from the source code on "pingpong"
  • the pingpong uniform updates per frame, not per pass
  • the second component of "step" provides a random step increment of ouput instead of constant step,
  • the step is framerate independent, mening it is not constant step between frame
  • the minimum increment step is 0.05,
  • there's a hidden annotation "smoothing" to decrease step when value is near the end points.

secondly, the pixeloffset you're using has min/max offset 72 pixel, which is "flipping as expected", with frequency defined by your pingpong term, which I assumed is what you intended for the shader, and was not what I fixed with the provided solutions, (I can have both type of flickering happened in the same time.)

this is what I saw, and fixed: (obviously sth is fuck up texcoord and position)
Last Edit: 8 months 3 weeks ago by kingeric1992.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 3 weeks ago #9

Yes, you're right. Both:

static const float2 xy_c[3] = { float2(0.0, 0.0), float2(0.0, 2.0), float2(2.0, 0.0)};
        xy = xy_c[id];
and

position = float4(xy * float2(2.0, -2.0) + float2(-1.0, 1.0), 0.0, 1. + 10e-7);
fix the mentioned issue. I was assuming an incorrect behavior from pingpong it seems, which was causing the weird remaining flickering.

Also, I've just switched to using framecount, because why not use it in the first place. :silly:

DX9 issue still remains however.
Last Edit: 8 months 3 weeks ago by ShoterXX. Reason: EDIT: fixed.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 3 weeks ago #10

yeah, I didn't check dx9.

another thing is that the 1.0e-7 doesn't fix the issue for me (dx11).
for all I know, 1. + 1.0e-7 is equivalent to 1. from reshade's pov, (while 1 != 1.)

Have you tried to debug your effect from just one pass? check if there's any depth related extrema.
Last Edit: 8 months 3 weeks ago by kingeric1992.
The administrator has disabled public write access.

Seemingly arbitrary bugs? 8 months 3 weeks ago #11

AAAAAAAAAAARGH

10e-7, not 1.0e-7

1 + 10e-7 = 1.000001 -> this works
1 + 1.0e-7 = 1.0000001 -> this doesn't

Sorry.
The administrator has disabled public write access.