crispy-doom
crispy-doom copied to clipboard
Add support for extended and generalized linedefs and sectors
So it will be possible to play through Freedoom.
...so are you basically turning crispy doom into chocolate boom or crispy boom? What boom features won't be implemented in crispy doom?
No, I am not going to turn Crispy Doom into Chocolate Boom.
- First, if that would have been my plan, I should have started with something different, e.g. by using WinMBF as a basis.
- Second, once I step foot on Boom territory I will be running behind PrBoom+ (and to some extend Eternity) which I don't want.
- Third, I am not even sure if I should really implement support for extended and generalized Linedef and Sectors at all, because I will take myself and the port into compatibility hell. Being Boom-compatible is not only an extension to being Vanilla -compatible, it is sometimes outright contradictory - and then there's even Boom's compatility mode in which it attempts to be compatible to Vanilla itself. It's a mess!
To answer the second part of your question: I am not going to implement Boom features which are not crucial for finishing a level (or for watching a demo of others doing just that). That is, most certainly there won't be e.g. deep water effects or translucent walls. My original aim is to allow people to play through the FreeDoom maps without getting stuck at switches or doors that have no effect at all.
This is still not completely off the table...
I'm still working through this slowly, but I implemented generalised sector types in my own fork.
Cool! Are you also going to add support for generalized linedefs?
Yes, I'm just going through implementing some simpler changes first. I'll update you in here when it's done.
Does this work well across a save/load cycle, i.e. are all light thinkers properly restored?
I am currently considering to add some kind of translation between generalized linedefs and regular/extended ones. The idea is that each generalized linedef will have a matching regular/extended linedef which could be used to replace it. The matches will not be 100% accurate (as in, e.g. how fast a door actually opens), but probably enough to make maps at least playable.
This idea does not yet cover stuff like push/pull objects, sectors with changed friction, translucent segs, etc.. It is more about "do I have a chance to reach the exit in this map, no matter what?".
It's rather annoying that Freedoom was built without vanilla compatibility in mind, but you're a trooper for even considering this.