What's wrong with XWE?

[TheDoomGuy]

I've been out of the loop for a few years, so bear with me and my ignorance.

Just out of curiosity... I've heard a lot of people talk about how XWE is bad, and how SLADE is the go-to tool for editing. What's actually wrong with XWE? I've tried using SLADE, but I actually find it confusing, as opposed to XWE which I've always found fairly simple and intuitive. Is the difference actually that great that it's worthwhile to learn how SLADE works?

[wildweasel]

A lot of the problem with XWE is in the back end. It always saves changes to the wad immediately, and if I remember correctly, there's no undo function in a lot of cases. It's entirely possible to wreck your project, especially due to a persistent unfixed bug that corrupts the file if it's accidentally opened more than once. It's just too risky to continue using.

While SLADE is certainly not bug free, I find it much more stable, with better and more reliable tools for sprites, actual Zip support, and nicer editors for things like the Textures lump.

[cocka]

Is the difference actually that great that it's worthwhile to learn how SLADE works?

Just a few examples among many others:

1. Extract a texture from TEXTUREx lump to a png file. How would you do that in XWE? No way.

2. Once it completely erased the content of my wad, from then on.. I wouldn't use it at all.

3. You cannot open more than one files at once.

4. As far as I know it doesn't support pk3s.

[Blox]

It always saves changes to the wad immediately. It's entirely possible to wreck your project, especially due to a persistent unfixed bug that corrupts the file if it's accidentally opened more than once.

It's funny you mention that, because it sounds very much like the cause of the bug is writing the file as you close it and open a new file.. Which is the one you're writing, which would cause an access error to both ends and ending up with an empty file. (You can replicate a situation like that by using SoX and have the input and output filenames be exactly the same file.)
The fix to that would of course be checking if the currently opened file is in fact, the one currently open and aborting the attempt to read the file, but who would do such a thing?

[koopanique]

Is the difference actually that great that it's worthwhile to learn how SLADE works?

Yes. Recently (like, one month ago) I was still using XWE because I was so used to it, and like you I tried Slade but it confused me, so I went back to XWE.
Slade is not that complicated, and it's a matter of minutes before you understand how it works. Once you're used to it, it can do everything XWE does but better and without corrupting your files one action out of ten. Plus it has features that XWE doesn't have that you cannot live without once you've tried them (automatic offset placement, automatic conversion for large group of textures, .png support, etc).
So yeah, I'd say it's completely worthwile to learn Slade and drop XWE.

[Lysander]

Ahh, thanks guys. Well, you've convinced me.

[HavoX]

If there's one thing XWE can do that SLADE can't, it's the ability to edit the ENDOOM screen.

Seriously, why hasn't this been implemented into SLADE yet?

[edward850]

Seriously, why hasn't this been implemented into SLADE yet?

Because nobody has implemented it yet. The question answers itself, seeing as code doesn't magically write itself.

[Athel]

What's wrong with XWE?

XWE = Xtreme Work Eraser

...that is all.

[ReedtheStrange]

It eats your stuff and crumples it. It can also cause issues that you might not notice until you're far into working on your stuff. Particularly with textures.

[phantombeta]

If I recall correctly it also does things like this to lump names in WADs: ("\0" means NULL.)
"LUMP\0a8t" ("a8t" are garbage bytes)
While it should do this:
"LUMP\0\0\0\0"
Doing what XWE does can break other programs that read WADs. (Granted, you should just stop reading at the NULL byte since I believe it's supposed to be a C style/NULL terminated string, but...)

[Gez]

XWE is written in Pascal (more precisely, Delphi, IIRC) which natively uses sized strings. An eight-character strings is represented by nine bytes, the first being the value "8" for the length of the string. The standard C/C++ libraries use zero terminated strings: we still have one more byte than character, but the last one is at the end (not the start) and it is the value 0. Both approaches have their own merits and drawbacks (e.g. in C you have to parse the entire string to find its length, in Pascal you can't have a string longer than 255 characters) and in both cases for serious string manipulation you have to use better tools than the standard strings. Doom itself is no stranger to weird string bugs.

Anyway, that's why XWE will ignore zero values in short lump or texture names and continue reading the garbage bytes that come after. The real problem is that it turns the zero values into spaces (which is ASCII is actually value 32). However, it's not a problem in XWE by itself, the problem happen when XWE is used in conjunction with other tools which allow garbage bytes to exist instead of fully zeroing everything. SLADE 3 zeroes everything for this reason.

Honestly the main reason not to use XWE is that it's old and unmaintained, and increasingly hard to get working on modern Windows systems.

[GooberMan]

Further, reading a string off disk isn't as simple as "stop at the terminating byte". For example:

Code: Select all

struct Lump
{
  int offset;
  int size;
  char name[ 8 ];
};

Lump* lumps = new Lump[ numLumps ];

fread( lumps, sizeof( Lump ), numLumps, pFile );

Reading a WAD's TOC off disk doesn't need to be any more complicated than that.

[phantombeta]

I meant it as something like this:
1. Read offset and size.
2. Read until 8 bytes read or NULL byte read.
2-1. If 8 bytes read, repeat.
2-2. If not, skip the amount of useless/garbage bytes after the NULL byte then repeat.
(You could also read 8 bytes and then remove any garbage bytes before using the lump name for anything...)

[GooberMan]

The bracketed version you mention there would be the correct way to deal with a faulty XWE-produced WAD. Disk reads aren't the cheapest operation, it's far easier to deal with something once it's in memory than to read something byte-by-byte of disk (including the logic to support it).