Limit-removing ports be damned

Limit removal per se is not to blame here. Both crispy and prb have a lot more features than just chocolate doom without the visplane limit. Both incorporate some enhancements that reduce slime trails and such. Sadly it seems to break my effect somehow. DOS Boom renders it properly when it feels like it, which is why I think these enhancements come from MBF. Also Doom Legacy renders it properly, and that thing was mostly developed before MBF.

Haven't tried it but this might work:
doomwiki.org/wiki/Chocolate_Doom_Plus

Or you could just use Doom Legacy as mentioned.

Yeah I get you.

From what I can tell, the static limits are just defined in the code as numeric constants, so in my understanding, you could take the sprinkled Doom source code, find the place where the limits are defined, edit that to a really big number, then recompile.

The two limits that lead to a crash, visplanes and openings, are defined in r_plane.c. Also all the limits are multiplied by coefficients found in dpplimits.h. So in theory you only need to edit that dpplimits.h file.

But if it was that easy, maybe the authors would've done that already, so I really don't know, maybe if you set the limits too high, you run into some other overflow. I'm not a programmer, just speculating.

Also some limits are harder to remove afaik, such as the seg/blockmap/whatever ones. But by the time we get there, we're talking maps like Planisphere or Voodoo Guns, so that's not as pressing.

github.com/atsb/chocolate-doom-plus-plus/blob/master/src/doom/r_plane.c
github.com/atsb/chocolate-doom-plus-plus/blob/master/src/dpplimits.h

Sprinkled Doom did that, but apparently one needs better algorithms for port to function as limit-removing. Else it can be brought down to the knees while within limits it "raised".

Yes the wording "limit-removing" is a bit inaccurate, but most of the time it does the job, so w/e.

Generally when it matters (large maps like planisphere), it's indicated that a "proper" limit-removing port is necessary. For example Voodoo guns says an "advanced" port is required.
www.doomworld.com/idgames/levels/doom2/Ports/v-z/vg

You misunderstand what complevels are for. The complevels are only meant for demo compatibility, nothing more. It's not meant to reproduce visual effects. It's not an offense to anything, it actually does its job perfectly: if you record a demo in a map with the horizon effect, the effect wouldn't show, but the demo would stay in sync if you played it in vanilla doom.exe. Same for sky transfers or whatever. It's why speedrunners use prboom+. Once again they are not intended to fully replicate the behaviour of the targeted executable, only to produce demos compatible with that exe. We can cry about it all day but supporting a weird nodebuilder visual hack was never the intention.

Also don't forget that prboom has seventeen complevels. Imagine having to support the rendering of each of those executables too!

To follow up, my yelling about complevels is basically frustration with doomworld community in general. For some years before I knew about doomer boards, I visited that crap website daily. There were also some years of interruption. Initially, I didn't hate people who like Boom. But once the forum lost Post Hell, and Doomworld became toxic, that really poisoned my attitude towards what people like there. I started to hate them because I witnessed them expressing vitriol towards some poster that didn't, in my view, deserve it, and my discontent with that became attached to those people and things they like.

It also coincided with the fact that in some overlapping timeframe, I used Choco only, which thus became sacred to me.

The fun of actually playing Doom - rather than playing for the sake of proving to myself I'm not inferior to people (via beating this or that map) on the website I never registered on (Doomworld) - has started only when I came to doomer boards. And yet some people call doomer boards toxic, and doomworld as being improved rather actually becoming toxic over the last years. I genuinely don't get it.

Well that was general ruminations, on how lurking on a toxic community such as doomworld can lead to all sort of irrational but entreched beliefs or dogmas.

Aha. I just realized that fixing slime trails could indeed be related, another clue (since I'm thinking of also make VigilantBSP support generation of Zdoom extended nodes, which are supported by Crispy and PrBoom-plus, and support for generating DeeP nodes was already implemented in VigilantBSP since original release) is that Zdoom extended nodes don't have angle and thus can't possibly support this effect.

Naturally, the two together would be convenient to implement if seg's angle is always ignored (no matter what nodes format is used) and instead angle is computed, possibly with even greater precision than vanilla engine could allow, by the "limit-removing" engine. Or maybe rendering doesn't even need that angle anymore even as temporary computation, whatever.

Just a theory, I didn't look into source code of Crispy and PrBoom-plus yet. Is also possible they did this before implementing extended nodes support, just for the sake of fixing slime trails.

In case they still chose to do it later, historical request to support extended nodes in Crispy:
github.com/fabiangreffrath/crispy-doom/issues/43

P.S. And by the way, yes, DeeP nodes, despite being derailed as inferior to extended nodes (the latter got wider support as well), actually do offer something that extended don't and it is also easier to generate "vanilla-or-DeeP (DeeP on overflow) " than "vanilla-or-extended (extended on overflow)". Simply put, conversion of already built BSP trees between vanilla format and extended format is lossy both ways, even if the counts of all relevant structure are within vanilla nodes format limits. Building either would require algorithm tailored to the intended output format (good luck switching intentions midway). Whereas algo for vanilla and DeeP nodes format can be unified, as no data loss happens if convertation between either occurs before the limits of vanilla format are hit.

P.P.S. For clarity, DeeP nodes could be theoretically supported by vanillaish Doom engine that would render bzzrak effect faithfully just based on the angle stored in seg. But extended nodes don't store angle in segs at all, you would have to modify the engine to take angle from elsewhere, or support the special marks on linedef for this effect directly (i.e. information about effect will have to be stored outside of nodes).

Didn't know that. Well I don't know then ¯\_(ツ)_/¯

That's just information from zdoom wiki:

I don't know if the guys behind Odamex are that unaware or just have some weird sense of humor by still keeping that horrible name.

I mean, it sounds like a suppository brand ffs.

Try telling to any non-Doomer friend that you were using Odamex yesterday and see what pop into their minds.

@gibbon Well, I never got around to hacking on my own Doom port yet, but still I find it strange that removing limits would ruin this specific effect, especially consider that you do NOT fix slime trails. The only thing that should interfere is ignoring Angle (and maybe also Offset) fields provided in a Seg structure and instead computing it to "improve precision". Even then, the exact horizon/infinite ocean/bzzrak effect implies 180 degrees are added to the angle compared to what it should have been, which means that even if recomputing Angle is somehow necessary, the effect can still be detected and reapplied as you can discover it is there by seeing an absurd deviation of Angle compared to the expected value one could compute.

So if it is not because of ignoring Angle, I am very curious (and clueless at the moment) of what it is then. Widescreen support? Although it is better not to do guesswork and just look into code.

Also, not all limits can be removed in non-Boom limit-removing without desyncing demos anyway: like spechits, for example.

P.S. Sprinkled Doom used to render it correctly in version 3.3.0.