Weird level hack: Decoupling linedefs and segs

Edward850 said:

Actually, ZDoom doesn't think the nodes are corrupted, and will use them as is (assuming you aren't using GL nodes for the automap).
There is something very wrong with them, however.

esselfortium said:

I dunno, picture looks perfect to me ;P

Well, it could use a little more anti-aliasing.

Edward850 said:

Actually, ZDoom doesn't think the nodes are corrupted, and will use them as is (assuming you aren't using GL nodes for the automap).
There is something very wrong with them, however.

ZDoom does not use the (redundant) linedef offsets stored in the segs and recalculates texture position from the linedef. This of course doesn't work if the seg doesn't match the line as is the case here.

dew said:

Too often ports deviate from Doom, because their devs think they know better. Reminding them they're not allowed to redefine the standard can be worth it sometimes.

Source ports are haram. What are you doing, "removing limits" and "fixing bugs"? That's blasphemy! Off with your head!

Also custom maps are haram too. Who are these blasphemers who believe their work can compare to the IWAD maps? They've gotta be reminded they're not allowed to redefine the standard of mapping. Burn them at the stake!

And just where do you think you are going with that custom palette and these new textures? Are you trying to think you are allowed to redefine the visual standard? Blasphemer! Gotta nail you to a cross for that crime!

Finally, I hope none of you are actually playing the game, because honestly you are not allowed to redefine the standard set by Romero, PBUH, in the demos. The only thing you are allowed to do is run Doom on a vintage 486 to watch its demo loop. Anything else is blasphemy.

I just wish ZDoom supported things like fast scrolling linedefs in Plutonia Map05 or Squadron 417 Map06, for example. It's like the only "overly hacky" trick that I use sometimes. But from what I've heard ZDoom operates too differently to make it work.

Huh. I thought they did. You know, I see no reason why that shouldn't be fixed, now that you bring it up. It really shouldn't be ignored if it's an expected IWAD function, after all.

Memfis said:

I just wish ZDoom supported things like fast scrolling linedefs in Plutonia Map05 or Squadron 417 Map06, for example. It's like the only "overly hacky" trick that I use sometimes. But from what I've heard ZDoom operates too differently to make it work.

ZDoom unpacks the sidedefs so the cumulative scrollers get separated.
There's two problems 'fixing' this:

1. ZDoom expects sidedefs to be unique so it needs some explicit checks as the unpacking takes place long before the scrollers get initialized.
2. I have absolutely no idea if there's maps out there that depend on it. So at best it could be done as a compatibility option.

Gez said:

extended strawman

OK...

Graf Zahl said:

2. I have absolutely no idea if there's maps out there that depend on it. So at best it could be done as a compatibility option.

He just listed several maps that use it purposefully. Unless you mean the map literally won't work without it? Which seems like an odd standard to have, since the same question could be applied to invisible sectors / deep water effects, which I am pretty sure ZDoom supports.

Like, here's the effect in Plutonia Map05 in Choco Doom:



And in GZDoom:

Graf Zahl said:

ZDoom unpacks the sidedefs so the cumulative scrollers get separated.
There's two problems 'fixing' this:

2. I have absolutely no idea if there's maps out there that depend on it. So at best it could be done as a compatibility option.

Linguica said:

He just listed several maps that use it purposefully. Unless you mean the map literally won't work without it? Which seems like an odd standard to have, since the same question could be applied to invisible sectors / deep water effects, which I am pretty sure ZDoom supports.

I thought Graf Zahl was not referring to the scroller trick, but to ZDoom's current behaviour regarding unpacking sidedefs.

Linguica said:

THANKS SODAHOLIC

That was in response to this:

Linguica said:

play this WAD (MAP01) in any engine that more-or-less retains the original rendering code. That means [...] Eternity

Compatible or not, it's still original code AFAIK (I haven't actually bothered reading much of either sets of rendering code yet, mostly been focusing on editing physics).

Linguica said:

He just listed several maps that use it purposefully. Unless you mean the map literally won't work without it? Which seems like an odd standard to have, since the same question could be applied to invisible sectors / deep water effects, which I am pretty sure ZDoom supports.

... and we do not know how many ZDoom maps are out there which compress sidedef and merge such scrolling lines. That's easily possible because for ZDoom there are no cumulative actions.

So far nobody bothered because the effect is entirely visual without any risk of breaking functionality.

On the other hand, if a map with inadvertently compressed sidedefs gets affected it might look really, really bad if the scrollers suddenly got faster. One has to choose the lesser of two evils.

Linguica said:

I racked my brain for a bit before making this thread to try and think if there was any legitimate use for this, but all I could think of was making wall detail in a gimmick contest where you had a linedef limit (lol)...

I guess you could make a map that was not easily editable...? You sure tend to find some neat hacks :)

Sodaholic said:

That was in response to this:Compatible or not, it's still original code AFAIK (I haven't actually bothered reading much of either sets of rendering code yet, mostly been focusing on editing physics).

The projection code is different. Calling it entirely original is kinda like calling one of those "Last Supper"-ish tapestries they put up in small churches an "original" painting, though. It's still the Doom renderer at its core and just fixes various things the original did with mindbending math.