Incredibly pointless hack WAD

http://www.doomworld.com/linguica/hax/texture2.wad

"works" in Choco, PrBoom+, ZDoom
bombs out Crispy Doom, Doom Retro

Has absolutely zero effect on the game when it "works" properly (so there is really no point in downloading this just to see the effect)

makes SLADE not recognize the texture lump, so it could function as a poor man's copy protection I guess???

TEXTURE1 texture count = -1 (actually contains 428 textures)
TEXTURE2 texture count = 429 (actually contains 0 textures)
Total texture count = 428

Read the 428 textures from both lumps.
If the counter reaches TEXTURE1 texture count, switch to TEXTURE2.
The counter starts at 0 and cannot reach -1. The switch never occurs.
All 428 texture are read from TEXTURE1.

Pointless, but was fun to work out with the source code.

*golfclap*

You could use it to dick around with the stock textures and confuse a few people when they boot up a spastic acid wonderland instead of E1M1 by hiding it in a custom skin wad or monster mod maybe?

I found some SLADE bugs with TEXTURE{1,2} handling when I tried to rename one to the other, and/or edit/delete all the textures (I was trying to modify a texture definition from doom2, and put it in a PWAD but not have to copy over all the texture definitions.) I should really file a bug.

Interesting. I could add a "sanitizer" to Mocha for it, and check actual number of entries, rather than trust the reported number ;-)

I'm a bit surprised that ZDoom's texture loader accepts this. I thought I had implemented proper checks for all error cases when I did the last cleanup on it.

Linguica said:

bombs out Crispy Doom

This is because Crispy Doom works on *all* TEXTURE1/2 lumps it finds, not just the first ones. Thus, the total number of available texture definitions is higher than 428 and the code runs into the "R_InitTextures: bad texture directory" error when (offset > maxoff). Technically, this error message is spot-on, because the texture directory is *really* bad.

I think it fails in Doom Retro as well simply because it uses my code. ;)

Sorry for late reply but this is actually a really useful bit of manual fuzz testing that allowed me to replace "xrealloc: failure to allocate 18446744073709551600 bytes" with a proper error! Thank you very much.

RjY said:

"xrealloc: failure to allocate 18446744073709551600 bytes"

One day in the future, somebody needs to test this exact game and engine on (a virtual machine in) a supercomputer capable of allocating 18 ExaBytes and see what happens to the program next.

scifista42 said:

One day in the future, somebody needs to test this exact game and engine on (a virtual machine in) a supercomputer capable of allocating 18 ExaBytes and see what happens to the program next.

:)

By then such machines will probably have 128-bit size_t and the error will become "failure to allocate 340282366920938463463374607431768211440 bytes".