More options for texture alignment (pegging) (WITH CODE!)

[RockstarRaccoon]

So, to extend my requests from a while back, I would like to propose a new system for texture alignment, or "pegging" as it is referred to.

In case no one remembers, in the past year I've bumped up against the need to the need to do things like pegging a texture to the floor, or doing away with pegging and aligning a wall to the 0 on the map height. After examining the part of the rendering code which deals with this, it seems to me that both are theoretically possible, but adding a bunch more flags to a line for each one would neither be robust nor elegant.

I would like to a propose a group of numeric fields (3 bytes) for sidedefs, to provide absolute control over the alignment for textures. This would be one byte for each texture on each sidedef of a linedef, and would have values along the lines of...
-1 - Old System
0 - Absolute (0 on the map height)
1 - Front Ceiling
2 - Back Ceiling
3 - Front Floor
4 - Back Floor

Would this be a good feature, or would attempting to implement it tear the engine apart? Is there a better potential implementation to look at?

[RockstarRaccoon]

So, necroing my own thread here, but I actually have this code in a build from a year ago. I was going to post it and talk about whether I should integrate it, but then post-COVID must have knocked me down for a few days and I lost track of it.

Here's a video of what it looks like in action...


This may seem a bit less than useful at first glance, but the idea behind it is that you have full control over what each individual texture is pegged to, including the zero-point of the map height, which is extremely useful if you want to make big blocky geometry or move both the floor and ceiling without it messing with the texture alignment. (also, pegging to zero is a few ops quicker, because texture-height actually starts at zero before being calculated against whatever the texture is pegged to, I don't remember how it was done in vanilla, but if it was similar, I have no idea why Carmack didn't just make that the default)

Anyway, my issue with this code is that it feels a bit... cumbersome? In how the mapper interacts with it, how it's recorded in the UDMF, and how the engine reads it out.

Basically, each side-def has fields called peg_top, peg_mid, and peg_bottom, which take ints like the suggestion in the original post.
They are defined in r_defs.h, in side_t as

Code: Select all

enum EPegging {
	PEG_NONE=0, // DEFAULT / ORIGINAL BEHAVIOR
	PEG_ZERO=1,
	PEG_FRONT_CEIL=2,
	PEG_FRONT_FLOOR=3,
	PEG_BACK_CIEL=4,
	PEG_BACK_FLOOR=5,
};

Which is then used for the values assigned to

Code: Select all

	uint8_t peg_top;
	uint8_t peg_mid;
	uint8_t peg_bottom;

I then added switch statements wherever pegging came up, which was mainly in the "do texture", "project texture", and "render draw" sections of hw_walls.cpp, r_wallsetup.cpp, and r_renderdrawsegment.cpp, which was basically just re-working the equations for that new system on a linedef-part by linedef-part basis... (where, once again, pegging to zero ended up literally being straight-assignments like texturemid = texheight;)

So...

That's what I've got, and I'm sitting here torn between wanting to update my code-base and push it to the github, but also I really want someone to come in and tell me there's not a better way to do this, because it feels like it's cludgy and breaking convention. Something about it doesn't feel "right", even though it works just fine in practice.

Anyone have any input on this? I'd like to see the feature in there, especially since someone just added per-part sidedef-lighting, but I don't want to push a change that adds steps to the rendering like this only to realize later that it could've been done more elegantly...

[RockstarRaccoon]

Just thought of a problem with this solution: someone might want to implement code down the line which pegs side-parts to sectors they aren't attached to. I should make sure I'm not making their job harder by splitting this up.

I could also implement that now... hmm...

Anyway, I'm patching the working code into the current version of GZDoom now, so if anyone has thoughts on a more elegant solution, go ahead and tell me. It's way easier to change the implementation of a feature like this while it's being built in than it is down the line...

Edit:
Another thought I just had is that someone might want to peg a side death part to another side def part, which should be possible considering it's all the same vertical alignment concept.

Also, vertical alignment is recalculated every frame (probably because there are a ton of ways to change it), and I feel like a little optimization could go a long way, especially considering vertical alignment never changes for like, 99% of textures, and even for the ones it does, it's only ever constant when the texture is being animated in some way.

[Major Cooke]

I think I would actually like this myself. If you do get the code up and going again, let me know. I can move this into Code Submissions for you if you like.

[RockstarRaccoon]

I am working on the code submission, but I've been stalled a bit on it... I had normal pegging working just fine in the latest build with the new code, but then I broke it again while trying to optimize to a new system. I'm also really not sure if this is the way I should be going about it, because I'm ending up overhauling the entire line-texture-placement code.

We definitely should enhance the pegging system, splitting it up for all 3 parts and adding more options (including one for not pegging decals), but there's just so much baggage in terms of compatibility...

Mind looking at it when I get something lookable working?