Maes
I like big butts!
Posts: 10313
Registered: 07-06 |
While trying to repackage some old, notoriously problematic megawads/TCs (Quest for the Necronomicon, Obituary), a common problem I stumbled upon was that both had malformed texture lumps that contained characters beyond the null terminator mark, see example here:
http://www.doomworld.com/vb/showthr...630#post1001630
In that case, a certain texture "YELMIX" was actually stored in the TEXTURE1 lump as "YELMIX 2", where the "space" was actually the null terminator. This problem was present on several textures, and in the case of Quest for the Necronomicon, also in many patch names referred by textures.
When the "YELMIX" texture is recalled from a linedef, most modern source ports (prBoom+ and ZDoom did this) seem to bomb on the grounds that they can't match "YELMIX" with "YELMIX[null]2" with a string comparison (and similarly for other textures). The problem can extend to patches and floors in a similar way.
Yet, vanilla Doom obviously had no problem using the malformed entries with either TC.
My theory is that this is due to how string comparisons are performed in the DOS .exe (fully left-to-right scans until the first null terminator, so the bogus/trailing text is ignored), while modern source ports use modified/optimized string comparisons which however are fooled into believing that strings mismatch (due to encountering valid characters beyond the real, left-most null terminator).
Now, Chocolate Doom in particular, since it's aiming at reproducing the DOS executable's behavior as closely as possible, should probably implement a string comparison function that is guaranteed to behave like the DOS one (e.g. perform no optimizations like starting from the end of a length-limited comparison).
Since texture name matching is done in R_CheckTextureNumForName (char *name) the "offending" library function should be strncasecmp, used as follows:
code:
if (!strncasecmp (textures[i]->name, name, 8) )
Now, in some optimized implementations this might return a false negative on two strings "YELMIX[null]2" and "YELMIX", since it will attempt starting from the 8th character, while unoptimized ones will correctly give a positive. At least that's what I'm imagining.
What's more disturbing is the knowledge that there probably are more such modifications out there, plagued by the same problem which went under the radar for years, which can only be fixed by cleaning up the TEXTURE1 lumps, renaming patch and floor names manually or by making source ports tolerant/modifying their string comparison functions.
Last edited by Maes on 08-15-11 at 19:05
|
08-14-11 00:27 
