Weird chocolate doom glitch

I have been having issues with a particular map I am working on.


This pic is as it should be.



But the view changes to something like this as you move, and from various angles. Interesting, this weird glitch does not crash the game.

However, this particular map has been crashing chocolate doom due to its huge size. When you open fire in one of the areas prior to this, the level crashes without warning, which from the little I know about such things, is a blockmap issue. I have been moving far flung areas and making them more central, and shuffling areas around so they are not above/below or to the left or right of the area in question, which seems to have removed most of the crashes, except in one particular area, and this glitch has only recently popped up.

Thoughts?

I think this might be related to being too far from x=0 y=0

Possibly Long Wall Error?

Does the same thing occur in Vanilla?

Vorpal said:

I think this might be related to being too far from x=0 y=0

Yeah. Most probably this. Although I do notice that, as I go around the map removing linedefs to try and get the map within vanilla limits, what seems to happen is that the 'crash event horizon' moves further and further away from x=0 y=0 as I do so. So I gather that merely distance from a central point is not the sole factor in play. And the area causing the biggest headaches is much closer to 0,0 than many other areas which are fine.

Here is an image of the map with some details. The screens above were taken in the no man's land between where the map crashes if I fire a weapon, and where the map crashes irrespective of what I do.

http://i.imgur.com/WpqR1OI.png

Interestingly enough, the map does not crash when I am noclipping around, even in places where it will insta-crash if I take noclipping off.

fraggle said:

Possibly Long Wall Error?

Does the same thing occur in Vanilla?

Thanks Fraggle for the suggestion, but it isn't long wall error, as there are no lines long enough in this area to cause that to happen.

The same series of crashes occurs in Vanilla Doom and Chocorenderlimits, but that said, I have been unable to replicate the visual glitch pictured in the screens above. It glitched originally while in that weird death state after you take damage from nukage and then kill an alternate P1 start, (hence no weapons in the screens) but even repeated attempts at this has been unable to replicate the glitch.

Have you hit the BLOCKMAP size limit?

I've never had trouble with the BLOCKMAP limit before, so I have no idea if the symptoms match yours, but the gun firing crashes reek of collision detection bugs in my mind.

If the wall is disappearing then it could be a SlopeDiv overflow.

If you start chocolate doom with nuts.wad, -nomonsters and -warp 1, then from the start position strafe right (don't turn) eventually you reach a point where the walls start disappearing.

Is this the same effect you have?

marineController said:

If the wall is disappearing then it could be a SlopeDiv overflow.

That's possible. These and other types of overflows (mostly involving sine/cosine/tan tables) happen a lot more often than people think, but 99.9999% of the time they are asymptomatic in vanilla Doom, or result in visual glitches. In Mocha Doom, I had to emulate the same "leeway" mechanism inherent in C's memory order in order NOT to get a crash every now and then. Basically, if the tan (?) table is overread, values get read from the sine table instead.

However, the length of the map suggests that you're getting a BLOCKMAP which is longer than 256 blocks the horizontal direction. No matter how well you center it, this will give you all sorts of bugs and problems, even if the blockmap itself is generated, stored and read correctly from the WAD.

You really need a port with support for 512 x 512 Blockmaps, otherwise it will still give you problems even in many limit-removing ports. It's not enough to store a larger blockmap on-disk or in-memory, the code must be altered to support calculations with BLOCKMAP distances greater than 256 blocks.

Perhaps a Chocolate Doom port with the same blockmap extensions used in prBoom+/Mocha/ZDoom should be made? The fix is quite backwards compatible and demo-friendly.

Or you can shuffle and rotate some sections of the map so it fits better in a square. It's a mostly horizontal design here.

Overflows can make the wall appear in front of the player, regardless of where the wall actually is. It depends upon what part of the calculation overflowed. Strange things also happen in longdays.wad.

Europe.wad has a large blockmap overflow (x3) which does not generate
those kind of wall displays. Instead the player cannot interact with the walls (or sprites) outside the working blockmap.