It's by design; as Grazza went over from a different angle, the engine doesn't exist as a testing tool for vanilla WADs but to play them (and Boom/MBF add-ons) in the least buggy way possible.
Porsche Monty said:
So prBoom+ shows Tutti Frutti/Medusa where there would normally be any? that's something for the prBoom+ developers to fix.
Demo playback should be identical except where Doom or Doom+ crash or get terminated. Andrey hacked Doom+ to be 100% backward compatible with Doom on purpose, avoiding any limit removals that could affect demo compatibility. In addition to visual glitches, PrBoom/+ gets rid of various conflicts with unidentified or erroneous data that will terminate or crash Doom.
So far you've mentioned purely graphical abnormalities, nothing that would stop a demo from playing back correctly in prBoom+
It isn't, and yeah, that's the main issue. At least it exists in some form, though. Something is better than nothing.
I didn't know it was still being actively developed. The difference between the older Strawberry Doom I used a while ago and the freshest Chocolate Doom svn build is enormous to say the least.
I would agree if the community had a much greater provision of coders, making Strawberry Doom maintenance (or of a similar limit raising offshoot) a given, but as we can see, that is not the case. There is a handful of dedicated coders, and they have their hands full. See my reply to fraggle below for more details on this, the "portability" point in particular.
Anyways, I see nothing "counterproductive" or "dumb" about being organized and keeping a folder for each port, and we're talking 2 ports here, that is, 2 folders. What a horrible "counterproductive" nightmare it must be for some people...
See the "applicability" point below.
Can someone please explain this to me? I must have missed like 15 years of everything. Other than the moderately raised visplain limit in Doom95, can't think of anything else.
There are many standards to that, not one. Limit removing ports support different levels of "limit removal". They generally take from each other and aim to support each other's limit removals, but not completely due to differences in their features and focus. Likewise, none represents what Doom+ does, as Doom+ raises limits but to a lesser degree than even Boom does, which is now being left behind by more "advanced" ports.
Limitless ports are the standard for limitless maps.
You can download Doom+ from the PrBoom+ site. The standard is just its use as a testing base by WAD makers, as exemplified by that WAD by Eternal that I linked above. The limit raising table Grazza linked to above essentially marks the difference between the plain vanilla and Doom+ standards. Everything else is the same.
I'm unfamiliar with this "Doom+" standard, myself, and the forum search isn't turning up anything useful (just every single post that contains the word "Doom" in it. ;) What's the story with it?
I understand this and find that work ethic intelligent, yet, how is it an argument against applying a Doom+ option? "More things" that are off limits to anything vanilla does or to anything you need to do to get it ported in various environments don't make sense in Chocolate, but... check out these points about Doom+ and its features in relation to Chocolate Doom:
What's different about Chocolate Doom is that it has a clear goal and purpose, and I can reject things that don't fit that purpose, and have done. It limits the scope of the project in a way that makes it far more enjoyable to work on. There's certainly a lot still to be done but there's always some kind of end in sight.
Would it be difficult to implement Doom+-style limits? Probably not. But I'm not going to do it. If I did, it would complicate the code, and it's a slippery slope to having to support even more things. It doesn't fit with the vision that I have for what I want my port to be. If you don't like it, develop your own port. I've intentionally designed the Chocolate Doom code to be easily forkable so you can do just that. If you can't do that, I suggest you use Prboom+ instead, which is an excellent port that I believe already includes the feature you want.
- Applicability: Doom+, which comes as a modified executable and in the form of a binary patch (effectively its "source code") that is applied much like DeHackEd patches, and which works with DeHackEd and any PWADs or add-ons for vanilla, is like all other vanilla add-ons, vanilla-compatible and inter-compatible. It's as much part of vanilla as the other add-ons are. Because of this add-on, vanilla can do higher limits as long as a user is aware of the patch.
- Complexity: Doom+ is a hack created by a high profile DOOM community coder with a narrow and well-defined aim and set of changes (a few values are modified in a linear fashion without otherwise affecting the engine functionality in a qualitative manner). The aim being to raise limits in the binary that are 100% backward compatible with vanilla demos. This isn't a hack that may be updated capriciously by anyone at any point. Once you said something like "ah but then I might have to make updates dependent on its updates". The chances for an update are extremely unlikely, and if they happen (some before-unnoticed limit, if that is even possible since they were tracked down through the released source and other research) the update should be utterly trivial.
- Portability: Since, as noted above, Doom+ is a minor change (regardless of adding considerable potential to the engine by being able to additionally load more demanding levels) and it pretty much implies no further changes, some guy would have to bother to maintain yet another branch or tree of Chocolate Doom, Chocolate Doom+ or whatever, without doing anything but adding whatever changes arrive from Chocolate Doom? That's what I meant by "dumb and counterproductive" above. There is also the danger that any "Doom+" Chocolate offshoot will contain things that are extraneous to Doom, as it occurred with Strawberry Doom. Not surprising, since once the coder adds the limit raising, he'll get bored just copying updates if he doesn't invent something else to add.
As accurately stated, it's up to you what you include in Chocolate and I'm ready to accept whatever that is (luckily there's also DOSBox, which also ports Doom+ around, if it doesn't fully satisfy my preferences) but I had to provide the above comments and factors because the logic of excluding Doom+ in something of Chocolate's dimensions isn't working for me.