Doom monster
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom
Pages (52): « First ... « 47 48 49 [50] 51 52 »  
Author
All times are GMT. The time now is 10:08. Post New Thread    Post A Reply
esselfortium
Cumulonimbus Antagonistic Posting


Posts: 5979
Registered: 01-02
No Rest For The Living isn't vanilla-compatible: it requires the removal of the visplane and drawsegs limits.
Old Post 10-27-12 06:35 #
esselfortium is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Sodaholic
Banned


Posts: 2204
Registered: 04-07
I myself view vanilla gameplay more in terms of ingame behavior of actors, physics, damage, stuff like that, not when and where it crashes.

I can easily understand if Fraggle doesn't want to add an option for limit removing just to run NERVE.WAD, but it'd be nice to be able to with a very vanilla feeling experience, even if it doesn't technically conform to visplane limits and such.
Old Post 10-27-12 11:48 #
Sodaholic is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
GreyGhost
a ghost... only grey


Posts: 6878
Registered: 01-08
Once you start fiddling with the static limits, where do you stop? Chocolate ZDoom?
Old Post 10-27-12 12:19 #
GreyGhost is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 9166
Registered: 07-07
Then use PrBoom+ with complevels 0, 1, 2, 3 or 4.
Old Post 10-27-12 13:10 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
chungy
Doomworld is so about bullshit excuses


Posts: 1694
Registered: 06-05
NRFTL is just part of the current XBLA, PS3, Windows, and Mac ports of the game. If it ran within vanilla limitations I wouldn't be objected to supporting it, but it requires expanded limits and I believe it should be treated just as any other Doom port: no special compensations in Chocolate Doom. NRFTL support is more proper in other ports like PrBoom+, Eternity, ZDoom, and all, but not Chocolate Doom.

Chocolate Doom is all about preserving the behavior of Doom(-based) engines that ran on DOS. That is Registered Doom/Doom 2 1.9, Ultimate Doom, Final Doom (both versions), Chex Quest, Hacx, Heretic, and Hexen. Doom 3: BFG Edition is not released for DOS (indeed, it would be ridiculous), and the special Doom 2 episode contained in it does not respect the DOS engine's limitations.

Oh also fraggle's hinted at not bothering to support doom2.wad from BFG Edition because of the TITLEPIC thing. IMO that one is fairly minor compared to the changes NRFTL would require.
Old Post 10-27-12 19:23 #
chungy is online now Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Sodaholic
Banned


Posts: 2204
Registered: 04-07
Well, I can certainly understand not supporting NERVE.WAD, since it certainly wasn't part of the original Doom experience in the 90's and is already incompatible in terms of rendering limits (even if it still only uses vanilla features in the maps). Not supporting the BFG IWADs also makes sense, since these were made for a newer version of the engine in mind, and not the original 1.9 release, and there's already incompatibilities like the TITLEPIC missing from Doom 2 (yet not Ultimate Doom, strangely enough).
Old Post 10-28-12 11:30 #
Sodaholic is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
myk


Posts: 14812
Registered: 04-02
Some people have apparently equated the term vanilla compatible with its out-of-the-box static limits, yet accepting DeHackEd as part of vanilla, when both DeHackEd and Doom+ (which you can get on the same page where you get PrBoom+) are widely available and well-known binary hacks that are compatible with vanilla.

Vanilla compatible is anything that runs with the vanilla DOS engine, including stuff like Hacx and No Rest for the Living. The latter has only one real vanilla compatibility issue: the hard-coded secret level, which makes vanilla or PrBoom+ users require an alternate copy of the WAD from levels 12-19 so that 31 can act as level 9 (normally reached through level 4), to play through the whole episode in proper order.

GreyGhost said:
Once you start fiddling with the static limits, where do you stop? Chocolate ZDoom?
In terms of defining vanilla compatibility that depends on what vanilla compatible add-ons that raise limits which are publicly available. Fraggle not wanting to add Doom+ support due to concerns that other hacks that raise limits may appear has nothing to do with vanilla compatibility, even though his choice may be a viable development line. In the front page of the Chocolate site it says that "Chocolate Doom is a Doom source port that accurately reproduces the experience of Doom as it was played in the 1990s." That and being "Doom compatible" are not necessarily synonymous. In fact, to get that experience through more solidly, it may well be a good choice to deviate somewhat from current Doom compatibility.

It is a conservative, historically accurate Doom source port, which is compatible with the thousands of mods and levels that were made before the Doom source code was released. Rather than flashy new graphics, Chocolate Doom's main features are its accurate reproduction of the game as it was played in the 1990s.
There it says it again in more detail, potentially implying that it makes no guarantees about vanilla compatible WADs created after that pre-source-release period.
Old Post 10-28-12 20:04 #
myk is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6578
Registered: 07-00
If I wanted to take a hard line I'd reject supporting both NRFTL and the new IWADs. Both cross the line to different extents, but sometimes I "bend the rules" for certain things. As it is, I've decided to support the new IWADs (which required the addition of only a small workaround), but not NRFTL (which requires more extensive and far reaching changes).

myk describes NRFTL as "Vanilla compatible" which I find interesting. I don't have a copy of BFG Edition or NERVE.WAD, but my understanding was that it exceeds the Vanilla limits, and that's my main objection to adding support for it. Is that incorrect?
Old Post 10-28-12 20:16 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Dragonsbrethren
Senior Member


Posts: 1460
Registered: 03-09
myk is just stretching the definition of vanilla compatible to remove the limits entirely and only refer to the gameplay. No Rest for the Lviing's maps definitely break the limits.
Old Post 10-28-12 20:52 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
myk


Posts: 14812
Registered: 04-02
Nah, that's what Sodaholic said. In fact, the gameplay can vary a lot in vanilla itself because of DeHackEd, because of modifications to actor or weapon behavior. "Gameplay" in Sodaholic's post is just "core engine physics or mechanics," which is only a part of gameplay, but that's a definition coming roughly from PrBoom's Doom compatibility settings... hence the appropriate reply that he should "go use PrBoom+".

Vanilla is the DOS engine or executables, thus compatibility with vanilla means that the WAD or add-on in question can be played with it, notwithstanding any other add-ons required to make this happen. Can vanilla run Deus Vult levels 1-4? Yes, if you patch the engine with Doom+. Can Doom run Batman Doom? Yes, if you patch the engine with DeHackEd. These two WADs aren't out-of-the-box Doom compatible, they aren't immediately compatible with vanilla. They are Doom compatible, but one is Chocolate Doom compatible and the other isn't. I noted above why; Chocolate Doom focuses on what defined vanilla compatibility in the 90s. Is that wrong? I don't think so, I understand Chocolate's founding role, but let's not define things incorrectly by saying DeHacked is vanilla compatible but Doom+ isn't.

Two related topics get mixed up here, what Chocolate Doom supports and the definition of Doom compatibility.
Old Post 10-28-12 21:26 #
myk is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 9166
Registered: 07-07
Vanilla, schmanilla. Even supporting DeHackEd patches is bending the rules a little, because a mod that relies on DeHackEd will not be compatible with certain official ports (such as Doom 95, or that Macintosh port from GT Interactive) that are otherwise fully compatible with 100% pure real unmodified organically-grown non-GM vanilla.

kb1 said:
Could you not just increase the static allocation, then test the index for being out-of-bounds, against a variable? (I might be missing something here...)

I thought of a more elegant method, I think:

code:
drawseg_t	bfgdrawsegs[MAXDRAWSEGS*2];

drawseg_t drawsegs = (bfgedition? bfgdrawsegs : bfgdrawsegs + MAXDRAWSEGS);


And similarly for visplanes.
Old Post 10-28-12 21:38 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
TimeOfDeath
Forum Regular


Posts: 2020
Registered: 06-06
Just curious, was the Doom+ hack used back in the mid-90's before the Doom source code was released, like Dehacked was?
Old Post 10-28-12 21:44 #
TimeOfDeath is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
myk


Posts: 14812
Registered: 04-02
Nope, entryway released it in 2006.
Old Post 10-28-12 21:53 #
myk is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
chungy
Doomworld is so about bullshit excuses


Posts: 1694
Registered: 06-05
DeHackEd support in Chocolate Doom is acceptable because it makes plenty of otherwise vanilla WADs playable. Yes, you can argue it stretches the rules a bit, as well as the built-in merging support, but all that is convenience of not having to hack Chocolate Doom's source code to account for every *.deh change, or load up external utilities to merge IWADs (it also keeps the on-disk ones clean).

TimeOfDeath: no.
Old Post 10-28-12 21:54 #
chungy is online now Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 9166
Registered: 07-07
TimeOfDeath said:
Just curious, was the Doom+ hack used back in the mid-90's before the Doom source code was released, like Dehacked was?

I think if the places in the exe were the static limits were stored were known back when DeHackEd was still actively developed, they would have become a DeHackEd feature.
Old Post 10-28-12 22:02 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
myk


Posts: 14812
Registered: 04-02
chungy said:
DeHackEd support in Chocolate Doom is acceptable because it makes plenty of otherwise vanilla WADs playable.
Why it's supported seems better answered by what I quoted above from the Chocolate Doom site. What you're saying also applies to Doom+. I play tons of limit removing WADs using Doom+ (which has a rough Chocolate-derived equivalent in Strawberry Doom). To boot, the concern that people may add more features to Doom+ also applies to DeHackEd. Someone could release a new version of DeHackEd, or a similar app that adds other actor, pointer or text possibilities not covered by DeHackEd.
Old Post 10-28-12 22:12 #
myk is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
hex11
Forum Staple


Posts: 2005
Registered: 09-09
TimeOfDeath said:
Just curious, was the Doom+ hack used back in the mid-90's before the Doom source code was released, like Dehacked was?


No, and that's exactly why to me vanilla DOOM can include DeHackEd (and any other mod tools available in '94-97) but can't have extended limits. It sounds arbitrary, but that's the way DOOM was during those early formative years and so that's what vanilla will always mean for me.

It's even weirder if you consider the limits were bumped-up by id themselves after DOOM 1.2. But in actuality, that version only lasted a very short time so it's more of a curiosity (like the alphas).

The other thing is extending limits tends to result in severe design changes which makes the end product look completely non-vanilla in some cases, especially when the mapper is also using high-res display (above 320x200). There is a tendency to overdetail every nook and cranny, with hordes of sectors and linedefs all over the place, so the end result feels more like an advanced port map.
Old Post 10-28-12 22:13 #
hex11 is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
myk


Posts: 14812
Registered: 04-02
hex11 said:
No, and that's exactly why to me vanilla DOOM can include DeHackEd (and any other mod tools available in '94-97) but can't have extended limits.
You mean Chocolate Doom. Chocolate Doom, its purpose and features do not define vanilla. This confusion is what I've been pointing out all along. If anything else, you mean 90s vanilla or pre-source-release vanilla, which are not equivalent to vanilla in general (something more vague) nor to current vanilla (what it is now).
Old Post 10-28-12 22:24 #
myk is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Dragonsbrethren
Senior Member


Posts: 1460
Registered: 03-09
hex11 said:
It's even weirder if you consider the limits were bumped-up by id themselves after DOOM 1.2. But in actuality, that version only lasted a very short time so it's more of a curiosity (like the alphas).

I test my vanilla, non-E4 Doom stuff with 1.0. I don't hold others to that standard, but it has more appeal to me than making a Doom map for the bumped up limits and new line actions intended for Doom 2.
Old Post 10-28-12 22:50 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
hex11
Forum Staple


Posts: 2005
Registered: 09-09
No that post was entirely about the DOOM alive during the early 90's (well for me up until 1999, since I didn't discover source ports until then).

Doom+ patch is a modern hack designed to extend vanilla's limits so it can play maps that are a direct result of modern source ports. People became accustomed to not having these arbitrary limits, and even forgot how to build within them (or sometimes never even knew, for the younger ones).

Incidentally not that many 90's PWADs used DeHackEd, and I think you're overstating that to make your case. In comparison, a large percentage of modern maps are limit-removing instead of vanilla. Again, people don't know, forgot, or can't be bothered to deal with those limits. But I don't like it much, it changes the map design too much, and results in people using tons of sectors for detail instead of just basic architecture and carefully-chosen textures. But then, I'm a minimalist in many ways...
Old Post 10-28-12 23:11 #
hex11 is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
_bruce_
Senior Member


Posts: 1045
Registered: 11-07
hex11 said:
... But I don't like it much, it changes the map design too much, and results in people using tons of sectors for detail instead of just basic architecture and carefully-chosen textures. But then, I'm a minimalist in many ways...


Right from my heart.
Old Post 10-28-12 23:51 #
_bruce_ is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
myk


Posts: 14812
Registered: 04-02
hex11 said:
No that post was entirely about the DOOM alive during the early 90's
Right, which is why I'm telling you how to say it in words that convey that clearly and aren't confusing.

Doom+ patch is a modern hack designed to extend vanilla's limits so it can play maps that are a direct result of modern source ports.
By saying "designed to" you're phrasing things in a normative manner that assumes an intention in what Doom+ is supposed to do. I'm guessing Andrey researched and released it because he could, because he likes tinkering with the engine and because it helped him investigate limit removing vanilla for demo compatibility in PrBoom+. After that, it just came to be and it's what it is, not what it's meant to be. Thus, yes, it can run a plethora of WADs released from 1998-2006 which vanilla couldn't run before, plus many other WADs from then on, including some specifically tested so they would run well in Doom+.

People became accustomed to not having these arbitrary limits, and even forgot how to build within them (or sometimes never even knew, for the younger ones).
Like I said more than eight years ago, more than a year before Chocolate Doom had its first change log entry.

Incidentally not that many 90's PWADs used DeHackEd, and I think you're overstating that to make your case.
My case is criticizing a sloppy use of Doom compatible, while pointing out how clearly Chocolate Doom primarily aims to support 90s vanilla instead of always keeping up with vanilla and being 100% vanilla compatible. If you think I'm saying vanilla is Doom+ in exclusion of Doom without raising the limits, you're confused. Vanilla and vanilla compatible don't mean the same thing. You get vanilla in the box, and you can use various compatible add-ons with it, some of which are required for others, such as DeHackEd for Aliens Doom.

I don't have anything against anyone sticking to 90s vanilla, on the contrary, nor that Chocolate aims to cater to it. I have suggested adding Doom+ support to Chocolate in the past, but after fraggle's responses, I don't have much against his choice and haven't made any statements in this thread demanding limit removal in Chocolate. I've simply argued against a misuse of terms which is muddling the debate but also affects much more than this particular discussion.
Old Post 10-29-12 01:23 #
myk is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Sodaholic
Banned


Posts: 2204
Registered: 04-07
myk said:
Nah, that's what Sodaholic said. In fact, the gameplay can vary a lot in vanilla itself because of DeHackEd, because of modifications to actor or weapon behavior. "Gameplay" in Sodaholic's post is just "core engine physics or mechanics," which is only a part of gameplay, but that's a definition coming roughly from PrBoom's Doom compatibility settings... hence the appropriate reply that he should "go use PrBoom+".

Nah, even regular PrBoom feels too unvanilla to me. The interface, menus, and everything surrounding the core gameplay mechanics makes it feel vanilla as well, and PrBoom in those regards feels to updated and modern for that. I understand that the settings can be tweaked to feel vanilla-ish, but still.

I'm not requesting anything, but I really wish there were a limit-removing commandline option. So everything except arbitrary rendering limits would still remain in an entirely vanilla experience. I guess it'd be called -nolimits or something.

Still, it reeeaallly stretches what you can call strictly vanilla, so I don't mind that anything of the sort won't be considered.
Old Post 10-29-12 02:54 #
Sodaholic is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
hex11
Forum Staple


Posts: 2005
Registered: 09-09
It seems to me the purpose of Doom+ is clearly defined, there's no need to guess:


Doom-plus is a patched version of the original DOS exe for Doom2 (version 1.9) with increased limits to reduce the risk of crashes, premature program exits and certain visual problems. This is done without loss of compatibility - in other respects, Doom-plus behaves exactly like the original DOS exe. Dehacked patches can be applied as normal, for instance, and any demo that plays back correctly with Doom2.exe will also play back with Doom-plus.

(that's directly from http://prboom-plus.sourceforge.net/)

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. 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).

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).
Old Post 10-29-12 05:01 #
hex11 is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
kb1
Junior Member


Posts: 229
Registered: 11-06
fraggle said:
If I wanted to take a hard line I'd reject supporting both NRFTL and the new IWADs. Both cross the line to different extents, but sometimes I "bend the rules" for certain things. As it is, I've decided to support the new IWADs (which required the addition of only a small workaround), but not NRFTL (which requires more extensive and far reaching changes).

myk describes NRFTL as "Vanilla compatible" which I find interesting. I don't have a copy of BFG Edition or NERVE.WAD, but my understanding was that it exceeds the Vanilla limits, and that's my main objection to adding support for it. Is that incorrect?
Nah, it's not incorrect. It all boils down to your port's philosophy. Personally, I'd support both.

The way I see it, Chocolate Doom serves 3 very different and distinct masters:

1. Map/WAD authors - These guys want to see every hard crash, every visplane overflow, and, yes, save game overruns. They'll want to use Chocolate to ensure that their creation is DOS vanilla compatible.

2. Knowledgable purist players - They want the game to look and feel exactly the way it did 20 years ago, but they don't want their game to crash!

3. Newbies, looking to see what Doom was all about, without hassle, without 150 settings to tweak. They don't want their game to crash either!

So, therein lies the problem. If I were running the show, I'd do the following:

1. Support NRFTL, for Person type #3.
2. Add a "-strict" option, to force all vanilla limits, including savegame size. Person type #1 would use this.
3. Up the limits a la Doom Plus, for Person Type #2.

NOTE: Maybe you would prefer to reverse the default: "-limitremoving". But I would suggest not to - only authors would typically use "-strict".

Yes, that's a big decision, but I don't think it deviates from the philosophy - It would be a port that provides non-crashing original bugs, and a damn close look and feel, even if the WAD has a lot of visplanes. That's a very desirable engine, for a lot of reasons. One would say "use PrBoom[+]", but, Chocolate could keep it's menus, resolution, graphics, etc. original, and avoid "gameplay-deviant" behavior, like Boom specials, etc. Basically, Doom, without crashes, conditional on the presense/absense of the "-strict" parameter.

Even if you didn't want to up the limits during play time, the "-strict" option would give you a place to "park" deviant behavior. Examples: Savegame limit removal, INTERPIC vs. TITLEPIC, visplane limit, etc. That way, it would perhaps become easier to decide whether or not to add support for this or that feature in the future. In other words, I feel that, right now, it's very difficult to decide what to support, because it's "all or nothing", whereas if you had a way to switch between two different ideologies, that would alleviate this tension.

Something to consider, anyway.
Old Post 10-29-12 20:53 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Dragonsbrethren
Senior Member


Posts: 1460
Registered: 03-09
I think player #2 and #3 need a different port entirely. They'd probably appreciate higher resolution, too. PrBoom-plus pretty much provides this if you run it with a complevel, but I can see why players would prefer something with fewer options. Luckily id has provided just that, if you're on Windows, with their official port. Which takes us back to why Chocolate Doom should even support higher limits in the first place, when there are better alternatives for modern wads.
Old Post 10-29-12 21:36 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
kb1
Junior Member


Posts: 229
Registered: 11-06
Maybe, maybe not. Sure, the knowledgable players can use PrBoom-Plus, or anything they want - that wasn't really the point.

Here's my hypotheses:

1. There is a definite group of people that want "Doom, as close as possible - i.e. Chocolate Doom as it is today".

2. A subset of the whole group uses Chocolate Doom to test their home-made WADs for compatibility with vanilla, which is the main reason people want it to "crash authentically" anyway.

3. A different subset uses Chocolate to play WADs. They want to get that "vanilla" experience, using larger WADs. This subset does not care about authentic hard-crashes, because they are playing to have fun. But they *do* want authentic gameplay.

4. Finally, there is another group of people that don't know what they want, just got Doom BFG Edition, want to run it "retro", and heard that Chocolate Doom ("Plus") does a kick-ass job of emulating that authentic Doom experience.

My conclusion is that, simply, there's no reason why Chocolate Doom would have to compromise it's "morals" to support each of these groups equally well:

- Chocolate Doom as a WAD validation tool
- Chocolate Doom as a stable Doom emulator
- Chocolate Doom as a fun game, as intended by id
- Chocolate Doom as the standard in authentic gameplay

It's not about adding features, it's about bringing that good ol' original Doom feel to a larger audience of people, and a larger range of PWADs. I think if id had packaged NRFTL with Final Doom, they would have upped the visplane limit. That's not a "feature" per se, it just making the Chocolate Doom experience work more often.

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'm interested in what you think about all this, fraggle!
Old Post 10-29-12 23:35 #
kb1 is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
hex11
Forum Staple


Posts: 2005
Registered: 09-09
It's the wishy-washy path that leads a project with solid, clear-cut goals to become just another port with a random collection of features the maintainers thought were cool. Just wait some years until id/ZeniMax/wtf releases yet another modern episode with Boom or ZDoom features (or something else entirely), and people will be asking for that to be supported too, because, hey it's "official".

I still don't understand why you don't just fork the code and release your own limit-removing port. It's so easy to do, there's only a dozen constants to change and then just recompile and you're done. Build a Win32 binary, and provide the diff for everyone else. You coulda had it all done several posts ago. :-)

You could probably even run this modern episode with ChocoRenderLimits, since that's effectively the port you're wanting. I don't know if the debug stuff will get in the way though (never used it myself).
Old Post 10-30-12 00:02 #
hex11 is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Dragonsbrethren
Senior Member


Posts: 1460
Registered: 03-09
So what's wrong with id's new engine? As far as I could tell when I played the XBLA demo, it's just vanilla in higher res with increased limits. It sounds exactly like what your hypothetical players would want. I don't understand why Chocolate Doom's design goals have to be compromised to support some fallacy that it's the only authentic engine. id's engine or PrBoom-plus with -complevel 2-4 is exactly what you're arguing for.
Old Post 10-30-12 00:07 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
GreyGhost
a ghost... only grey


Posts: 6878
Registered: 01-08
fraggle said:
I don't have a copy of BFG Edition or NERVE.WAD, but my understanding was that it exceeds the Vanilla limits, and that's my main objection to adding support for it. Is that incorrect?
Map08 of NERVE.WAD is the only one which doesn't trigger HOM and/or VPO warnings in CRL.

hex11 said:
You could probably even run this modern episode with ChocoRenderLimits, since that's effectively the port you're wanting. I don't know if the debug stuff will get in the way though (never used it myself).
You can and it does.
Old Post 10-30-12 06:24 #
GreyGhost is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 10:08. Post New Thread    Post A Reply
Pages (52): « First ... « 47 48 49 [50] 51 52 »  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts 		HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Message Board Statistics