3D floors ... again (impossible comes true)

[Nash]

Using siggi's build, I find that monsters are offset a little lower than usual whenever they are standing on 3-d floors so it appears as though their sprite has sunken into the floor by a few pixels.

[kgsws-CZ]

How does it color sprites? GZDoom just takes the plane's z at the sprite's center and splits the sprite there. If it could do that in ZDoom, too it'd be good enough.

That will need much bigger change in code. I don't think it is worth it. Old renderer also did nothing with this.
Every visible (unsloped) 3D floor creates at least one "clip height". Everything gets rendered only in current clip height. There is loop going trough all clip heights from top to middle and from bottom to middle. Sprites are partitioned even if they are not in sector with 3D floor. Sprite parts are colored only in sector containing 3D floors, and because of clip heights, there is no need for additional partitioning.
Clip heights are sorted fixed_t numbers calculated only from non-sloped planes, so they always make horizontal line on screen.

Using siggi's build, I find that monsters are offset a little lower than usual whenever they are standing on 3-d floors so it appears as though their sprite has sunken into the floor by a few pixels.

They are not standing little lower, sprites are just clipped to floor heights. Doom engine allows overdraw on floor or ceiling.
For example go to MAP01 in Doom2 and summon cyberdemon in green hallway. As you can see, its sprite overdraws floor. Most of items in doom does this, but not that much.
Because sprites had to be partitioned with 3D floors, it will not draw anything under fake floor. This also affects ceilings.

[koverhbarc]

I complied version 3055 of this build - verified the 3D floors seem to be working. However, not everything is working - only Hexen format maps render correctly, Doom format maps HOM all over, apparently not drawing any textures on 2S linedefs. Since this doesn't happen with the latest build of the main branch I don't think it's my computer.

Maybe it's your build. I have no such problems. Looks all fine to me.

Yeah, I had to comment out parts of the translator because xlat_parser.h was missing; that must be it. The mystery is how everyone else gets it to work! When I copied over this header file from the 2.5.0 source, it worked; as well, the binary given in this thread does.

Anyway, I find the other rendering problem to be much more important. What has been done since 2.5.0 that might cause full-screen mode to break? I would suspect some change in DirectX, right?

[Nash]

Oh, right I just remembered that regular sectors in Doom don't clip the sprites. Somehow your 3-d floors are successfully clipping them...

[esselfortium]

Oh, right I just remembered that regular sectors in Doom don't clip the sprites. Somehow your 3-d floors are successfully clipping them...

Boom transfer-heights deep-water sectors clip sprites and midtextures, too, so I think Doom's odd sprite clipping isn't something necessarily difficult to change, but rather just something that's been maintained in software ports for compatibility with 'proper' sprite drawing and abusive midtex use.

[Zippy]

Oh, right I just remembered that regular sectors in Doom don't clip the sprites. Somehow your 3-d floors are successfully clipping them...

It's part of the 3D floor rendering process. In the normal rendering, sprites are some of the last things drawn, so the floor etc. is already drawn and the sprites are drawn over it, hence no clipping. With 3D floors, there has to be some effort to separate the viewable volumes, so sprites above/under/behind/etc. aren't drawn when a 3D floor would hide them. It's this volume separation that means the sprites aren't going to be drawn over the 3D floor.

[Gez]

You might want to adapt the sprite clipping adjustment code (and assorted CVARs) from GZDoom then. It's not a perfect solution, but it can help.

[Graf Zahl]

At least for pickup items. For monsters it might cause more problems than it solves though. But some of the pickups definitely need some work. The health bonus looks quite bad on 3D floors at the moment.

[koverhbarc]

What I've just found when experimenting with 3D floors, that may be related (and also happens in GZDoom) is that a Thing placed to start right on a 3D floor falls through, but even 1 unit above saves it. (or maybe this is just gravity being computed (incorrectly) before 3D floors are set up, because it doesn't happen with Bridge things).

Also, translucent 3D floors are supported by this, but they look awful. It would seem the software renderer isn't using the correct translucency algorithm (why?); it seems to be the same as used on walls (walls do have the option to use a different formula, but it doesn't look any better with water textures). By the way when testing this out I found a bug or 'feature' presumably left over from Boom: TranslucentLine does not tile the texture on it, but only draws one copy extending down from the ceiling 128 (or whatever the height of the texture) units) - even if this has some purpose it should at least be overridable.

[Graf Zahl]

What I've just found when experimenting with 3D floors, that may be related (and also happens in GZDoom) is that a Thing placed to start right on a 3D floor falls through, but even 1 unit above saves it. (or maybe this is just gravity being computed (incorrectly) before 3D floors are set up, because it doesn't happen with Bridge things).

The physics code involved here is a mess, unfortunately. I'm not sure it's really fixable

Also, translucent 3D floors are supported by this, but they look awful. It would seem the software renderer isn't using the correct translucency algorithm (why?); it seems to be the same as used on walls (walls do have the option to use a different formula, but it doesn't look any better with water textures).

No bug here. This is working exactly as it should and just shows the limitations of the palette.

By the way when testing this out I found a bug or 'feature' presumably left over from Boom: TranslucentLine does not tile the texture on it, but only draws one copy extending down from the ceiling 128 (or whatever the height of the texture) units) - even if this has some purpose it should at least be overridable.

As intended. And guess what: It is overridable!

[Enjay]

a Thing placed to start right on a 3D floor falls through, but even 1 unit above saves it. (or maybe this is just gravity being computed (incorrectly) before 3D floors are set up, because it doesn't happen with Bridge things).

I do know that the positioning of things on 3D floors comes down to some very sensitive checks. Some slight alterations in the code a couple of years ago broke a number of existing maps at the time. This was, of course, addressed and the way things are currently handled is the result of quite a bit of work to ensure behaviour consistent with what existing maps expect.

[koverhbarc]

Also, translucent 3D floors are supported by this, but they look awful. It would seem the software renderer isn't using the correct translucency algorithm (why?); it seems to be the same as used on walls (walls do have the option to use a different formula, but it doesn't look any better with water textures).

No bug here. This is working exactly as it should and just shows the limitations of the palette.

It may be working as intended, but it's certainly not how I expect translucency to work! I admit that in 8-bit mode it's impossible to use blending of RGB values (the only correct way).

... TranslucentLine does not tile the texture on it, but only draws one copy extending down from the ceiling 128 (or whatever the height of the texture) units) - even if this has some purpose it should at least be overridable.

As intended. And guess what: It is overridable![/quote]
Is this how 2s mid textures work in general? I just realised that I'd never made one before. I guess it does make sense!

[Graf Zahl]

No bug here. This is working exactly as it should and just shows the limitations of the palette.

It may be working as intended, but it's certainly not how I expect translucency to work! I admit that in 8-bit mode it's impossible to use blending of RGB values (the only correct way).[/quote]


ZDoom's translucency is precisely that, mapped to the palette afterward. How else would you do it?

[koverhbarc]

It may be working as intended, but it's certainly not how I expect translucency to work! I admit that in 8-bit mode it's impossible to use blending of RGB values (the only correct way).

ZDoom's translucency is precisely that, mapped to the palette afterward. How else would you do it?

Oh, sorry. So then it _doesn't_ look any different in GL mode? I guess the only option to get correct translucency is to use true color rendering - on today's hardware there's hardly any reason not to, if it were coded, and of course 256-color graphics could still be loaded fine. No, I don't expect you to code it, but if someone did I hope you'd add it.

Anyway, I can't play on versions later than 2.5.0 at all until that renderer error is fixed! It's simply ridiculous that I have the 'choice' between windowed mode, which is far too slow on any serious level, or full-screen mode which flashes weird colors every other tic or whatever - it looks to be palette-related as some colors do not flash. What has changed since 2.5.0 affecting this? I doubt it was anything intentional.

[Graf Zahl]

It may be working as intended, but it's certainly not how I expect translucency to work! I admit that in 8-bit mode it's impossible to use blending of RGB values (the only correct way).

ZDoom's translucency is precisely that, mapped to the palette afterward. How else would you do it?

Oh, sorry. So then it _doesn't_ look any different in GL mode? I guess the only option to get correct translucency is to use true color rendering - on today's hardware there's hardly any reason not to, if it were coded, and of course 256-color graphics could still be loaded fine. No, I don't expect you to code it, but if someone did I hope you'd add it.

I wouldn't bother waiting. This is one of the things that most likely will never happen.

Anyway, I can't play on versions later than 2.5.0 at all until that renderer error is fixed! It's simply ridiculous that I have the 'choice' between windowed mode, which is far too slow on any serious level, or full-screen mode which flashes weird colors every other tic or whatever - it looks to be palette-related as some colors do not flash. What has changed since 2.5.0 affecting this? I doubt it was anything intentional.

No idea. You seem to be the only one having this problem. What's your graphics card?