Rendering OCD

Despite being a few years old as of this writing, I literally just noticed this thread, and it caught my interest. For whatever reason, certain ports align textures and sprites differently than others. Chocolate Doom, Boom and MBF look "right" when compared to DOS Doom, but other ports, like Eternity, PrBoom-Plus and even Crispy Doom look "wrong"... if you really want to be OCD about it.
 

Here's my own pics of Crispy Doom, Crispy Doom Low Detail, Boom, and MBF 640x400 (open tab for full size)
 

So my question is... why do certain ports have these kind of alignment problems... and more importantly, do they really matter?

One thing I can say for certain: I believe that the released Doom source code uses a different algorithm for drawing wall columns and flat spans, written in C, whereas the originals are written in assembly, included as a little extra with the source code, but not compiled by default. I don't know how much the column drawer differs, but the new span drawer does have some differences (and perhaps some improvements? I remember reading that Doom's normal span drawer starts getting uglier as it draws further to the right). EE's differences can likely be explained by the shift to the floating point based renderer, and PrBoom's renderer does have a lot of changes and bugfixes applied on top of it, which have likely changed things over the years. I do not know if its using drawers based on the asm originals or the c versions in the linuxdoom source.

The chocolate doom screenshot is darker than the dosbox screenshot, but I wouldn't be surprised if that's just due to the 6-bit color conversion.

When comparing the Vanilla screenshot with the Crispy 320x200 one, the most significant change can be found in the rendering of the flats. I am sure this can be explained by two fixes to the Vanilla code which led to distorted flat rendering (which became especially noticeable in the higher resolution), i.e.

https://github.com/fabiangreffrath/crispy-doom/blob/master/src/doom/r_plane.c#L138

and

https://github.com/fabiangreffrath/crispy-doom/blob/master/src/doom/r_draw.c#L977 .

Regarding the rendering of the segs in the distance, I think this can be attributed to the "line wiggle" and "long wall wobble" fixes. ;)

Also, which Crispy version was used for the screenshots? I have fiddled around with the fake contrast code at some point, but this has been fixed for the 4.3 release.

So you're saying that the way the flats are rendered in Vanilla/Chocolate/Boom/MBF is wrong? Considering how Crispy, Eternity, PrBoom-Plus, Odamex fix the rendering issues differently, is there a "right" way for the flats to be rendered/aligned?

As for the version of Crispy I am using... It's commit d4b04411

7 hours ago, fabian said:

https://github.com/fabiangreffrath/crispy-doom/blob/master/src/doom/r_draw.c#L977 .

So uh how does this fix anything? I wish the comments would actually explain what has been changed and why.

Excert from Chocolate r_draw.c

    // Blocky mode, need to multiply by 2.
    ds_x1 <<= 1;
    ds_x2 <<= 1;

    dest = ylookup[ds_y] + columnofs[ds_x1];

    do
    {
	// Calculate current texture index in u,v.
        ytemp = (position >> 4) & 0x0fc0;
        xtemp = (position >> 26);
        spot = xtemp | ytemp;

	// Lowres/blocky mode does it twice,
	//  while scale is adjusted appropriately.
	*dest++ = ds_colormap[ds_source[spot]];
	*dest++ = ds_colormap[ds_source[spot]];

	position += step;

    } while (count--);

Excert from Crispy r_draw.c

    // Blocky mode, need to multiply by 2.
    ds_x1 <<= 1;
    ds_x2 <<= 1;

    dest = ylookup[(ds_y << hires)] + columnofs[ds_x1];
    dest2 = ylookup[(ds_y << hires) + 1] + columnofs[ds_x1];

    do
    {
	// Calculate current texture index in u,v.
        // [crispy] fix flats getting more distorted the closer they are to the right
        ytemp = (ds_yfrac >> 10) & 0x0fc0;
        xtemp = (ds_xfrac >> 16) & 0x3f;
        spot = xtemp | ytemp;

	// Lowres/blocky mode does it twice,
	//  while scale is adjusted appropriately.
	*dest++ = ds_colormap[ds_source[spot]];
	*dest++ = ds_colormap[ds_source[spot]];
	if (hires)
	{
	    *dest2++ = ds_colormap[ds_source[spot]];
	    *dest2++ = ds_colormap[ds_source[spot]];
	}

//	position += step;
	ds_xfrac += ds_xstep;
	ds_yfrac += ds_ystep;


    } while (count--);

Excert from Chocolate r_draw.c

#ifdef RANGECHECK
    if (x2 < x1
     || x1 < 0
     || x2 >= viewwidth
     || y > viewheight)
    {
	I_Error ("R_MapPlane: %i, %i at %i",x1,x2,y);
    }
#endif

    if (planeheight != cachedheight[y])
    {
	cachedheight[y] = planeheight;
	distance = cacheddistance[y] = FixedMul (planeheight, yslope[y]);
	ds_xstep = cachedxstep[y] = FixedMul (distance,basexscale);
	ds_ystep = cachedystep[y] = FixedMul (distance,baseyscale);
    }
    else
    {
	distance = cacheddistance[y];
	ds_xstep = cachedxstep[y];
	ds_ystep = cachedystep[y];
    }

Excert from Crispy r_plane.c

#ifdef RANGECHECK
    if (x2 < x1
     || x1 < 0
     || x2 >= viewwidth
     || y > viewheight)
    {
	I_Error ("R_MapPlane: %i, %i at %i",x1,x2,y);
    }
#endif

// [crispy] visplanes with the same flats now match up far better than before
// adapted from prboom-plus/src/r_plane.c:191-239, translated to fixed-point math

    if (!(dy = abs(centery - y)))
    {
	return;
    }

    if (planeheight != cachedheight[y])
    {
	cachedheight[y] = planeheight;
	distance = cacheddistance[y] = FixedMul (planeheight, yslope[y]);
	ds_xstep = cachedxstep[y] = FixedMul (viewsin, planeheight) / dy;
	ds_ystep = cachedystep[y] = FixedMul (viewcos, planeheight) / dy;
    }
    else
    {
	distance = cacheddistance[y];
	ds_xstep = cachedxstep[y];
	ds_ystep = cachedystep[y];
    }

14 hours ago, Linguica said:

So uh how does this fix anything? I wish the comments would actually explain what has been changed and why.

I have to admit that it is not obvious (not even to me right now), but in the original code (which is still present but commented out) there was some accumulated precision loss due to rounding errors caused by repeated right shifting. That's why the distortion became more apparent on the right side of the screen (increasing horizontal screen coordinate).

> is there a "right" way for the flats to be rendered/aligned

I guess that the approach in Crispy (which I have taken over from PrBoom+, which in turn has taken it from ZDoom, I believe) is mathematically more correct, but the other code is Vanilla and thus "good enough" by itself. ;) However, the rendering distortion becomes worse with increased screen resolution and even with Crispy's 640x480 there were some places where this really hurt, and so I decided to fix the code.

PS: Isn't this thread better suited to the "Source Ports" section?

Anyways,does the latest ZDoom renders it correctly?