#663 Textures with pink/black/pink stripes

[Michael Bäuerle]

See attached screenshot from Map 1 of Lost Civilization:
https://www.doomworld.com/idgames/levels/doom2/Ports/megawads/joi_lstcv15
(from the start walk along the walls on the left side until you reach this location)

Looks the same on Linux/ppc and NetBSD/am64, likely no endianess problem.

[Michael Bäuerle]

Same problem can be seen above the bridge in the start area.
PrBoom+ does not display such colored stripes.
See attached screenshots for comparison.

Tested with version 1.48.4, but older versions show similar behaviour.

[Wesley Johnson]

View it with OpenGL, and those are missing textures.
The software render will fill a missing texture with texture[0], just to make the map playable.
Texture[0] in doom is usually the vertical red/white stripes, but this map has changed the textures.
That also looks a bit like the horz. color line under the sky texture.
I have been trying to identify what that sky stripe is for years.

It is likely an artifact of the renderer, dependent on what it does for broken maps.
Things like this happen when a wad is developed on one particular engine, and engine dependent tricks were used.
Looking at the wad with a checking map editor should reveal if there is a texture violation trick involved.

Deferred for now.

[Michael Bäuerle]

Looks like the textures are not missing, but they use DeePsea tall patches as explained here in the Doom Wiki:
https://doomwiki.org/wiki/Picture_format#Tall_patches
(Some tree sprites in Lost Civilization looks crippled in the same way as on the picture in the Wiki too)

I have looked at Crispy Doom and imported the attached patch for R_DrawMaskedColumn().
The other patch is for the hardware renderer.

I have used this demo WAD from Julia Nechaevskaya:
http://jnechaevsky.users.sourceforge.net/files/512x512.wad
that shows no HOM anymore for the lower part of the textures with the hardware renderer.

The software renderer still shows the colored stripes on the wall textures, but looks good now for the transparent mid texture (on the right in the demo WAD above).
The interesting part is that the software renderer (without patches) already shows the bottom part of the texture on walls (below the stripes). Not a copy of the top part as I have expected for tiling.

[Wesley Johnson]

Patched SVN 1546, 1547.
Thank you for the patches.
However, there were 10 places in the code that had to read DeePsea tall patches.
The DeePsea patch fixed the translucent draw in the demo room.

The violet horz. stripe in the texture is the DeePsea post header being drawn as pixel data.
This happens because the wall draw (software draw) expects a patch with a monolithic column, which it draws like a picture, and it tiles the wall draw using the texture height.
To fix this required generating Picture format data from the patch posts (R_GenerateTexture2).
This however replaced the patches with pictures, with black backgrounds. That affected several textures in the "lost civ" wad, causing them to become wall pictures with black backgrounds (vines). They are used both as a wall texture and in a masked draw.

This required a change in how R_GenerateTexture chooses the texture model, and how it is stored.
The wall draw now can save its own picture format textures separate from the masked draw textures. This was complicated enough that it is likely to have introduced some new bugs.
There will have to be more testing and some future patches to deal with those.

The large trees have been fixed.
The violet line in the wall textures has been fixed.

There is a large tree in "lost civ" that is still messed up, but in the width (Stand at camp fire and look at last large tree to the right.)

[Michael Bäuerle]

Thank you for adding DeePsea tall patch support!

I have first tried to patch all places in the code, but removed that part of the patchset again because it has not worked as intended for the software renderer.

Tested SVN 1547 with software and hardware renderer and the textures on walls seems to be OK now.

Also looked at the tree sprite in question: Here it looks good with the hardware renderer.
With the software renderer there seems to be a horizontal wraparound. The right part of the tree is missing and replaced with the beginning of the left part. Screenshot attached.

[Michael Bäuerle]

Tested SVN 1549 with software renderer:
The tree from Map 1 looks good now.
The rotating saw blade in the building at the start of Map 4 (needs Feature #95 and #96) is fixed too.

[Wesley Johnson]

fixed DeepSea svn 1547
fixed patch draw svn 1549