Attributes to FS contain NaN

[kf6kjg]

From my research it it looks like the FROM and TWO are somehow getting the same value:

This result in a div/0 error that results in the attributes getting NaN as a value.

This is based off of master at 7702efb

[theproadam]

Is this happening for every pixel or just some pixels (ie, the ones on the left side of the screen)?

[kf6kjg]

I've not determined. Been trying to build a version of the demos that shows the problem.

[kf6kjg]

I've been unable thus far to build a demo that shows the issue, but I did modify my shader:

		public unsafe void TerrainShaderFS(byte* bgr, float* attributes, int faceIndex)
		{
			// UVZ
			// 012
			var u = renderX.Clamp01(attributes[0]);
			var v = renderX.Clamp01(attributes[1]);
			var terrainHeight = attributes[2];

			if (float.IsNaN(u) || float.IsNaN(v) || float.IsNaN(terrainHeight))
			{
				bgr[0] = 0;
				bgr[1] = 0;
				bgr[2] = 255;

				return;
			}
...

And yes, it's only the ones on the left side of the screen. EDIT: Whoops, just realized that I had the patch from #5 (comment) applied when I got this result.

[kf6kjg]

Running without the patch from #5 I still get errors. However they are not all on the leftmost pixel: they are scattered.

And it changes pattern in every file it renders.

[theproadam]

Can you try running it with the patch, however comment out these two lines in the patch:

FROM[0] = roundf(FROM[0]);
TO[0] = roundf(TO[0]);

They can be found right after the if (ScanLinePLUS(i, VERTEX_DATA, BUFFER_SIZE, Intersects)) call.

[kf6kjg]

I got my demo variation showing the problem: https://github.com/kf6kjg/renderXF/tree/issue_10

And commenting out the roundf lines didn't fix it.

Here's a screenshot using GL.Blit() to do the rendering since there's an additional problem with blitting to the bitmap for some reason:

Be sure to zoom in: the blue dots along the left edge are where the attributes ae NaN due to the slope being 0.

[theproadam]

Okay excellent, I will check it out.

[theproadam]

Okay, I have fixed the problem, however I will have to reexamine the scanline algorithm as some issues have emerged while testing it in XFDraw. I have created a pull request for issue_10.