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

Texture FUBAR

Recommended Posts

Why is it at a certain number of textures in TEXTURE1 and PNAMES that the wad suddenly screws up all the textures? Do I have to add a new texture file?

Share this post


Link to post

I don't know of any set upper limit for textures or patches, how many do you have in your wad?

Share this post


Link to post

Unless you have a ridiculous number of textures/pnames entries, then no, you haven't hit a limit or anything. What editor are you using?

Share this post


Link to post

Been using XWE as Slade keeps crashing. I have hit a number where it sends textures funny. When I add a new patch it sends the texture files up the wall, several textures like the ROCK textures and MODWALL get screwed up.

I have quite a lot of textures. If I add any more patches it will screw up the texture file, I made a backup and saved my work before the problem.

What happens is the name of the patches in the texture file for each texture gets messed up.



See? That happens. By adding one PNG to PNAMES and then TEXTURES it screws up all the rest. What's going on?

PS I do have a ridiculous amount of textures as flats have somehow become textures in doom builder and vice versa. I also intend to have many more textures as well.

Share this post


Link to post

I have 1098 custom textures in the megawad I'm working on but I don't have Slade. Do you have more than that? [edit] Tho I'm not using .png's so maybe that's a problem with so many?

Share this post


Link to post

You may have corrupted your PNAMES lump or something. If you built your TEXTURE1/PNAMES lump in SLADE/SlumpEd and then edit it in XWE, it will screw it up (or is it vice-versa?). Either way, it looks like that could be a possibility.

Share this post


Link to post

It's some retarded xwe bug that happens all the time. No clue what causes it but it's a pain in the ass and it tags random letters and underscores at the end of texture and patch names

Share this post


Link to post

Thanks, I figured as much it might be. I'll try Slumped and see if its any better.

EDIT:

Nothing happened, it added as a texture and pname no problem in Slumped. Must be XWE, thanks for the help everyone!

Share this post


Link to post
Mechadon said:

You may have corrupted your PNAMES lump or something. If you built your TEXTURE1/PNAMES lump in SLADE/SlumpEd and then edit it in XWE, it will screw it up (or is it vice-versa?). Either way, it looks like that could be a possibility.

If you use SLumpEd then XWE, it will screw up.

If you use SLADE then XWE, it will not screw up, because the SLADE developers are perfectly aware of XWE's failings and compensate for them.

Ralphis said:

It's some retarded xwe bug that happens all the time. No clue what causes it but it's a pain in the ass and it tags random letters and underscores at the end of texture and patch names


Here's what happens. Doom and SLumpEd are both coded in C. (Well, Slumped is in C++, but whatever.) XWE is coded in Delphi, a variant of Pascal. The C family and the Pascal family are very different on certain points.

In the C family, strings are " null-terminated", that is to say, a character with a value of 0 marks the end of the string. In Delphi, that's not the case. Instead, strings have a separate value that corresponds to its length. Let's take the string STARTAN3. In C, it will be written this way (using \ to represent a literal value rather than the value of the corresponding ASCII character):
STARTAN3\0
That's nine characters in total: eight for the string, and one for the delimiter.
In Delphi, it'll be written that way in memory:
\8STARTAN3
That's also nine characters in total, but the first value is not a character, instead it's the number of actual characters in the string. And there are no delimiters since it's not needed as we have the length.

Okay, so now we know the magic voodoo that happens behind the scene. What is the problem with XWE, then?

Simple. When reading records from files, Slumped and Doom know that a texture (or patch, or whatever) name is at most eight characters. So it creates a nine-byte string (remember, there's one more for the delimiter), reads into it the eight characters from the record, and puts the value of the ninth character to 0. When XWE reads a record from a file, it also knows that the length is at most eight character. So it creates a nine-byte string, writes 8 for its length, then copy the characters it reads from the record.

And this is where it breaks. What happens if a string is shorter than eight characters? For example, it's SW1S1? The record is still eight bytes. They can't be variable size as it'd have made the loading routines far too complex and inefficient. Since the delimiter is 0, it's very simple: just write a 0. SW1S1\0. That's six bytes, there are still two more bytes in the record, they could be anything, Doom won't care because when reading the string it'll find a null terminator in the sixth position and cut the string there. Suppose that what comes after it is random garbage because the area of memory had not been zeroed out before writing the data? Well, it still works. Woohoo!

But XWE is not so lucky. It reads these six characters but it was told there would be eight, so it continues. A zero? You can't print a null character. How odd. But there are still non-zero values after wards, so let's replace it with a space (value 32). Now, what were the next two characters? Oh yeah. "¨P". That really looks like it's part of the patch name. Okay, so this texture uses the patch SW1S1 ¨P. Yay! Let's save it that way, with a real space rather than a null character so it's clear that it's what was obviously meant.

Now, here comes Doom again. It reads the record, and doesn't find a terminator until the 9th byte (the one that's manually added by the loading routine), so instead of loading SW1S1 it loads SW1S1 ¨P. Yeah, thanks XWE.



SLADE does not cause this bugs because before writing string records, it takes care to zero out all the bytes after the end of the string. That way, XWE will not think that it's an error since there aren't more characters after, and it won't replace them with spaces.

Share this post


Link to post

Oh good, I guess I don't have to worry about that nearly as much since I use SLADE almost exclusively now. Not to mention that SLADE's TEXTURE1 editor is pretty much the best one around, so there's really little reason to use XWE for that. I wouldn't touch a TEXTURE1 lump with a 100-foot pole in XWE since the last time I had this bug ruin my day.

Share this post


Link to post
Alphawolf said:

By adding one PNG to PNAMES and then TEXTURES it screws up all the rest. What's going on?

Didn't happen to me, check that you have only one PNAMES lump.

Share this post


Link to post

Thanks gez that was interesting to read and to see what is happening behind the scenes.

Didn't happen to me, check that you have only one PNAMES lump.


I did it just reached a limit.

Now, here comes Doom again. It reads the record, and doesn't find a terminator until the 9th byte (the one that's manually added by the loading routine), so instead of loading SW1S1 it loads SW1S1 ¨P. Yeah, thanks XWE.


The pnames size right before adding one more pname was 6.82 Kilobytes
The textures size right before adding one more texture was 36.73 Kilobytes.

Is this the limit XWE reaches before this effect happens?

Anyway I've solved the issue by simply using Slumped. I copied over my maps into a backup wad I had and no problems. Anyone reading this who has this problem just follow the same solution!

And thanks everyone.

Share this post


Link to post
Alphawolf said:

I did it just reached a limit.



The pnames size right before adding one more pname was 6.82 Kilobytes
The textures size right before adding one more texture was 36.73 Kilobytes.

Is this the limit XWE reaches before this effect happens?

By way of an experiment I merged four of the largest texture wads at my disposal (each of which exceed the "limits" you encountered) in XWE without running into any problems. I can only conclude that your copy of XWE has turned moody and decided it doesn't like you, your PC and/or something you did.


(880x640 - 30k)

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  
×