Doom64 EX: texture and flat number

[Maes]

I'm currently working on a map parser/converter of sorts, and noticed in SLADE3 that the ceiling/floor texture names in SECTORS as well as the Upper/Lower texture values in SIDEDEFS have been replaced by numeric indices.

OK, no biggie, since the Doom64 EX bible does say that those are supposed to be indices into the texture/flat list implied by the T_START and T_END lumps. Perfectly understandable.

According to SLADE3, there should be 354 texture lumps in DOOM64.WAD (indices 969 to 1322) and 149 flats (indices 1323 to 1471), so I would expect to find only numbers between 0-353 for textures (if the numbering is 0-based) and 0-148 for flats.

However, many of the indices encountered in SECTORS and SIDEDEFS have values that go well beyond any reasonable interpretation, like 5862 for a ceiling texture, or 7988 for an upper texture. These can't be safely interpreted either as indices into a 0-based table for textures/flats, nor as IWAD table indices.

The Doom 64 bible document isn't more specific at this point:

The lump names of the textures are not actually referenced in Doom 64. Instead they are looked up as
indexes based on the order the lumps between the T_START and T_END markers.

without hinting at e.g. interpreting part of the read value as a flag or attribute.

Does anybody have any extra info on that?

[Gez]

Doom 64 uses indices, but Doom64 EX changed them into hashes. The rational for that change is that it makes it much less of a headache to figure out how to handle index ranges for when you're loading a mod that contains both new and modified textures... A consideration that, obviously, was never relevant for the original Doom 64 on console, but definitely is for an enhanced PC port.

Here's the hashing algorithm, as copied from SLADE's code which I had conveniently open:

/* ResourceManager::getTextureHash
 * Returns the Doom64 hash of a given texture name, computed using
 * the same hash algorithm as Doom64 EX itself
 *******************************************************************/
uint16_t ResourceManager::getTextureHash(string name)
{
	char str[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
	for (size_t c = 0; c < name.length() && c < 8; c++)
		str[c] = name[c];

	uint32_t hash = 1315423911;
	for(uint32_t i = 0; i < 8 && str[i] != '\0'; ++i)
		hash ^= ((hash << 5) + toupper((int)str[i]) + (hash >> 2));
	hash %= 65536;
	return (uint16_t)hash;
}

So create yourself a hash table of 65536 lump names, add all flats and textures to it using the above algorithm to compute their position in the table, and then you have everything you need for your utility to read Doom64 EX's maps.

[andrewj]

Looking at the Doom64EX source code, the texture numbers are used unaltered from the sidedef or sector (i.e. no bits are used as flags).

P.S. ninja'd -- I remember now about the hashes, never understood the reason for it though.

[Maes]

Thank you Gez! I'll give that a try. Well, I wondered how someone could map/mod for Doom64EX and remain sane when adding new textures, deleting some, shifting them around etc. with the numbers constantly changing O_o

[Blastfrog]

I wonder why Kaiser didn't go with plain old texture names in EX.

Huge thanks, Gez, this utility is going to be incredibly useful. If you're curious, it's to address this issue.

[Maes]

Well, the hash function works as intended. However, I wonder if a hash/key space of just 65536 values won't cause problems, sooner or later, since it is much smaller than the namespace of 8 character strings, even with Doom WAD format limitations. What happens if two completely differently named textures end up having the same hash? How can one disambiguate between the two? Or are such collisions resolved at map creation time by e.g. forcibly renaming some of the textures?