The status of ZDoom 2.0.97

Post by **Graf Zahl** » Wed Aug 03, 2005 1:45 am

Ajapted wrote: And FWIW, updating all the physics code for 3D floors is definitely not a piece of cake . A lot of it relies heavily on the fact that each linedef has a single vertical gap for objects/bullets/sight to pass through.

It's not that hard. I have something working that is not too bad. You don't have to be 100% precise because the most problematic cases don't occur that often and more importantly, rarely have any serious impact on the game.
I found that it is sufficient for both sight checking and aiming to ignore any 3D floors that obstruct only a part of the target but neither top or bottom. Just clipping the top and bottom of the given range is more than enough given Doom's engine. For shooting there is no problem at all to add this to ZDoom's trace function because you can determine precisely where a trace hits a 3D floor.
So the only thing that remains is to determine the gaps at lines in P_LineOpening. Yes, if you want to be exact it can become a nightmare but again, if you think about the engine's needs you can easily forget all the problem cases and reduce it to something manageable without rewriting the whole system. The engine just needs to know that a move is blocked. It does not need to know how precisely a 3D floor blocks it so again choosing either the gap above or below the 3D floor is fully sufficient to clip movement.

The only problem is that it requires an OpenGL renderer because I really don't want to deal with a z-buffer-less implementation...

BetaSword · Post by **BetaSword** » Wed Aug 03, 2005 2:12 am

Pardon my ignorance of the code, but technically, wouldn't allowing plane-alligned sprites make a suitable substitution for true 3D floors when combined with bridge things? Or would it actually be easier just to have real 3D floors?

And another question based off that, if true 3D floors were implemented, how would the be mapped? Would it be done like Legacy, with dummy sectors and that fun stuff, or would the actually map format be changed to allor for 3D floors?

Post by **Graf Zahl** » Wed Aug 03, 2005 2:53 am

BetaSword wrote:Pardon my ignorance of the code, but technically, wouldn't allowing plane-alligned sprites make a suitable substitution for true 3D floors when combined with bridge things? Or would it actually be easier just to have real 3D floors?

Real solutions are always better than hacks. If you have a z-buffer rendering a 3D-floor is not a complicated issue.

And another question based off that, if true 3D floors were implemented, how would the be mapped? Would it be done like Legacy, with dummy sectors and that fun stuff, or would the actually map format be changed to allor for 3D floors?

Of course like this. Otherwise we'd need Quake support. Doom still used 2D-maps and that is not going to change.

Lexus Alyus · Post by **Lexus Alyus** » Wed Aug 03, 2005 3:06 am

I've not been keeping up with this thread and so I feel a bit in the dark about things... so, does this mean that Zdoom will soon have 3D floors?

Post by **Graf Zahl** » Wed Aug 03, 2005 4:00 am

No. You should at least read the relevant discussion here.

Ajapted · Post by **Ajapted** » Wed Aug 03, 2005 5:42 am

Graf Zahl wrote:The engine just needs to know that a move is blocked. It does not need to know how precisely a 3D floor blocks it

Step ups? e.g. an extrafloor bordering on a normal sector and the extrafloor is 24 units higher.

As someone who has "been there done that", I hope to convince you that getting it to work as well as people will expect it to really won't be easy.

The only problem is that it requires an OpenGL renderer because I really don't want to deal with a z-buffer-less implementation...

I know what you mean

.

Maybe you should completely forget about 3D floors, looks like ZDoom will always have software rendering, and not having a major feature like 3D floors usable in S/W mode would surely be unacceptable.

Post by **Graf Zahl** » Wed Aug 03, 2005 6:09 am

Ajapted wrote:
Graf Zahl wrote:The engine just needs to know that a move is blocked. It does not need to know how precisely a 3D floor blocks it
Step ups? e.g. an extrafloor bordering on a normal sector and the extrafloor is 24 units higher.

Not a problem. If the floor height of the 3D-floor is close enough to the actor's feet use it as the bottom of the gap. All the necessary information is there to determine which part of an actor is blocked

As someone who has "been there done that", I hope to convince you that getting it to work as well as people will expect it to really won't be easy.

As I said I have something that works quite well (I'll release it once I upgraded my code to ZDoom's new floating point system.) It is doing collision detection mostly like Legacy but I had to fix some issues with it.

Just for reference, what do you think of Legacy's implementation for collision detection with 3D floors? If there are problems with it, can you point me to an example map?
(Please don't say anything about aiming, shooting and checking sight. I know that these don't work well or not at all and I had to reinvent all of this from scratch.)

Maybe you should completely forget about 3D floors, looks like ZDoom will always have software rendering, and not having a major feature like 3D floors usable in S/W mode would surely be unacceptable.

This subject will come up again and again. Just saying 'no' won't make it go away.

BTW,

Post by **TheDarkArchon** » Wed Aug 03, 2005 6:22 am

What port is that?

Post by **Graf Zahl** » Wed Aug 03, 2005 6:26 am

My own one. Still in development.

I recently dug out some stuff I did with PrBoom a few years ago. Most of it has been ported to work with ZDoom already but before I finish that I want to convert it all to ZDoom's new floating point code.

Post by **Xaser** » Wed Aug 03, 2005 9:10 am

That's pretty damn cool. Not only is it a 3D floor, but it's a sloped 3D floor. Nice.

The only problem with implementing GL rendering is that won't it cause problems with vanilla doom wads that use those crazy sector-referencing tricks and the like? If we can get a GL renderer which doesn't have these problems, that would rule so much, but I don't think it would be too easy to do so.

killingblair · Post by **killingblair** » Wed Aug 03, 2005 9:16 am

Graf, did I ever tell you that I love you?

LK873 · Post by **LK873** » Wed Aug 03, 2005 9:26 am

Well from what I know Graf already has sector referencing figured out for GL.

Post by **Xaser** » Wed Aug 03, 2005 9:38 am

That's certainly good to know. I'd hate to have backwards compatibility ruined in such a way.

Post by **Graf Zahl** » Wed Aug 03, 2005 9:55 am

LK873 wrote:Well from what I know Graf already has sector referencing figured out for GL.

Plain self-referencing sectors are simple because it's easy to discard lines with both sides in the same sector.

One big problem are elaborate deep water hacks that use several nested open sectors. Although I know how to handle them in theory this can be a very costly operation. Granted, I haven't seen many maps that use them but they are important. A good example is MAP21 of Strain.

Another thing that is not easy to emulate is stuff like the exit in Kama Sutra MAP01. Even Risen3D fails miserably with that utterly screwed up area.

Post by **Bio Hazard** » Wed Aug 03, 2005 1:28 pm

Why not just make supported alternatives to these hacks and make a huge repository of patches via WadDiff?