Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  

Doom64 EX: texture and flat number

Recommended Posts

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?

Share this post

Link to post

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.

Share this post

Link to post

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.

Share this post

Link to post

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

Share this post

Link to post

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.

Share this post

Link to post

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?

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this