Spechits overflow

The Doom Wiki article on STRAIN wrote:
MAP07: En Route is impossible to complete in modern ports such as ZDoom, as the level relies on the occurrence of a spechits overflow in order for the exit to work. There also problems with the DeHackEd patch when it is used with Doom Legacy.

This is interesting. I'm a little ignorant on the technicalities of the Doom engine, so what's a spechits overflow?

For the record, MAP07 of STRAIN features a portal-like exit structure with an 8-mapunit-wide gap behind it. The player obviously can't fit in this space so the portal's exit line cannot be triggered, at least not without clever use of noclip. The portal also uses a fancy decorative scrolling technique, one that I know was also used in a few levels of Requiem, which makes the texture appear fluid-like, and appear to scroll both left and right outwards from the center. It's a really neat effect, and one that I don't hesitate to stare at for minutes on end. X)

So what is a spechits overflow, and what did ZDoom do to fix it, thereby rendering this map impossible to beat legitimately? Bear in mind that I might not fully understand the answer, as these kinds of things just go over my head mostly, but for once I'm intrigued. :)

Also, while I'm at it, I might as well ask how a map author could achieve the fluid-like scrolling effect used on STRAIN'S MAP07's exit portal. :P

A spechits overflow occurs when you have I believe 8 or more linedef specials so close together that a player can activate them all simultaneously. I'm not sure on the specifics, but my guess is that it was some hard-coded limit that ZDoom lifted.

I think "spechits" probably stands for "special hits", as in "linedef special activations".

Oh, and the effect you're wondering about is pretty easy. You take a linedef with the scrolling special and break it up into many 1-unit segments. Then adjust the x-offsets incrementally, and voila. A texture that scrolls to the right. There is also another way of doing it, but it involves some weird method using dummy linedef of some sort.

EarthQuake said:
but my guess is that it was some hard-coded limit that ZDoom lifted.

Actually, Boom fixed it and as a result pretty much every advanced source port in existence

I think "spechits" probably stands for "special hits", as in "linedef special activations".

Correct.


Regarding this particular map, it's pretty easy to fix the mapping bug but it can't be updated in the archives because the team has prohibited to upload any altered versions of this WAD. Too bad - the installer it comes with is a piece of outdated shit.

EarthQuake said:

There is also another way of doing it, but it involves some weird method using dummy linedef of some sort.

o_O In vanilla? Tell me more, I want to hear about this. :P

I'm surprised you don't already know about this trick.

Interesting. Can you name any map editors offhand that actually allow you to change which sidedefs are referenced by which linedefs, though? I know pretty much everything allows you to change sector references, but editing sidedef references I haven't seen. o_O

Sweet. Deepsea does.

I always wondered why I would want to change the sidedef references to a linedef. Heh.
Does anyone else know of some neat tricks involving changing sidedef references?

I wonder if a similar trick could be used as a cleaner, non-damaging way to do multi-trigger switches in vanilla? o_O

edit: Aww. Unless I did something wrong, it doesn't work. It seemed like a good idea though :P

esselfortium said:

I wonder if a similar trick could be used as a cleaner, non-damaging way to do multi-trigger switches in vanilla? o_O

edit: Aww. Unless I did something wrong, it doesn't work. It seemed like a good idea though :P

I don't think you could pull that off. The only switch-related sidedef-reference trick I know about is that you can make multiple lines change texture upon a switch press if they all have the safe sidedef.

Grazza has a topic on spechits overflow (along with a list of maps that can cause it) in the demos forum if anyone is interested:

http://www.doomworld.com/vb/doom-speed-demos/35214-spechits-reject-and-intercepts-overflow-lists/


Oh yeah, and there is this topic as well:

http://www.doomworld.com/vb/showthread.php?s=&threadid=34929

Gez said:

I'm surprised you don't already know about this trick.

You should be aware that this trick doesn't work anymore if a port requires unique sidedefs like ZDoom does for its decal positioning. It will unpack them at load time so that each of the linedefs is assigned a separate one.

In addition the 'right scroll' trick is more or less useless due to the narrow limit of 64 scrolling linedefs per level. You'd reach that faster than you might think when trying to create animation tricks.

Graf Zahl said:
In addition the 'right scroll' trick is more or less useless due to the narrow limit of 64 scrolling linedefs per level. You'd reach that faster than you might think when trying to create animation tricks.

In Doom+ it's 16384, so it should be fine for Doom+ and PrBoom complevel 2 levels (limit removing vanilla).

Besides, it'd be like using the MBF sky transfer in a "Boom" level. It might not show up in ZDoom as intended, but the level would run fine.

Yeah, like many abuses of obscure glitches, it won't work on modern port. I suppose this is part of what the author of the linked wad meant with "If only this was known ten years ago people might have cared"...

Not only is it risky to use tricks based on sidedef compression nowadays, but some sidedef-compression tricks can be caused by accident. I found that I couldn't compress sidedefs in crea_one.wad because this unintentionally increased the scrolling speed of some textures when the level was played in Boom 2.02. A certain waterfall sidedef was applied to many linedefs, including some linedefs with Boom's offset-based texture scrolling. I suppose this is just a fault of Doombuilder's automatic sidedef compression, because it would have worked if the waterfalls kept their own unique sidedefs, but still. Risky.

Wait, so if a map hasn't had it's sidedefs compressed, then the trick will work? If not, what if the sidedefs were different (say textures or offsets set uniquely amongst them)?

EarthQuake said:
Wait, so if a map hasn't had it's sidedefs compressed, then the trick will work?

It's just that if you compress sidedefs they'll share attributes, and thus the effect may be applied where it was not intended. The trick is just broken (though non-critically) in ZDoom specifically (not modern ports in general) because of the modifications made to add decals, while under true Doom or Boom engines it works fine.

I still wouldn't rely on such tricks. What's the point? The only realistic motivation would be to make it work with vanilla and Chocolate Doom, both of which have the limit in place so the usability of such effects is very, very limited.

Doom+ doesn't count in my opinion.

It works on many other engines running vanilla levels, and PrBoom/+ also allows things to work with v1.9 compatiblity (-complevel 2), which is widely used by demo fans and people who want to ensure vanilla WADs behave as tested. Not using it just inhibits a vanilla possibility. It's easy to just recommend something more vanilla friendly than ZDoom in the text file.

I equated it with the sky transfer above because one may choose not to use it for additional compatibility with some engines, but can also use it, because there are many options that support it, and it's not going to cause errors or crashing in those that don't support it.

Sometimes people complain that sticking to Doom or Boom inhibits design; "why use Boom when ZDoom has so many additional features?" This goes the other way too; "why care what ZDoom does when this works perfectly in Doom and the more faithful ports?"

It's a choice by the designers, and depends on their preferences and who they aim their WAD for. As you know, some Boom WADs that combine barrels and conveyors can break in ZDoom, and there one can choose to juggle things around and make them work more or less well in both, or just recommend a more faithful Boom engine.

People who use ZDoom regularly will likely make a greater effort to make it work there, others may or may not try, depending on the effort required, what possibilities may lost ensuring the compatibility, and how much they care for other reasons.

myk said:

It works on many other engines running vanilla levels, and PrBoom/+ also allows things to work with v1.9 compatiblity (-complevel 2), which is widely used by demo fans and people who want to ensure vanilla WADs behave as tested. Not using it just inhibits a vanilla possibility. It's easy to just recommend something more vanilla friendly than ZDoom in the text file.

If you need a Boom-compatible port to get around the limit, why not use a Boom-compatible means to achieve the same thing? At least that's guaranteed to work properly everywhere. The hack as described is not even safe in all Boom-compatible engines. As soon as interpolation has to be used to get higher frame rates than 35 fps it might already show some issues.

Hacks tend to break - not only with ZDoom. In this case even careless processing with a tool that re-expands the sidedefs might already be it. So yes, if vanilla compatibility is of paramount concern - feel free to do it but expect problems elsewhere. If not: Best steer clear and research your options first.

Graf Zahl said:
If you need a Boom-compatible port to get around the limit, why not use a Boom-compatible means to achieve the same thing? At least that's guaranteed to work properly everywhere.

You don't need such a port, and the level doesn't work properly everywhere anyway.

So yes, if vanilla compatibility is of paramount concern - feel free to do it but expect problems elsewhere.

It definitely is, in a vanilla level. The only true standards for what a "vanilla level" is are Doom/+ (first), Chocolate/Strawberry Doom*, and PrBoom/+ at -complevel 2 (or 3/4). Anything else is optional and might break or alter some of the vanilla functionality in some way. Using one Boom feature in a completely vanilla level, when that feature works in vanilla directly just to make a vanilla level work in non-vanilla engines is a mistake; the resulting level isn't a vanilla level. Either use the hack, be more conservative and use only normal scrolling walls, or use Boom features more or less freely instead (aiming for a Boom level, and testing with Boom and PrBoom/+ at -complevel 9 plus any optional engines).

* I had forgotten Strawberry Doom, that is a Chocolate Doom offshoot that behaves like Doom+.

myk said:

You don't need such a port, and the level doesn't work properly everywhere anyway.

It definitely is, in a vanilla level. The only true standards for what a "vanilla level" is are Doom/+ (first), Chocolate/Strawberry Doom*, and PrBoom/+ at -complevel 2 (or 3/4). Anything else is optional and might break or alter some of the vanilla functionality in some way. Using one Boom feature in a completely vanilla level, when that feature works in vanilla directly just to make a vanilla level work in non-vanilla engines is a mistake; the resulting level isn't a vanilla level. Either use the hack, be more conservative and use only normal scrolling walls, or use Boom features more or less freely instead (aiming for a Boom level, and testing with Boom and PrBoom/+ at -complevel 9 plus any optional engines).

* I had forgotten Strawberry Doom, that is a Chocolate Doom offshoot that behaves like Doom+.

I think the point that Graf is making is that, considering that Doom's limit of 64 scrolling linedefs makes this trick just about useless in maps made for doom2.exe (as it takes 63 scroll lines to make a 64-wide texture appear to scroll in the opposite direction), instead of using that trick anyway and requiring people to use Doom2-Plus, just making the map Boom-compatible and having it work properly in the majority of sourceports instead of a very small percentage of them.

esselfortium said:
instead of using that trick anyway and requiring people to use Doom2-Plus, just making the map Boom-compatible and having it work properly in the majority of sourceports instead of a very small percentage of them.

A vanilla level with that hack doesn't require Doom+, and making it "Boom compatible" just for that is like making a vanilla level and then sticking a particle fountain somewhere in it. Also, it's false to say the trick will only work in a "small percentage" of ports.

I'm with Myk on this. There is a certain glory in creating elaborate tricks and exploits in the original engine, no matter what this does to the wad's compatibility. I'm surprised that Essel isn't more enthusiastic about this trick, considering that exploiting the vanilla engine at the expense of possibly all others is KDiKDiZD's mission statement.

But yeah, if you made a map that used this trick and required Doom+, that would be silly.

The Doom+ patch is as vanilla as DeHackEd is (both being less vanilla than the plain unmodified engine, but still of the same executable). It merely changes something else.

But if you want to use this trick, you can only use it on a line that's 64 units long and then not use any other scrolling lines anywhere else in the map. I guess it could be used on shorter lines, but the trick isn't omg wow amazing enough by itself to really stand out enough to matter. IMO, at least. If you have some crazy incredible usage for it, then by all means go for it, but in most cases it just doesn't seem like it'd be worth the cost.