So I have thrown together a texture pack with different bits nd pieces......

[Kyka]

...Aaaaaaand it doesn't work, and does interesting things like causing DB2 to get unhandled exceptions and crash.

So no, not so good.

Would someone mind taking a look at it for me?

Link:http://www.mediafire.com/?ay1qs6yjctxva3q

Thanks guys. :)

[GreyGhost]

Only issue I can see is the texture lumps "DUMMY" entry, if removing that doesn't help I'll take another look.

[Guest]

Thanks for having a look GreyGhost. :)

I tried making the DUMMY texture into an actual texture like AASTINKY (Just made it 64x128 and added some random texture), and this time DB2 managed to load the texture wad, though it crashed when I tried to launch a test level with it, giving this error:

W_CacheLumpNum: 1464550740 >= numlumps

Deleting the DUMMY texture entirely gave the same error.

[Vermil]

The TEXTURE1 lump seems to be corrupted?

XWE can't open it.

[Gez]

Vermil said:

XWE can't open it.

SLADE 3 can open it.

And after changing DUMMY to a potentially valid texture and saving it, it works in ZDoom (before, ZDoom said "bad texture directory" and refused to load).

[GreyGhost]

Vermil said:

The TEXTURE1 lump seems to be corrupted?

XWE can't open it.

"Read beyond end of file" error. That's probably due to the DUMMY texture's binary data being 6 bytes short.

[Maes]

From what I see, the DUMMY maptexture_t struct (with height=0, width=0) has a patchcount of 0x4F4F, which is clearly overkill (over 20000 patches? WTF?) and underflows the bounds of the TEXTURE1 lump (which is 3666 bytes!), since each mappatch_t struct is 10 bytes long.

Upon closer inspection, it's revealed that it's totally malformed: the DUMMY patch maptexture_t's entry is only 18 bytes long (while, in theory, a valid one even with zero patches should be 22 bytes long:)

//
// Texture definition.
// A DOOM wall texture is a list of patches
// which are to be combined in a predefined order.
//
typedef struct
{
    char		name[8]; // 8 bytes (8)
    boolean		masked;	// 4 bytes (12), becase "boolean" is typedeffed to int
    short		width; // 2 bytes (14)
    short		height; // 2 bytes (16)
    void		**columndirectory;	// OBSOLETE, but takes up 4 bytes anyway (20)
    short		patchcount; // 2 bytes (22)
    mappatch_t	patches[1]; // 10 bytes, but it's actually optional if patchcount=0, so minimum valid length is 22 bytes.
} maptexture_t;

Your "DUMMY" entry is only 18 bytes long which means that the unused columndirectory** pointer is read partially from the beginning of the next entry "BLOODTLE", and that patchcount value read is actually from the two "OO" bytes, hence the weird "0x4F4F" value. Of course that is bound to fuck up several things afterwards. I dunno how SLADE3 handles this (I noticed it writes the value 0x10100000 in the masked field, maybe that's a special value?)

Texture COMPTALG is also malformed: it's only 72 bytes long and therefore it should contain at most 5 patches, but it actually reads 64 as a patchcount(!) and there are probably others later on.

The only reason the standard vanilla/boom texture loading code is able to read each (or most) maptexture_t entry from the TEXTURE1 lump entirely, even with all this fucking up and nonstandard lengths, is that it contains a directory which tells it exactly where each entry begins, so even if one is malformed it won't affect reading the next ones (e.g. no partially-read texture names occur, despite the overlapping). However that doesn't safeguard against trying to interpret such malformed entries....


SLADE3 and ZDoom might load it because of (several) extra sanity checks there or silently defaulting to a "bad texture" in such cases, but Mocha and most other ports presume complete well-formedness.

[GreyGhost]

I think I've finally worked out what's wrong with that texture lump - it's in Strife format!

<facepalms>

[Maes]

Is it so different and irregular, compared to vanilla? :-S

[GreyGhost]

They discarded some unused stuff, which makes their texture definitions noticibly shorter, especially with multi-patch textures.

I wonder if Kyka forgot to tell us something. ;-)

[Guest]

GreyGhost said:

I think I've finally worked out what's wrong with that texture lump - it's in Strife format!

<facepalms>

Well I don't actually know how that is possible.

I mean when you create a new texture definition in SLADE3, the defaults are:

Doom(TEXTURE1 + PNAMES)

and

Create new (Empty)

So all you have to do is click OK.

Now I could perhaps accept that I clicked the Strife(TEXTURE1+PNAMES) option somehow once by mistake.

But I don't accept that I could have done this in all of the three times that I created this texture pack from scratch to see if that would fix the problem.

Go Figure.

[GreyGhost]

Didn't expect to encounter a Strife texture lump, that's what threw me. :D

I'll experiment with making a few texture wads in Slade over the weekend and see what happens.

[Maes]

Next time use XWE[/obvious_trolling]

[Guest]

So...

I have just tried recreating the .wad a couple more times, and both these times I managed to crash SLADE.

Steps I went through:

File > New > WAD archive.

Archive > Import files

Selected all the .png's from their directory and imported.

Archive > New > Entry to create the PP_START and PP_END

Select all the patches.

Gfx > Add to patch table.

That little options menu doesn't come up. Try same again. Nothing again.

Just for the hell of it:

Gfx > Add to TEXTUREx

Crash.

I might try reinstalling Slade I think. This gets stranger.

Could there be something wrong with the png's? [/unlikely]

GreyGhost said:

Didn't expect to encounter a Strife texture lump, that's what threw me. :D

I'll experiment with making a few texture wads in Slade over the weekend and see what happens.

That threw you? You're not the only one.

Maes said:

Next time use XWE[/obvious_trolling]

Heh.

A fair comment. I used to use XWE, it seemed like a really solid little program, but it is pretty old and unintuitive when you have Slade available these days..

[sirjuddington]

Following those steps I can't reproduce the crash at all. When I get to the 'add to patch table' step it brings up the dialog to import/create a texturex list, and everything after that works fine. What version of slade are you using? Judging by the 0x0 DUMMY texture in that wad, it's a fairly old version (I changed that to create a valid dummy texture a fair while ago)

[Guest]

It is a strange bug. It only started happening the last few days, and has never happened to me before that. I was using Slade 3.0.0 up until now. I have just downloaded and installed 3.0.2.

And having repeated the same steps, it now brings up the dialog to import/create a texture list etc.