SLADE Discussion - Latest: v3.2.6 (28/May/2024)

[Gez]

This is what SLADE3 does. It looks like the doom64 sprites are passing the 'doom gfx' data format test somehow, even though they aren't. I'd need a sample d64 sprite to fix this properly

Check your private messages.

[Wh1tefang94]

I really love Slade but I've been having a major issue for some reason that i don't know, It converted my text files to sprites (that crashed the game on even trying to look at them), then another time it "converted" everything to "sprites" that crash the editor, i had to completely reload all my files into the mod and remake my decorate luckily there wasn't much in the wad yet.

[sirjuddington]

That certainly shouldn't happen. You didn't put those entries between S_START and S_END did you? (or in the 'sprites' directory if it's a pk3). Beta 1 has a bug where any entry with an unknown format between special markers will be detected/opened as doom gfx.

[Gez]

When can we expect Beta 2? I tried to compile but wxWidget isn't being cooperative.

[sirjuddington]

Soon. I'm in the middle of rewriting how entry type detection works - once that's all up and running I'll release beta 2, and possibly update the website

[Gez]

Good to hear.

If/when the TEXTUREx editor comes back, I've found a good test case to check its robustness: the SKY1 to SKY8 textures in pleiades.wad. They crash Slumped.

This is from a comment in ZDoom's multipatch texture code:

Code: Select all

	// [RH] Some wads (I forget which!) have single-patch textures 256
	// pixels tall that have patch lengths recorded as 0. I can't think of
	// any good reason for them to do this, and since I didn't make note
	// of which wad made me hack in support for them, the hack is gone
	// because I've added support for DeePsea's true tall patches.
	//
	// Okay, I found a wad with crap patches: Pleiades.wad's sky patches almost
	// fit this description and are a big mess, but they're not single patch!

[sirjuddington]

Beta2 is up now, which fixes a bunch of issues from beta1, and has a new entry type definition/detection system. Grab it from the first post

View the changelog here

[Gez]

Doesn't crash anymore when encountering weird data types (like the sprites in this old doom64.wad -- they're not PNG, as I've found out, they were made by a previous version of Kaiser's wadgen), so I can browse DOOMPRES.WAD without it crashing. Won't display the files, since the format is a bit different, but won't crash. Yay!

Browsing through the Circle texture resources, it identifies correctly the files as BMPs, but then when clicking on one says that "the entry is not a known image format". Which is odd because Beta 1 does display them correctly.

That is for now the extent of the trick tests I can do. I'd have tried JAGDOOM.WAD as well, but it's not the same endianness anyway.

[Cutmanmike]

I've still been using slumped but I'll try this version tonight and see how things go

[Gez]

Just thought of something. When converting image file in a zip or pk3, say from BMP to PNG, it would be nice if the extension was changed accordingly and automatically.

Another thing: when converting paletted pictures, it would be great if it were possible to choose the color index to be made transparent. At the moment, we can choose the color, which isn't always what one would want (e.g., if two or more palette indices correspond to the same color, choosing that color as transparent will affect all these palette indices).

Just noticed the TEXTUREx editor is back again, though not usable yet. It still crashes when looking at Strife's TEXTURE1 lump. The format is slightly different as they removed unused fields. Here's the relevant ZDoom code to show the differences:

---

Code: Select all

//
// Each texture is composed of one or more patches, with patches being lumps
// stored in the WAD. The lumps are referenced by number, and patched into
// the rectangular texture space using origin and possibly other attributes.
//
struct mappatch_t
{
	SWORD	originx;
	SWORD	originy;
	SWORD	patch;
	SWORD	stepdir;
	SWORD	colormap;
};

//
// A wall texture is a list of patches which are to be combined in a
// predefined order.
//
struct maptexture_t
{
	BYTE		name[8];
	WORD		Flags;				// [RH] Was unused
	BYTE		ScaleX;				// [RH] Scaling (8 is normal)
	BYTE		ScaleY;				// [RH] Same as above
	SWORD		width;
	SWORD		height;
	BYTE		columndirectory[4];	// OBSOLETE
	SWORD		patchcount;
	mappatch_t	patches[1];
};

// Strife uses versions of the above structures that remove all unused fields
struct strifemappatch_t
{
	SWORD	originx;
	SWORD	originy;
	SWORD	patch;
};
struct strifemaptexture_t
{
	BYTE		name[8];
	WORD		Flags;				// [RH] Was unused
	BYTE		ScaleX;				// [RH] Scaling (8 is normal)
	BYTE		ScaleY;				// [RH] Same as above
	SWORD		width;
	SWORD		height;
	SWORD		patchcount;
	strifemappatch_t	patches[1];
};

Also, pleiades.wad's TEXTURE lump provokes this error window before crashing:

Code: Select all

Stack Trace:
0: RtlAnsiStringToUnicodeString()
1: TpDisassociateCallback()
2: TpDisassociateCallback()
3: RtlEnumerateGenericTableWithoutSplaying()
4: malloc()
5: operator new()
6: ()

Don't even try to look for one of the messed up sky texture, just opening that lump is enough.

[Karnizero]

Downloading and testing.
Will give feedback when I fully test it out.

Cya.

[Gez]

Okay, this is awesome.

---

TEXTUREx identification works great now. Now clumsy workaround with file name, and I even got it to recognize the nameless format used in Doom alpha 04.

What it needs now is to be more reliable in its identification of the alpha and beta graphics. When they aren't totally disabled, it tends to see them everywhere.

[sirjuddington]

Nice, be sure to send me a patch or something for that And yeah, the problem with the alpha gfx format is it's too simple - and therefore pretty hard to detect correctly.

[Gez]

I sure intend to!

I tried an approach where it seeks to validate the texture in detectDoomGfxAlpha()/detectDoomGfxBeta(): verify that it ends on a FF, and that the last pixel of the last span is still within the boundaries set by the size. I must have done something wrong though because now it doesn't identify them at all anymore (except for three patches total). So I'm just finetuning things and looking how it fares with the alphas, beta, and various random wads or pk3s.

By the way, a little annoyance:

---

When debugging in VC++ 2005, I get this error messagebox: "Windows has triggered a breakpoint in Slade.exe. This may be due to corruption of the heap, and indicates a bug in Slade.exe or any of the DLLs it has loaded. The output window may have more diagnostic information." The point in the code where it points to is "delete pal" in GfxEntryPanel::updateImagePalette(), but it occurs actually quite a bit above (or below) that in the system dll:

Code: Select all

 	ntdll.dll!76f88b2e() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	ntdll.dll!76ff162b() 	
 	ntdll.dll!76fda6d7() 	
 	ntdll.dll!76fc24d0() 	
 	ntdll.dll!76ff267f() 	
 	ntdll.dll!76fbb7cd() 	
 	ntdll.dll!76fa7512() 	
 	ntdll.dll!76fa7545() 	
 	msvcr80.dll!75324c39() 	
 	msvcr80.dll!75324c58() 	
 	ntdll.dll!76fa7512() 	
 	ntdll.dll!76fa7545() 	
 	kernel32.dll!76b49a26() 	
 	msvcr80.dll!75324c58() 	
 	msvcr80.dll!75324c58() 	
 	ntdll.dll!76fa7545() 	
 	kernel32.dll!76b49a26() 	
 	msvcr80.dll!75324c39() 	
>	Slade.exe!GfxEntryPanel::updateImagePalette()  Line 223 + 0xd bytes	C++
 	Slade.exe!GfxEntryPanel::loadEntry(ArchiveEntry * entry=0x02b4f788)  Line 154	C++
 	Slade.exe!EntryPanel::openEntry(ArchiveEntry * entry=0x02b4f788)  Line 128 + 0xd bytes	C++
 	Slade.exe!ArchivePanel::openEntry(ArchiveEntry * entry=0x02b4f788)  Line 577 + 0xc bytes	C++

This doesn't happen when run normally, only when debugging. I'm not sure if it is fixable given the issue appears to be within ntdll.dll.

[Shadelight]

Will SLADE3 support converting sounds to Doom WAVs?