Preserving the physics code

[printz]

This ZDoom thread has inspired me to ask this here.

Is Eternity planned to keep the vanilla Doom-like physics in it, unlike ZDoom? This is so that maps relying on trick puzzles (such as those used in speedrunning) are forward compatible with Eternity. Those bugs are of the type that doesn't break the core Doom gameplay, so there's no real need to fix them. This way Eternity could become a viable alternative to ZDoom mapping-wise. I'm asking this so that people like TimeOfDeath (if I'm not mistaken) have an alternative for mapping, while also having access to customization.

Does Eternity support demos recorded with previous versions of itself? This could allow the circulation of speedrunning attempts as well... If further fixes only address features rather than physics, then I don't see how they couldn't be conditioned with demo_version (if I'm not mistaken) in the code.

[esselfortium]

The new portal-friendly 3D clipping code is planned to optionally be used in place of the original clipping code, much like how the ZDoom-based 3D clipping code that's in EE currently can be disabled with a compat flag. I'm not sure if this is going to replace the ZDoom-based code for 3D object clipping, or if it's going to be a third system in addition to the existing two. Somehow I imagine it'll be replacing the existing 3D code, though, since having three clipping codepaths would almost certainly be a huge mess.

You shouldn't have to worry about the vanilla-style clipping going anywhere, though.

Also, supporting vanilla physics for compatibility has nothing to do with "becoming a viable alternative to ZDoom mapping"...

[Quasar]

esselfortium said:

I'm not sure if this is going to replace the ZDoom-based code for 3D object clipping, or if it's going to be a third system in addition to the existing two. Somehow I imagine it'll be replacing the existing 3D code, though, since having three clipping codepaths would almost certainly be a huge mess.

Actually the ZDoom code is integrated in with the current 2D-only codepath in such a way to where it is not a completely separate codepath, and therefore it shouldn't be in the way of the new portal clipping stuff. It can remain as the way to have 3D object clipping but still play with the old physics. For example, even with comp_overunder off, EE still allows plasma bump. That change is related to something else in ZDoom, probably changes in the blockmap algorithms.

[printz]

esselfortium said:

Also, supporting vanilla physics for compatibility has nothing to do with "becoming a viable alternative to ZDoom mapping"...

See the last sentence of my second to last paragraph in the starting post.

[Quasar]

At this point I can't promise anything about how the portal-enabled clipping and physics will work. It may not end up being compatible with tricks like wallrunning and bumps, since SoM wants to create a system that is mathematically correct and not full of hacks. That's why the old system will be retained for use with normal levels.

[Graf Zahl]

Quasar said:

since SoM wants to create a system that is mathematically correct and not full of hacks.

That's probably the only way to do a working clipping system with portals. Each time I have a look at P_XYMovement, P_ZMovement, P_TryMove and associated code my head starts to hurt and I really don't see how any of this could be preserved with more complex concepts.

As Randy repeatedly stated, this code is in desperate need of getting redone - the problem is just that it's this code that mostly defines Doom so replacing it will definitely alienate some more conservative players.

[esselfortium]

Graf Zahl said:

As Randy repeatedly stated, this code is in desperate need of getting redone - the problem is just that it's this code that mostly defines Doom so replacing it will definitely alienate some more conservative players.

Indeed, and this is part of the reason why it's planned for the original code to still be usable by default, if the user wants it, in maps that don't expressly require the new clipping system.

[Quasar]

esselfortium said:

Indeed, and this is part of the reason why it's planned for the original code to still be usable by default, if the user wants it, in maps that don't expressly require the new clipping system.

The feat is successfully pointerizing the interface between the clipping engine and the rest of the game so that this can be allowed :)