r625 Translucent 3D slopes gone

[Enjay]

OK, so I'm not really sure about this one because I know that you "can't" do translucent slopes. However, this WAD (not mine) did it *somehow* and now it doesn't work.

GZdoom 1.2.1


r625


So, it did work but I have no idea how or why or if it should have done. Anyway, I've cut the file down to a minimal section consisting of just a stripped-down version of that room and using stock textures. All the scripts have been removed from the level too just in case that had something to do with it. It still has the translucent floors in 1.2.1 but not in r625.

[Gez]

In my opinion, that's this that changed it. Quite deliberate.

[Graf Zahl]

To make translucent sloped 3D floors work half of the engine needs a redesign. If someone abuses a bug in the engine and as a result that hack ceases to work it's not my problem.

[Gez]

To make translucent sloped 3D floors work half of the engine needs a redesign.

That said, and just out of curiosity, what was so bad about additive transparent slopes? Judging from that screenshot, it seemed to work well enough.

[Graf Zahl]

The sorting of polygons. Without translucent slopes it is all quite trivial and at no point I have to use complex calculations. But with slopes all that ease is gone and I'd have to implement something considerably more complex. With the current underlying data structures that's not really doable.

[TaBaR]

How about this?

using gzdoom 1.3.17 r649

[Graf Zahl]

Thanks for pointing out another hole I have to plug.

What happened here is that slopes created with slope things were altered after the 3D floor was defined - which was an undefined situation that could have bad side effects - so I had to switch the order of slope things processing and 3D floor generation - which effectively renders your demo worthless.

[TaBaR]

why? what does it hurt?

[Enjay]

That was cunning. However, whilst I was analysing what you had done, I figured out what was going on (the vertex things moving the floor after it had been established) and it did strike me as something unintended and which would get removed at some point. I didn't expect it to happen quite so quickly though. The change has already been committed.

Here's the explanation:

- fixed: Slope things must be processed before creating 3D floors. Otherwise
the 3D floors are not properly set up if the control sector is affected by a slope thing.

[TaBaR]

whatever !

now i have a lot of levels i have to redo !

months of work gone !

thanks

[Graf Zahl]

Translucent slopes don't work with how sorting of translucent stuff is done. You wouldn't think I'd disable it for no reason, would you?

[Graf Zahl]

I didn't expect it to happen quite so quickly though. The change has already been committed.

Why not? The moment I saw it it was clear to me what was something wrong with the setup code. What may not be so obvious is that the 3D floor was not created properly. The post-creation sloping changes some stuff that the engine assumed was still unaltered.

[Enjay]

I didn't mean that I didn't expect you to fix it quickly, it was merely that I had just downloaded the demo files, figured out what they were doing and typed a reply in the thread asking if this was actually something legal or if it was likely to change. However, when I tried to submit my post, you'd already replied saying that it would change (meaning there was no point in me actually submitting my post) and when I checked the SVN the fix was already committed.

ie, for me the "flash to bang time" of me seeing the examples and you plugging the hole was about 2 minutes. That's quick

[Enjay]

Question: Should png textures with an alpha value transfer their translucency to 3D floors (sloped or otherwise)? At present, they do for the sides of a 3D floor but not for the top/bottom of it. Is this correct behaviour?

[Graf Zahl]

I'll check tomorrow if it can remain like that.