Danfun64 Posted December 24, 2017 (edited) 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. Spoiler On 6/19/2013 at 8:11 PM, Holering said: dosbox_fullscreen chocolate-doom_fullscreen prboom-plus_fullscreen_4x3aspect prboom-plus_fullscreen_5x4aspect prboom-plus_fullscreen_autoaspect eternity_fullscreen_4x3aspect eternity_fullscreen_5x4aspect eternity_fullscreen_legacy odamex_fullscreen_stretch_doublehorizontal-doublevertical_640x400 These are all double scaled from 320x200 to 640x400. Here's my own pics of Crispy Doom, Crispy Doom Low Detail, Boom, and MBF 640x400 (open tab for full size) Spoiler So my question is... why do certain ports have these kind of alignment problems... and more importantly, do they really matter? Edited December 25, 2017 by Danfun64 : add additonal linebreak 0 Share this post Link to post
SaladBadger Posted December 24, 2017 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. 0 Share this post Link to post
fabian Posted December 24, 2017 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. 0 Share this post Link to post
Danfun64 Posted December 24, 2017 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 0 Share this post Link to post
Linguica Posted December 24, 2017 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. 0 Share this post Link to post
Danfun64 Posted December 24, 2017 (edited) Excert from Chocolate r_draw.c Spoiler // 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 Spoiler // 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 Spoiler #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 Spoiler #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]; } 0 Share this post Link to post
fabian Posted December 25, 2017 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? 0 Share this post Link to post
Cacodemon345 Posted December 25, 2017 (edited) Anyways,does the latest ZDoom renders it correctly? 0 Share this post Link to post