Archy
Member
Posts: 646
Registered: 11-09 |
fiend-o-hell said:
Isn't Doom2+ for all intents and purpose a vanilla clone with some extended limits? From the looks of it, its having trouble accepting a new patch. In any case I'm sorry to say its an outdated port. I designed the map with PrBoom+ (a descendant of Doom+) using "Vanilla Doom's engine principles" (aka -complevel 2).
What "patch" are you referring to? If it's a LUMP in the WAD, tell me it's name and I'll look into it. The reason I'm pushing for Doom2+ compatibility is that I don't want WADs to have unnecessary errors. By all means, if the removal of the "error" would cause some negativity or loss in the WAD it's self, it should not be forced to become Doom2+ compatible.
I've played many WADs that could easily be Doom2+ compatible if they just changed one thing that doesn't even affect the level. I wish I knew more about WAD editing, because most of these errors are probably easy to fix, and I'd fix them if I could. Sadly though, I lack even basic WAD editing knowledge (let alone skills).
By creating a WAD without unnecessary errors, a wider group of people can play it (as more ports can play it) and this also prevents other errors related to that error from occurring.
Scythe 2 is a great example of a -complevel 2 WAD that goes far beyond the limits of Vanilla Doom yet works just fine in Doom2+ without any sacrifices made to the WAD. Plutonia 2 is a great example of a -complevel 4 (the Final Doom equivalent of 2) WAD that was designed to also be Vanilla compatible (Vanilla Final Doom has the limits removed, so it's like Doom2+ [correct me if I'm wrong]) but wasn't fully because of a few errors that could have easily been prevented. One of those errors was that the midi music doesn't work - one of the most lazy errors ever, and totally unnecessary.
Another reason I'm pushing for Doom2+ compatibility is that it would make my anti-spechits overflow test almost fool proof. Spechits Overflow can cause recorded demos to desynch, and that would mean that speedrunners would not be interested in this WAD. (Testing for demo desynching situation in PrBoom would be more difficult because of the way PrBoom emulates spechits overflows.) As a speedrunner my self, I find that it is most important that we do every thing we can (without sacrificing any quality to the WAD) to ensure that spechits overflows have a near zero chance of occurring and that this WAD is playable for as many port users as possible.
Again, if the removal of the error is of any sacrifice to the WAD it's self, then it should not be removed. But if it can be removed without any sacrifices to the features of the WAD, then it is an absolute must that it is removed.
PS. I'll try to come up with a better way of testing these WADs than Doom2+, as it is not something many WAD makers use and thus they can't test it them selves. I'll try to see if I can get a Windows port of Doom2+ that's identical to the real thing (Chocolate+ I guess? LOL).
|
06-30-12 07:42 
