myk
volveré y seré millones
Posts: 14839
Registered: 04-02 |
hex11 said:
It seems to me the purpose of Doom+ is clearly defined, there's no need to guess:
My guess is much more informed that what you may think, as I gave a good amount of testing feedback for PrBoom+ and Doom+. That statement you quoted is saying what it can do, it's not telling people what to do with it.
There wouldn't be a need for this patch if people had kept making the same style of maps as they did in the 90's.
Not entirely the same style, as v1.2 and earlier systems required even simpler styles. As a style, v1.9 vanilla mapping only developed as such with the arrival of ports, if not against the v1.2 style, because there's no such thing as style if you don't have a choice or a point of comparison with other styles.
It's only because advanced ports extended the limits did such intricate maps materialize, and thus was there a need for this patch (because it turns out the ports were also affecting the gameplay and thus demo compatibility).
The only driving need, as I pointed out, was Andrey's research. To me the release of Doom+ was awesome, but the existence of PrBoom and PrBoom+ made it much less necessary than if there hadn't been Doom compatible (in the -complevel sense) engines.
So what you are saying contradicts the facts directly: It really came about as a result of there being ways to run limit removing WADs, and to enhance those, more than to run those WADs. If anything else, Doom+ also plays a form of ironic joke on a then incipient Chocolate Doom: "Why bother with the limits of vanilla when vanilla itself can break them now?"
And even though someone could have figured out how to do this before 1997, it would have been fairly useless since most computers at the time were barely powerful enough to run maps designed within the 1.9 limits. In fact, some TXT files that go with the more elaborate PWADs of the period mention that their maps may run slowly unless you have a fast 486 or Pentium class machine (and those weren't prevalent until Quake made everyone upgrade, at least those hardcore gamers who could afford it).
During the DOOM heyday of 1994-1995, it wouldn't have made that much of a difference, but by 1996 it would have become progressively more useful with the spread of early Pentiums. Only a few months passed between v1.2 and v1.9 and id had already raised some limits. In two or three years the potential to raise limits really starts to shine and v1.9 was coded mainly for the moment and the near future.
Note also that the release of the source didn't have immediate results, so vanilla mapping continued to dominate the scene years after 1997, when it was much clearer that the limits were being felt by map designers, and when ports were deviating from Doom's core behavior to make way for their new features.
I never argued against the fact that the existence of Doom+ depends historically on previous development of ports, and directly on PrBoom+'s development, but that has little to do with a normative purpose or with the definition of vanilla compatible. DeHackEd and Doom+ are equally Doom compatible and anything that works with vanilla by applying their changes is vanilla compatible.
Like I said, though, Chocolate Doom does not need to follow vanilla in every way to have a purpose in the community. Sure, it could be a more purist and Doom compatible port, and in that case it would support Doom+ and would probably do without some ease-of-use features that make Chocolate different from vanilla. This niche, though, is already covered by vanilla on DOSBox, which would weaken the point of such a port considerably. Vanillas persistence makes Chocolate Doom gain a more important role if it's not equivalent to it. And the way fraggle is coding it, geared around the static limits and vanilla in the 90s, also covers a niche which delineates it more clearly from all the other projects based on the source release.
Part of coding in the community depends on demands in the community, aside from more personal preferences that attract coders in the first place, and Chocolate Doom naturally covers the more retro aspect of Doom.
Another aspect or way of seeing it is as "the port-users' vanilla", versus vanilla on DOSBox and because of its extra ease-of-use features.
kb1 said:
The beauty of it is that, Chocolate Doom is basically done: it's doing a great job fulfilling it's purpose. With these seemingly simple changes, it could support a much wider range of possibilities, without compromising what's already working.
I don't think so, and I think hex11's comment about wishy washy was a critique of your post rather than an unconnected wise saying.
If the limits were only an option within the engine, most players would just ignore them, most mappers would start to ignore them, and them engine would end up catering 95% to "I want it more vanilla than PrBoom but modern" people who would be nagging fraggle even more about other "acceptable" features to add. The current "sustain 90s DOOM" role of the engine would be more or less dead, and the people interested in that would start ignoring it in sake of vanilla on DOSBox... which some do anyway, as it is.
|
10-30-12 11:55 
