Midtexture bleeding in Zdoom (port racism ITT)

So I was using MIDBARS3 to create a handle rail and noticed that, if it's right on the edge of the floor's sector, then bleeding occurs (at least in Zdoom) and of course that looks bad. So I tried setting the midtexture sligtly inside the sector to prevent bleeding, but it still happens, again in Zdoom. in GZDoom of course, everything renders fine. Is there any way to prevent this?

It'd be nice if you posted a screenshot, because i don't really know what you're talking about.

The midtexture, as you can see, is inside the sector, where I thought it would be safe from bleeding, but it still occurs, but only in ZDoom. Now, I suspect this is related to the fact that they're offset by 80 pixels so that they're shorter than the actual texture, so I guess this is what's fucking things up?

Yes, you can prevent this. There's two options:

1. Set the global 'clipmidtextures' flag in MAPINFO so that it's disabled for the entire map.
2. Set this flag on the linedef itself, in UDMF it is directly available, on Hexen format maps you have to go through Line_SetIdentification to set it.

GoatLord said:

So I was using MIDBARS3 to create a handle rail and noticed that, if it's right on the edge of the floor's sector, then bleeding occurs (at least in Zdoom) and of course that looks bad. So I tried setting the midtexture sligtly inside the sector to prevent bleeding, but it still happens, again in Zdoom. in GZDoom of course, everything renders fine. Is there any way to prevent this?

http://zdoom.org/wiki/Linedef
You want the CLIP_MIDTEX flag on that line. In UDMF it's called clipmidtex.

Alternatively, you can put the ClipMidTextures keyword in ZMAPINFO:
http://zdoom.org/wiki/MAPINFO/Map_definition#ClipMidTextures

Graf Zahl said:

Yes, you can prevent this. There's two options:

1. Set the global 'clipmidtextures' flag in MAPINFO so that it's disabled for the entire map.
2. Set this flag on the linedef itself, in UDMF it is directly available, on Hexen format maps you have to go through Line_SetIdentification to set it.

I'm mapping in vanilla format, so I think option 2 might be a no-go. I don't have a MAPINFO for this map. I can go into XWE and change it, but I wouldn't know what code to add in...

Hmm.. Maybe i'm blind or something, but i just don't see anything wrong in that picture. Maybe i just don't know what texture bleeding is? I thought it's some sort of slime trail, no?

This is normal behavior of the software renderer. The vanilla way of fixing this: Make sure to put at least 1 unit of floor height difference or at least 1 unit of sector brightness difference between the 2 sectors on the opposite sides of the linedef with the midtexture.

scifista42 said:

This is normal behavior of the software renderer. The vanilla way of fixing this: Make sure to put at least 1 unit of floor height difference or at least 1 unit of sector brightness difference between the 2 sectors on the opposite sides of the linedef with the midtexture.

Hot damn! That fixed everything in an instant, thanks!!!

scifista42 said:

This is normal behavior of the software renderer. The vanilla way of fixing this: Make sure to put at least 1 unit of floor height difference or at least 1 unit of sector brightness difference between the 2 sectors on the opposite sides of the linedef with the midtexture.

+1 for the non-scripting way to be less complicated than the zDoom-ism way.

Note that changing brightness by just 1 unit might be a lot more noticeable than you think. At least in most software (as opposed to OpenGL) ports 129 is the same as 128, however 127 is the same as 112. Because everything gets rounded down to the closest 16 * X.

"Scripting"?

As a quick term to describe using mapinfo; yeah, it's close enough.

What? It's less complicated to add a map hack than to add a single keyword to the MAPINFO or to tick a single checkbox in the editor?

You must be really overwhelmed by simple options then... :D

Fonze said:

+1 for the non-scripting way to be less complicated than the zDoom-ism way.

You literally open the line's properties and click on the checkbox that enable midtex clipping. I'm not really sure what that says about whatever if that's more complicated than making a whole new sector and potentially mucking with the physics and / or looks of the map.

Graf Zahl said:

What? It's less complicated to add a map hack than to add a single keyword to the MAPINFO or to tick a single checkbox in the editor?

You must be really overwhelmed by simple options then... :D

Well it's a known fact that when I open a map in UDMF format and right click a line I scream and run away from my computer screen, arms flailing like a muppet, but I don't see how that's here or there ^^

My point is that one set of options is guaranteed to always work, while the other set only works under set conditions (ie the (G)Zdoom ports or only while editing in particular formats). Given that, how are you saving him time? Perhaps 10 seconds in the short term, but one day he'll want to make a map that doesn't support those options, at which point he'll have to relearn the correct, not map hack way to do things. Of course that's a moot point considering that he is already currently mapping in a format which doesn't support the line flag. So from there, what's more work: drawing 1-2 lines and changing brightness up by 1, or floor height by 1 for that matter, or closing the map editor program, opening the map in a wad editor, and then creating a MAPINFO lump just for what could potentially be one thing.

Look, I have all the respect in the world for zDoom as a port and the hard work that went into making it literally the most convenient port, but it's nothing short of a huge mistake for authors to compromise their compatibility for the sake of one convenience that can also easily be accomplished in a more compatible way.

Of course if this map was one of those few mind-blowing, CPU-murdering zDoom wads that had a ton of complicated stuff going on in it, such a flag on lines or in the MAPINFO lump could be exceedingly useful and perhaps insane not to use, but for the 99% of zDoom wads that come out it's just a convenience shortcut that secures one type of compatibility and teaches the mapper to map for one type of compatibility.

Much the same as if you were training me for a job at your company. Now, your particular building/center does things a bit differently than "the book," or at least the proper way according to the person paying your bills. What service would you be doing me to just show me the one way this particular building does thing x, over showing me first the proper way and then showing me the "shortcut" or whatever? At some point I'm gonna move or bosses will change or something will change and it might acutally be important to at least be vaguely familiar with the proper way to do things. Of course you're not here to train folk or hold their hands, but just as an analogy.

So the long of the short of it is the normal way is easy enough to be the best place to start.

Arctangent said:

You literally open the line's properties and click on the checkbox that enable midtex clipping. I'm not really sure what that says about whatever if that's more complicated than making a whole new sector and potentially mucking with the physics and / or looks of the map.

Most mid-tex's are used as fences; what physics are going to get destroyed here? What looks are going the be destroyed by a commonly used mapping practice that is so unnoticeable most players won't/can't see it without stopping and inspecting the area? If something that you have to specifically look out for in order to spot actually mucks up the look of a map, then there is more at play than something this minor. I mean, that's nice, fancy, and convenient and all, but it's not always applicable.

Why software rendering ports don't fix the bleeding anyway? Is it a complicated issue? Will fixing it break something else? Is this behavior desired in some cases?

He said "ZDoom" initially. That's why people provided a ZDoom solution.

Fonze said:

at which point he'll have to relearn the correct, not map hack way to do things.

... Using a format that support midtex clipping, and using that option?

Like, say what you will about availability because that's a fair point, but that method you're talking about is literally a hack. It's exploiting an unintended interaction that makes zero sense.

I'm not really sure what must've happened to you to warp your definition of hack to include "tell the engine in a very unambiguous and well-labeled manner to cull this line's midtex below the floor and / or above the ceiling" but not "muck with parts of your level entirely unrelated to linedefs to make the engine think it should cull the midtex of a line."

Fonze said:

Of course if this map was one of those ... zDoom wads

GoatLord said:

... it still happens, again in Zdoom. in GZDoom of course, everything renders fine. Is there any way to prevent this?

Fonze said:

but for the 99% of zDoom wads that come out it's just a convenience shortcut that secures one type of compatibility and teaches the mapper to map for one type of compatibility.

Well now this just come across damning people for daring to make maps for ZDoom.

Memfis said:

Why software rendering ports don't fix the bleeding anyway? Is it a complicated issue? Will fixing it break something else? Is this behavior desired in some cases?

Fixing it is a relatively trivial matter. The original omission was to ignore floor and ceiling height when rendering a mid texture. Doom made the blanket assumption that nobody would ever be trying such a thing like placing the texture so that only part of it would be visible.

Since the engine can already do this for one-sided walls, it certainly has the means to do it, so I don't see what would prevent it from being used here.

Disclaimer: I am not really familiar with all the intricacies of the software renderer, so there may be some issue I'm unaware of. Of course, what would prevent the engine from inserting a new visplane at such a line, like it does for a light level change?

Memfis said:

Is this behavior desired in some cases?

I'm pretty sure there are vanilla tricks that depend on it. I remember a wad with a water floor and a texture with fish submerged into the floor this way.

Memfis said:

Why software rendering ports don't fix the bleeding anyway? Is it a complicated issue? Will fixing it break something else? Is this behavior desired in some cases?

It has been used deliberately to create fake "glass floor" effects in Boom. Sink translucent midtextures below the ground and it'll look like it's the floor "above" them that is translucent. So you can give to the player the impression they're walking over a pit obstructed by a glass floor.

Of course that breaks in GLBoom+, GZDoom, Risen3D, and every other accelerated port you might try using with a Boom level, so...

Graf Zahl said:

Since the engine can already do this for one-sided walls, it certainly has the means to do it, so I don't see what would prevent it from being used here.

Disclaimer: I am not really familiar with all the intricacies of the software renderer, so there may be some issue I'm unaware of. Of course, what would prevent the engine from inserting a new visplane at such a line, like it does for a light level change?

Strife clips the midtextures just fine.

Gez said:

Strife clips the midtextures just fine.

And that was the reason why ZDoom got the feature in the first place. Of course at the beginning it was just a hardcoded game flag, the per-level and per-linedef options came a lot later but since the feature already existed they were trivial additions.

Arctangent said:

... Using a format that support midtex clipping, and using that option?

Heh

Like, say what you will about availability because that's a fair point, but that method you're talking about is literally a hack. It's exploiting an unintended interaction that makes zero sense.

The unintended interaction was likely the midtex not being clipped by default when certain important sector properties are the exact same on each side of the linedef. I would say the resulting hack is what Gez mentioned; using the midtexture bleeding to achieve a non-typical aesthetic.

I'm not really sure what must've happened to you to warp your definition of hack to include "tell the engine in a very unambiguous and well-labeled manner to cull this line's midtex below the floor and / or above the ceiling" but not "muck with parts of your level entirely unrelated to linedefs to make the engine think it should cull the midtex of a line."

Well your mom dropped me on my head during breast feeding last night, so that could be it :)

Aside from what may or may not have happened to me to warp my views, the logic behind it is that midtex's were not meant to be used in this way in vanilla, otherwise a line or ten of code would have been written to always clip midtex's within floors\ceilings. The behavior of midtex bleeding is a bug, which can be seen through it's differences in behavior between 2 sectors with the same properties and 2 sectors with differing properties.

It's not that the zDoom additions are hacks, it's that they are not universal. I'm unaware of a port which the "vanilla 'hack' of ensuring the sectors that border a line are different" does not work for clipping midtex's.

Well now this just come across damning people for daring to make maps for ZDoom.

It does, doesn't it? I see about 80-90% of new zDoom wads as unnecessary to have been made in zDoom. A good zDoom wad should be clearly unable to have been made in vanilla, limit-removing, or even boom. Not because that automatically makes a wad bad, but because it is one of the red flags about map quality and author's experience. No single red flag is a damning thing, but multiple can be. On the other hand, well-made (G)zDoom wads are a thing of beauty that I can only have the utmost respect and admiration for; the work required to make a truly good (G)zDoom is formidable and a good end result is that much better for it. But how many people really have the time/patience/skill/want->need to achieve that result?

So you actually meant than mangling the lighting/geometry is "correct", and using a dedicated feature in an engine that supports it is a "hack"?

I wanted to believe that you just phrased the opposite in a weird way.

Fonze said:

Aside from what may or may not have happened to me to warp my views, the logic behind it is that midtex's were not meant to be used in this way in vanilla, otherwise a line or ten of code would have been written to always clip midtex's within floors\ceilings.

Anyone with a shred of knowledge about Doom's code can tell you that this conclusion is just flat out wrong. Like most commercial games, the engine was written to do what was needed, and bleeding/non-bleeding mid textures never were on the developers' radar because all midtextures they used were used at their full height.

It was just happenstance that this difference even exists.

It does, doesn't it? I see about 80-90% of new zDoom wads as unnecessary to have been made in zDoom. A good zDoom wad should be clearly unable to have been made in vanilla, limit-removing, or even boom.

Beware of source code Nazis! I think every mapper has the right to choose the port they want, not the port YOU want!

Not because that automatically makes a wad bad, but because it is one of the red flags about map quality and author's experience.

And what qualifies you to make such a statement?

No single red flag is a damning thing, but multiple can be. On the other hand, well-made (G)zDoom wads are a thing of beauty that I can only have the utmost respect and admiration for; the work required to make a truly good (G)zDoom is formidable and a good end result is that much better for it. But how many people really have the time/patience/skill/want->need to achieve that result?

It doesn't matter. Like I said, if people don't want to map for Boom, let them.

Fonze said:

A good zDoom wad should be clearly unable to have been made in vanilla, limit-removing, or even boom.

I disagree.

What's "clearly unable"? Monsters that spawn every ten seconds in an arena? You can do that with a conveyor belt and voodoo magic. Bump it down to Boom. A 3D floor bridge? You can fake that with criss-crossing mid textures, self-referencing sectors, and instant floor movement with appropriate triggers. Bump down to limit-removing. Transparent windows? Well you could just use a texture with a few MS-Painted diagonal streaks. Bump down to vanilla.

The "hack" of changing a light level prevents Doom from merging the 2 sectors into a single visplane, and, no, it's not a hack. Doom checks a minimal amount of properties to determine if it can merge 2 visplanes into one. Bumping a light level by 1 provides an efficient way to control that decision, without having to add another time-consuming check.

However, if you have an engine that handles UDMF, it is sensical to expose that ability in it's own specialized property. But, it's just a teeny bit slower, and only works in certain source ports.

This is not about being 'slower', but about abusing a property for purposes it was never meant for. In my book that counts as a hack.

kb1 said:

stuff

... Seriously, does vanilla Doom just cause stockholm syndrome? I get that making two sectors not identical so that they're separate visplanes isn't a hack ( since the code's doing exactly what it's supposed to be doing ), but that doesn't cover the fact that doing that clipping a midtex by having two sectors with different light levels isn't an intended effect.

Sure, that's a normal part of different visplanes, but to think that Carmack's thought process on this was actually "hmm yes let's make midtex not be culled through planes but let's also put in a way for mappers to do so once they figure out exactly how our renderer and such works and how to make it so that two sector don't get merged within it" is actually absolutely absurd.

Fonze said:

Well your mom dropped me on my head during breast feeding last night, so that could be it :)

... This is probably the most self-insulting attempt at a "haa but I slept with your mom!" insult I've ever seen. I'm not sure exactly who would want to take the advice of a self-admitted infant who has self-admitted brain damage and is only creating coherent sentences through a sheer luck at mashing at the keyboard.

Although, good to know I have a baby brother? I wasn't aware my mom was even pregnant, nor that she was even young enough to still get pregnant.