Eternal MAP03 Cardboard bug: any other instances?

I'm curious if anyone has seen anything else like this:

http://doomworld.com/eternity/engine/screenshots/eternal03_hom.png

This problem begins with SVN revision 209, which is the initial Cardboard commit. You should be able to see through the glass to an area on the other side. I haven't been able to tell SoM about this yet, but it's probably something he can fix without too much trouble (I hope at least ;)

But in order to make sure that this is the only problem of its type, I need to know about any others that people might have seen. Any recent SVN build of EE should show this issue.

A link to the wad this is happening with would be most appreciated. My internet is cutting in and out so IRC isn't an option for me right now

http://ftp.mancubus.net/pub/idgames/themes/TeamTNT/eternal/eternal.zip

There's a lot of files in there, all you need to load is eternall.wad. Go to map03, dqd and kfa, run straight on and keep going until you hit a wall (you'll go through a door or two). Go right, then left, hit the skull switch and then you'll see the hom glass.

I've narrowed this down to a particular type of transparent door hack. I am suspecting that it may have something to do with the change to render closed 2S lines as 1S. There probably needs to be an exception for lines that reference the same sector on both sides (this is an educated guess though).

Some doors in Eternal MAP12 are constructed in the same way and also suffer HOM until they are opened.

EDIT: Actually, it's not nearly so specific. But it IS directly connected to the use of seg.clipsolid -- if seg.clipsolid is forced to be false at all times, the offending HOMs are magically fixed. However, the rest of the renderer goes nuts and starts drawing flats out of closed doors, amongst other possible problems. I'm not confident that this is going to be so simple, now :(

EDIT 2: Setting clipsolid to false for certain types of lines does indeed fix it. However, it always breaks other stuff at the same time. For example I had both the raised sector in MAP03 and the door in MAP12 working, but an otherwise normal area of sky in MAP08 started to show HOM. I don't know what to do at all, so it's all up to you, SoM >_<

Taking a guess here, but. There are several ways to make transparant doors in vanilla Doom but also depend on the type of nodesbuilder used. Using a wrong combination (or wrong construction) may easily lead to a good-looking closed transparant door but which will give HOM during raising. Most levels where this is the case 'solve' it by raising the door really fast.

It may very well be that changes in EE makes dormant errors like above more apparant?

Was planning to look at it last night, but completely forgot again :)

This is definitely a compatibility problem in the Cardboard renderer. Problem is, Cardboard isn't doing anything wrong. This certain kind of transparent sector hack was a bug in the original engine. Emulating it with the new system is probably going to be difficult. SoM's surprised me before, though, so we'll see ;) I certainly know I'm not making any progress against it with my relatively limited knowledge :P

Also, the areas showing this problem aren't built at all like the translucent doors in your example. One of them is a closed sector at height 250 with no textures on either side of the sectors' linedefs, and the sector is enclosed entirely within another sector with floor and ceiling at -244 and 256 respectively. For some reason Doom draws through these types of lines. The other area showing a problem is a single floating 2S line attached to a separate control sector that is being used as a door. Looks like this:

|             |     |\
|__         __|     | \
   |_______|        |  \
 __|   |   |__      |___\
|             |
|             |

The 2S line with the flag on it is attached to the triangular sector on its front side and to the surrounding sector on the backside. The texture is on the middle part of the line. EE is currently not rendering the 2S line, resulting in HOM.

What is Cardboard renderer?

SoM's new floating-point projection and drawing code. He developed it independently and then merged it into Eternity. Among other things, it fixes wobbly lines, reduces long wall error, fixes edge-on HOM, makes flats align to their sector walls pixel-perfect, and significantly stabilizes the texture mapping for anisotropic two-sided lines.

He also put in an optimization that treats closed 2S lines as 1S, enabling them to avoid use of R_RenderSegLoop. Unfortunately this seems to disagree with some old rendering tricks to some degree. I'm really hoping that it can be fixed without totally destroying the optimization.

Just to keep everybody updated, SoM was able to fix this issue (the issue being with glass sector effects that rely on missing uppers or lowers on closed sectors in general). Turns out I was really close to the solution myself after all. I had the idea but implemented it incorrectly ;)

In other news, several other bugs have been fixed, including a really rare crash on savegame load, and the addition of a new comp flag, comp_planeshoot, that turns off the ability to shoot the floor and ceiling -- necessitated by at least Eternal MAP28 -- the glass protecting switches in this map is almost (but not entirely) impossible to shoot out without this comp flag due to a tweak regarding the crossing of 2S lines.

So is this why you forced yourself to play Eternal Doom?

Quasar said:

and significantly stabilizes the texture mapping for anisotropic two-sided lines

what is anisotropic two-sided line?

An anisotropic plane is one that is almost but not quite dead level with what would normally be referred to as the camera's z axis (ie, going into/out of the screen). You regularly hear this term thrown around with "filtering" tacked on -- "anisotropic filtering" -- because such polygons in true 3D engines can experience a special sort of aliasing and distortion that mipmapping alone doesn't do much for.

Anyway, textures look a lot better on such lines in EE now. You can get a lot closer looking down a 2S line without serious distortion due to the stability of the line projection and texture mapping code.

One of the major changes responsible for this was the ability to totally eliminate that grotesque mess of a function known as R_ScaleFromGlobalAngle.

AlexMax: In part yes. It's a fantastic regression test :P

r338:

1) bug: http://prboom-plus.sourceforge.net/etrn00.bmp

2) pcx screenshots are broken (probably wrong header): http://prboom-plus.sourceforge.net/etrn00.pcx

1) Not new to r338 evidently. This has been an ongoing problem in certain hires modes for a long time, and I believe it is caused by a difference between the way the display and the positioning of the status bar is scaled (realyarray is probably causing this...).

2) Paint Shop Pro 3.11 does not object to this PCX file. The PCX subformat used by Doom has never been properly interpreted by certain programs; Windows Explorer is one such program, which interprets the graphics as grayscale instead of paletted. I am not aware of whether or not this is a problem of Doom not adhering to the PCX standard, or of other programs not fully supporting it. It was always poorly defined in the first place, with numerous badly documented subformats. It's an obsolete 16-bit-system graphics format anyway, so it's not of high concern to me. EE supports BMP format shots in part because of PCX being more or less extinct. I would like to add PNG shots as well but I find that adding libpng to the program for this sole purpose to be overkill. Rest assured that if we find another purpose for the library, PNG screenshots would be a foregone conclusion.

EDIT: Turns out it was pretty easy to find the *official* ZSoft docs for PCX after all - http://people.scs.fsu.edu/~burkardt/txt/pcx_format.txt
According to this, there is only one error with how Doom (and I assume neither BOOM nor MBF changed this code, perhaps erroneously) writes the files -- it specifies 2 for the Palette Type instead of 1. According to the docs, 2 means grayscale and 1 means color. Oddly, next to the line pcx->palette_type = SHORT(2); is a comment:
// not a greyscale
Somebody got their wires crossed maybe? Anyway the docs also say that PC Paintbrush IV and up ignore this field entirely, as do apparently a majority of paint applications that handle the file format. This probably does explain the oddness under Win9x's Explorer though. Other than that, I see no errors in the header format. Unless the specific tool you are using expects the HscreenSize and VscreenSize words to be specified in the header. According also to the docs, these fields were only used by Paintbrush IV/IV Plus. The code has never written these out, and just includes their space inside the header padding block.

So that leaves me to ask, which program are you using that's having trouble with them?