Mysterious vanilla venetian blind crash

[Xaser]

Whelp. Between PRCP and DTWID, I've lately become somewhat decent at debugging wads for vanilla errors n' things. But now I've run into one that's completely eluding me. :(

This wad contains a couple of maps which cause a venetian blind crash at the start of the map, and I can't figure out why. I'm pretty sure that E3M7 breaks a bunch of vanilla limits (the point is that I'm trying to fix that :P), but I know for a fact that E2M5 is within the usual bounds, as oddly enough I've had it work in Chocolate Doom sometimes when exiting from the previous map. Warping to it, though, always makes the engine go boom.

Any vanilla-engine experts out there able to help out with this? I can't even get a crash message because of this (Chocolate doom just aborts with no error) so I can't tell at all what sort of apparent wonkiness is causing this sort of thing. If Chocolate's got a hidden debug mode somewhere or something with some better output, that'd be grand.

Sorry for the size of the wad, by the way. Lots of new textures. :P

[EDIT] Now that the problem's been solved, I've taken the wad down. Why? Spoilers. ;)

[Kira]

Did you try Chocorenderlimits?

[myk]

Not sure what the issues are but both run in Doom+ and both crash to DOS at startup with regular Doom. You could always patch copies of the engine with all but one of the limits that cause crashes raised. Testing with those would expose which limit is being hit. The critical limits in this sense, I think, are the last two (lineanims and openings).

By the way, in E3M7 the BLOCKMAP is 63.8 KB, and the maximum is 64 KB. Not sure if that blockmap is compressed. If not, you'll be able to get some additional leeway by compressing it. (ZenNode compresses it by default.)

[Maes]

I'll pass it through the magic of Mocha, and see how it fares....

Edit: the beginning of E3M7 gets a vissprite_t overflow warning but that's it. For the rest, both maps load and play apparently fine...but then again Mocha includes so many more safeguards during load time, that it's actually harder to crash with malformed maps. Plus I've removed debugging/warning prints for most of them, so I'd have to go by "gut" on this one.

Edit2: nothing atypical, other than E3M7 having a very large BLOCKMAP by vanilla standards (500500 bytes, due to 2002 sectors present). Still, loading is completely dynamic and that shouldn't be a problem ;-/

[_bruce_]

The look of the beginning of the e3m7 map is awesome... haven't seen such a cool look in a long time.

[myk]

I tried what I suggested above and the limit you are breaking in both levels is MAXLINEANIMS.

http://doom.wikia.com/wiki/Excessive_scrolling_texture_overflow?&cb=64

[Maes]

Heh indeed I had hardcoded this to a higher value (2048 but not made it totally adaptable) and so got no ill effects.

[Xaser]

Ah! Thank you very much, myk -- very strange. Didn't even realize this particular limit existed... either way, it works now. Much obliged, sirs. ;)

The page describing the effect doesn't seem to exist on doomwiki.org though. Probably needs a port away from the evil wiki... ;P

[NaturalTvventy]

wot sort of garabage is dis? thez WADS are noob suxor 2 teh max trollolololololol!

[Gez]

Xaser said:

The page describing the effect doesn't seem to exist on doomwiki.org though. Probably needs a port away from the evil wiki... ;P

What do you mean? http://doomwiki.org/wiki/Excessive_scrolling_texture_overflow :p

[printz]

Couldn't they have just made Doom quit to DOS instead of allowing undefined corruptive behavior?!

Scratch that; I now wonder what kind of data you can hack controllably by doing this abuse in vanilla Doom: if it allows implementing effects not normally possible.

[Gez]

Yes they could. Of course they could.


They just would have needed to have an approach to programming where they constantly assume that something is going to go wrong at every step of the program and stuff the game code with boundary checks and sanity checks.

They loved their static arrays for stuff and presumably only added checks when they ran into bugs while developing. Overall, they had a very "640 kb should be enough for everyone" approach. After all, the primary purpose of the Doom engine was to let people play the Doom levels that went with the game; not to be a generic game engine for a virtual infinity of user-generated levels played for two decades after release.

[_bruce_]

Gez said:

Yes they could. Of course they could.


They just would have needed to have an approach to programming where they constantly assume that something is going to go wrong at every step of the program and stuff the game code with boundary checks and sanity checks.

They loved their static arrays for stuff and presumably only added checks when they ran into bugs while developing. Overall, they had a very "640 kb should be enough for everyone" approach. After all, the primary purpose of the Doom engine was to let people play the Doom levels that went with the game; not to be a generic game engine for a virtual infinity of user-generated levels played for two decades after release.

Fully agree.