fabiangreffrath / crispy-doom

Crispy Doom is a limit-removing enhanced-resolution Doom source port based on Chocolate Doom.
https://fabiangreffrath.github.io/crispy-homepage
GNU General Public License v2.0
807 stars 132 forks source link

Small graphical glitch of doors with transparent textures #201

Closed JNechaevsky closed 7 years ago

JNechaevsky commented 7 years ago

I've found small graphical glitch of doors with transparent textures. This seems to be pure vanilla glitch, since it also happens in vanilla.

Here's how it looks in both Crispy and vanilla: https://youtu.be/a09V6EGpqxs

Suggestion: absolutely harmless gfx glitch, that barely worth of attention, but may be interesting from technical POV. Also, maybe @bradharding will be interested in this too, since it happens and looks absolutely the same way in Doom Retro.

Edit: Mini medusa has been fixed in https://github.com/JNechaevsky/russian-doom/commit/b88031dca8fb360378074f93d61686c76183c711.

Suggestion №68

fabiangreffrath commented 7 years ago

Hm, could you possibly provide a slomo video around the frame when this happens? You may want to place yourself a bit afar from the door so it is properly visible and use the SPECHITS cheat to activate it.

I am pretty sure that the glitch occures as soon as the first transparent region touches the ceiling...

JNechaevsky commented 7 years ago

Here we go: https://youtu.be/B2TUt3DEQlA I have made a few attempts with some explanations. Glitch seems to occurs when ceiling get above of half of the view screen (is it something like SCREENHEIGHT/2?), maybe this will helps somehow, but that's all I can do.

Edit (31.06): Oh daaang. I've just wake up with thought: half o' screen is not the only thing here, after reaching half o' screen player actually see ceiling texture.

fabiangreffrath commented 7 years ago

Thank you very much for that video, great!

So, yes, it probably has to do with rendering the ceiling flat through the transparent texture (though this works before when the door is closed). Another idea: The texture is tiled, there are three elements in a vertical arrangement. Maybe the glitch occures when the first element isn't visible anymore? It's not that clear to see and really just a thought...

JNechaevsky commented 7 years ago

My pleasure, it was interesting to refresh some of my video editing skills!

Could you please point me, where is the starting point of this texture drawing/applying in the code? I'll never handle fix of this glitch, but still want to try.

fabiangreffrath commented 7 years ago

Both midtextures and sprites are drawn by this function: https://github.com/chocolate-doom/chocolate-doom/blob/sdl2-branch/src/doom/r_things.c#L343

fabiangreffrath commented 7 years ago

It has definitely to do with the ceiling flat being visible. If you are standing higher like in this alcove (IDCLIP there) and activate the blue door by the SPECHITS cheat, the glitch does not occur: doom0000

JNechaevsky commented 7 years ago

Uh-oh, I was expecting more code in R_DrawMaskedColumn.

Okay, thank you! I will break my head tonight a little bit, right now just need to make some preparations for DOS version release.

UPD: Sorry, no, release process exhausted me completely for today. Will look tomorrow, after deep and long sleep. sleep

JNechaevsky commented 7 years ago

Good news!

Alright, after taking some time, I've got something. Trying to fix this in r_thing.c, I got nothing more than broken sprites and bunch of different medusa effects (that was really slows down notebook!). Finally I decided to open Doom Builder and investigate what the heck is going on here.

So, it does not seems to be engine glitch - these doors are naturally abusing game engine. There are few reasons of that:

  1. The door itself - is a two different sectors, that's why it does not have visible floor texture in Doom Builder. Screenshot: http://savepic.ru/14189303.png
  2. Next, it uses very interesting texture placement. Instead of using mid.texture, it's using upper texture, even on backwards linedef (that's why the door does not looking like onesided linedef while looking through it). Screenshot: http://savepic.ru/14184182.png
  3. Missing lower texture can also be explained: it is necessary to have some space between door's floor and ceiling, otherwise game engine will not draw through, making a mirror effect. Also note an amount of sidedefs on right screen. Screenshot: http://savepic.ru/14165513.png
  4. Finally, if we'll try to make this door proper way, as one sector with two sided sidefs, we got something like this. There will be black space in transparent places, or tutti-frutti effect, if some necessary fix was not applied: http://savepic.ru/14208523.png and http://savepic.ru/14168587.png
  5. And finally, all of this probably explains why I was having notable performance drops in DOS version (with emulating slow CPU) while close looking through these door-portals.

After all, I have a feeling that it will be better to leave it "as is", let's just say: "this mapping trick is by design".

fabiangreffrath commented 7 years ago

Thank you very much for this analysis! Again, this is another incredibly valuable contribution!

So, it does not seems to be engine glitch - these doors are naturally abusing game engine.

I wonder how it looks e.g. in ZDoom then.

There will be black space in transparent places, or tutti-frutti effect, if some necessary fix was not applied

The first shot is from Crispy, right? Fixing transparent textures on single-sided walls was one of the most long-standing fixes so far. That really cost me nerves. ;)

https://github.com/fabiangreffrath/crispy-doom/issues/23

After all, I have a feeling that it will be better to leave it "as is", let's just say: "this mapping trick is by design".

I agree. It's a mapping trick that is abusing the rendernig engine on purpose. I don't think there is much we can do about it.

JNechaevsky commented 7 years ago

As usual, my pleasure :-)

I wonder how it looks e.g. in ZDoom then.

Ahhh, actually I have looked how it looks in both ZDoom and QZDoom, but have not attached any info - I was thinking that it will not be interesting, since these are completely different engines. Anyway, here's the situation:

ZDoom / QZDoom (software renderer): http://savepic.ru/14157357.png (same glitch) QZDoom (OpenGL accelerated): http://savepic.ru/14220832.png (completely fixed)

Even this specific point looking same in software renderer: Crispy: http://savepic.ru/14194223.png ZDoom: http://savepic.ru/14185007.png QZDoom: http://savepic.ru/14183968.png (completely fixed)

The first shot is from Crispy, right? Fixing transparent textures on single-sided walls was one of the most long-standing fixes so far. That really cost me nerves. ;)

Sure, as window title says. Thanks for pointing, I'll try to apply your fix, with hope that my usual "hey, I fixed this one, but now that one is broken!" will not happen! 😌

JNechaevsky commented 7 years ago

P.S. One final experiment:

I'm completely unfamiliar with QZDoom hardware-accelerated rendering specifics, and have no any idea how it actually works. But I have some experience in 3D modelling, and I think that hw-accelerated engine converts whole level to polygons (triangles), wielding/joining vertexes together.

I have exported MAP21 to Wavefront .OBJ format and opened it in model editor. The export is kinda raw, all map object are grouped by textures, not by objects itself, but at least it gives a very little understanding/view of how these doors are broken. Screenshots are pretty ugly, but... What I see after raising this door:

I belive QZDoom have some routines that correctly merges vertexes and triangles, and this makes such a problematic walls/objects looking properly. I.e., it's not fixing them, it renders them properly for players POV. Something like this.

fabiangreffrath commented 7 years ago

Awesome analysis, thank you very much! And awesome renderer in QZDoom, btw.