Fix for Plutonia MAP05 fast scrollers

Forum rules
Please see Code submission guidelines

GZDoom Status:
Image

Legacy Status:
Image Image

QZDoom Status:
Image

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Fix for Plutonia MAP05 fast scrollers

Re: Fix for Plutonia MAP05 fast scrollers

by hfc2x » Mon Jan 03, 2022 2:16 pm

Rachael wrote:Yeah I definitely was not asking to apply that unconditionally across all maps. However, Ghost Town definitely is not the only map which makes use of this effect, and the effect should be applied per-map, but having a compatibility option for it lets us curate individual maps for it rather than having to do it manually as has been done in the PR.
So, I had some time (after over a year, I know) and I decided to rewrite this script so the particular cases can be added to the Level Postprocessor. I think this should handle most cases where specific maps require the fast scrolling effect, but I haven't had the time to figure out if this can be optimized somehow.

The biggest problem I found was that GZDoom outright separates all the Sidedefs, so counting multiple references to a single one of them separately simply wasn't going to happen. That's why the script compares front-side textures. This works for Plutonia's MAP05, but I haven't seen any maps that require this effect that use a Linedef's back side, so that could be added if necessary.

Code: Select all

version "4.5"

CLASS PlFix : LevelPostProcessor
{
	protected void Apply(Name checksum, String mapname)
	{
		switch (checksum)
		{
			case 'eb0d04aeb2841d5225caa576d7300d43': // Plutonia.wad MAP05
			{
				int speed = 64;
				int scrollers[64]; // Max number of possible scrollers in vanilla levels
				int multipliers[63] = {0};
				int currentscroller = 0;
				int maxscrollers;
				String textures[3];

				for (int i = 0; i < level.lines.Size(); i++)
				{
					if (level.lines[i].special == 100)
					{
						scrollers[currentscroller] = level.lines[i].Index();
						currentscroller++;
						if (currentscroller >= 64)
							break;
					}
				}

				maxscrollers = currentscroller;

				currentscroller = 0;
				textures[0] = TexMan.GetName(level.lines[scrollers[0]].sidedef[0].GetTexture(0));
				textures[1] = TexMan.GetName(level.lines[scrollers[0]].sidedef[0].GetTexture(1));
				textures[2] = TexMan.GetName(level.lines[scrollers[0]].sidedef[0].GetTexture(2));

				for (int j = 0; j < maxscrollers; j++)
				{
					// This would never work for non-compressed levels...
					if (!(TexMan.GetName(level.lines[scrollers[j]].sidedef[0].GetTexture(0)) == textures[0] &&
					      TexMan.GetName(level.lines[scrollers[j]].sidedef[0].GetTexture(1)) == textures[1] &&
						  TexMan.GetName(level.lines[scrollers[j]].sidedef[0].GetTexture(2)) == textures[2]))
					{
						currentscroller++;
						textures[0] = TexMan.GetName(level.lines[scrollers[j]].sidedef[0].GetTexture(0));
						textures[1] = TexMan.GetName(level.lines[scrollers[j]].sidedef[0].GetTexture(1));
						textures[2] = TexMan.GetName(level.lines[scrollers[j]].sidedef[0].GetTexture(2));
					}
					multipliers[currentscroller]++;
				}

				currentscroller = 0;
				textures[0] = TexMan.GetName(level.lines[scrollers[0]].sidedef[0].GetTexture(0));
				textures[1] = TexMan.GetName(level.lines[scrollers[0]].sidedef[0].GetTexture(1));
				textures[2] = TexMan.GetName(level.lines[scrollers[0]].sidedef[0].GetTexture(2));

				for (int k = 0; k < maxscrollers; k++)
				{
					if (!(TexMan.GetName(level.lines[scrollers[k]].sidedef[0].GetTexture(0)) == textures[0] &&
					      TexMan.GetName(level.lines[scrollers[k]].sidedef[0].GetTexture(1)) == textures[1] &&
						  TexMan.GetName(level.lines[scrollers[k]].sidedef[0].GetTexture(2)) == textures[2]))
					{
						currentscroller++;
						textures[0] = TexMan.GetName(level.lines[scrollers[k]].sidedef[0].GetTexture(0));
						textures[1] = TexMan.GetName(level.lines[scrollers[k]].sidedef[0].GetTexture(1));
						textures[2] = TexMan.GetName(level.lines[scrollers[k]].sidedef[0].GetTexture(2));
					}

					level.lines[scrollers[k]].args[0] = speed*multipliers[currentscroller];
				}
			}
		}
	}
}
Attachments
plfix.wad
PWAD with the ZScript lump
(2.76 KiB) Downloaded 166 times

Re: Fix for Plutonia MAP05 fast scrollers

by Rachael » Thu Nov 26, 2020 1:56 pm

Yeah I definitely was not asking to apply that unconditionally across all maps. However, Ghost Town definitely is not the only map which makes use of this effect, and the effect should be applied per-map, but having a compatibility option for it lets us curate individual maps for it rather than having to do it manually as has been done in the PR.

Re: Fix for Plutonia MAP05 fast scrollers

by hfc2x » Thu Nov 26, 2020 12:56 pm

Graf Zahl wrote:If you use a buggy sidedef compressor that's not aware of the original behavior you can easily end up with maps that accidentally merge these things.
This is precisely why I thought level post-processor compat detection option was better in this single one instance. Everything seems to point to this particular map being compressed, causing that (accidental) distinctive effect, and in turn is probably what led to people to discover how editing the LINEDEFS lump could achieve the same thing.

Sidedef counting could be useful for maps known to be made with the deliberate intention to achieve this effect, but in the case of Ghost Town, it's mostly just to restore one of the most distinctive features of it.

Re: Fix for Plutonia MAP05 fast scrollers

by Graf Zahl » Thu Nov 26, 2020 4:25 am

Don't count on it. If you use a buggy sidedef compressor that's not aware of the original behavior you can easily end up with maps that accidentally merge these things.

Re: Fix for Plutonia MAP05 fast scrollers

by Gez » Thu Nov 26, 2020 2:56 am

I'd be in favor of direct support (by line counting) and don't see a need for it to be compat-optioned. The effect is used in other maps too and it's really not a mapping trick that can be used accidentally.

Re: Fix for Plutonia MAP05 fast scrollers

by Rachael » Wed Nov 25, 2020 3:26 pm

Before adding this, I would prefer to ask the other devs if it would be more worth it to add a compatibility option to emulate this effect directly.

To do so, the linedefs themselves could be iterated and each sidedef could be labeled with how many lines are referencing it. Then the texture scroller can look this number up and multiply the scrolling directly by this value.

Fix for Plutonia MAP05 fast scrollers

by hfc2x » Wed Nov 25, 2020 1:56 pm

Just wondering if this could be added to the level compatibility post-processor, since most source ports display the rapid scrollers in Ghost Town, but GZDoom does not (for good reason). A quick compat option can be made to restore the effect:

Code: Select all

version "4.5"

CLASS PlFix : LevelPostProcessor
{
	protected void Apply(Name checksum, String mapname)
	{
		int speed = 64;
		int i;

		switch (checksum)
		{
			case 'eb0d04aeb2841d5225caa576d7300d43': // Plutonia.wad MAP05
			{
				for (i = 602; i < 648; i++)
				{
					if (level.lines[i].special == 100)
						level.lines[i].args[0] = speed*24;
				}
				for (i = 1065; i < 1069; i++)
				{
					if (level.lines[i].special == 100)
						level.lines[i].args[0] = speed*4;
				}
			}
		}
	}
}
And yes, tested with both "default" and Anthology Plutonia (same map checksum) and works as intended. See attached file.
Attachments
PlFix.wad
Fix for fast scrollers in Plutonia MAP05
(547 Bytes) Downloaded 218 times

Top