Patch texture composition logic errors
Doomsday's Patch texture composition does not replicate the logic of the id tech 1 column/post based software renderer. In the original renderer posts are automatically enlarged to encompass the full range of a Patch column. Therefore the actual dimensions of textures in the Textures namespace aren't necessarily the same as those defined in (say) the TEXTURE1 lump, the real dimensions are only known once the texture image is composite is built.
Looking at the code it would appear we already have some logic which attempts to do this with composites bound for use on the sky dome. However, the logic there is flawed also because the logical dimensions of the texture remain the same and only the dimensions of the uploaded image are adjusted.
See the attached test WAD for a concrete example of the failure case.
#3 Updated by danij about 11 years ago
#4 Updated by danij about 11 years ago
Further investigation revealed that there is in fact two issues here. The first being that the prepared image is not expanded as described in the initial report. The second is that the logical Material dimensions similarly need to expand to match the Texture as these are what determine the relative origin of middle textures on two-sided lines.
One solution would be an observer pattern -like mechanism (i.e., signals & slots in Qt parlance) whereby Materials are automatically notified when a Texture's logical dimensions change. Obviously this is too radical for the imminent Doomsday v1.9.9 release (material_t is but an opaque C struct presently) however it should be addressed early on for 1.9.10