by RockstarRaccoon » Fri Jan 28, 2022 5:53 pm
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...
So, necroing my own thread here, but[i] [b]I actually have this code in a build from a year ago.[/b][/i] 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...
[youtube]CqZPIjDyCP0[/youtube]
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, [b]including the zero-point of the map height,[/b] which is [i]extremely[/i] 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 [c]peg_top[/c], [c]peg_mid[/c], and [c]peg_bottom[/c], which take ints like the suggestion in the original post.
They are defined in [c]r_defs.h[/c], in [c]side_t[/c] as
[code]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,
};[/code]
Which is then used for the values assigned to
[code] uint8_t peg_top;
uint8_t peg_mid;
uint8_t peg_bottom;[/code]
I then added switch statements wherever pegging came up, which was mainly in the "do texture", "project texture", and "render draw" sections of [c]hw_walls.cpp[/c], [c]r_wallsetup.cpp[/c], and [c]r_renderdrawsegment.cpp[/c], 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 [c]texturemid = texheight;[/c])
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.
[b]Anyone have any input on this?[/b] 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...