Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Janizdreg

Chocolate Doom

Recommended Posts

Fraggle is as vanilla savy as it gets, so he will make the right decisions.
As for the limitless people - grab the code and recompile it with the specific '#defines' changed... should take ~5 minutes.
Include iwad changes and just call it SDLDoom or something.

Share this post


Link to post
hex11 said:

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.

Yep, that's an excellent point.

_bruce_ said:

Fraggle is as vanilla savy as it gets, so he will make the right decisions.

Well said.

Share this post


Link to post

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.

Share this post


Link to post

It's not just about the limits, it's also about all the other quirks in doom.exe. Mappers who can't be bothered to deal with limits also can't be bothered to care about tutti fruti, very limited linedef types, and all the other legacy that is part of vanilla. When I test peole's projects (even those of excellent, knowledgeable and experienced mappers), I'm constantly findind these types of bugs. Wouldn't it be great if we didn't have to deal with that annoying stuff too?... The other engines have a number of hacks in them to automagically fix any "broken" constructs. So to please those 95% of mappers you'd have to fix every damn "bug", and yet those are exactly what Chocolate Doom is working hard to emulate.

And you keep saying this new official version is also vanilla, but that's irrelevant since Chocolate Doom only cares about one very specific version of vanilla engine. When I wanted to play the 1.2 IWAD earlier this month, I had to run that doom.exe. Why doesn't Chocolate Doom emulate that version too? Hey, it's at least as significant as any modern version of the code, and even more so from a historical perspective.

A modern port that behaves EXACTLY like PC/DOS DOOM 1.9 - not 1.2, not this 2012 mod, and runs natively on many platforms, some of which may not even be able to run DOSBox (at least not at acceptable speed). Heck, DOSBox doesn't even run doom.exe at full framerate on my 1.8 GHz laptop. I stopped playing that way because it was just too damn slow. Now some other people got weaker hardware, and even completely different architecture entirely (ARM, etc.) We have slow netbooks and portable games consoles where it's the battery life that matters more than raw power. If you think just running DOSBox is the answer, then please send everyone some money so they can buy brand new top-of-the-line laptops (AlienWare for me plz). And besides, it's annoying to have to switch back and forth between native and VM. I used DEU 5.21 to edit recently, because I was running doom.exe. But as soon as I can run Yadex again, no more damn VM.

You know what, if Chocolate Doom didn't exist, I would be running SDL Doom (yes, that's already a port BTW - just a straight conversion of LinuxDoom to SDL, nothing else extra or changed). But of course I would have also needed to write my own DeHackEd equivalent (it would have been a separate tool, like the original) and just get the music playing again. That's it, nothing else. That's as close as I could ever manage to get to the original, since I don't know all the little details of the engine and what's different between doomsrc, the "real" LinuxDoom (before that guy changed stuff for fun), and DOS 1.9 version.

Share this post


Link to post
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.

myk said:

I don't think so, ...

Sorry, which part were you referring to? That it's beautiful, that it's basically done, that it's fulfilling it's purpose, that mentioned changes would not be a compromise? (not fighting, I honestly didn't get the meaning)

myk said:

...and I think hex11's comment about wishy washy was a critique of your post rather than an unconnected wise saying.

Nah, I read it as: "Vanilla is concretely definable, anything beyond that becomes less-defined, where you're trying to decide which feature-of-the-day to add." Wishy-washy. I acknowledge hex11 for this statement, and fully agree.

myk said:

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.

I think there's only 3 reasons people don't ignore limits:
1. They have no choice.
2. They're making a vanilla-compatible map.
3. Curiosity.

People already nag fraggle, and he's caved a couple of times. And in doing so, some tension was created - namely, where do you draw the line? Vanilla vs. new features. TITLEPIC vs. INTERPIC. NERVE.WAD.

I'm not trying to get fraggle to change his philosophy. My posts were designed to merely suggest that, you can keep a pure engine, and deviate at the same time, without losing anything. Have your cake and eat it too, so to speak. To be successful, you have to predefine how to turn off the "deviant features", with a single directive: -pure, -vanilla, -strict, etc. Or even inverted logic: -limitremoving, -nrftl, etc.

I think it would be a worthy endeavor to add such a switch, even if your only "feature set" is, say, savegame-limit-removal and interpic-vs-titlepic. Especially for Chocolate, I would personally avoid having too many of those switches. One would do.

In summary, by deciding to encapsule all deviation inside a switch, fraggle is free to add as much or as little deviation as he desires, without worrying about "de-purifying" the port. If he wants to consider supporting some funky wad, for whatever reason, that can be placed under this same umbrella. It eases the burden of deciding what to support.

Share this post


Link to post
kb1 said:

In summary, by deciding to encapsule all deviation inside a switch

And that's basically PrBoom's complevels.

How about forking Choco to remove limits (cf. Strawberry Doom) and stop nagging Fraggle?

Or how about forking PrBoom+ to change back the menu into its original form?

Share this post


Link to post
kb1 said:

I think there's only 3 reasons people don't ignore limits:
1. They have no choice.
2. They're making a vanilla-compatible map.
3. Curiosity.

4. I mostly play vanilla-compatible maps

It comes down to which port a particular wad was designed for. If it was designed for vanilla or chocolate, I use chocolate. If it was designed for limit removing, I use prboom+. If it was designed for zdoom, I use zdoom.

NRFTL was not designed for vanilla or chocolate, so there shouldn't be any expectation for it to run in either.

Share this post


Link to post

kb1 said:
Sorry, which part were you referring to? That it's beautiful, that it's basically done, that it's fulfilling it's purpose, that mentioned changes would not be a compromise? (not fighting, I honestly didn't get the meaning)

The latter. I detailed why in the following paragraph :p

I think there's only 3 reasons people don't ignore limits:
1. They have no choice.
2. They're making a vanilla-compatible map.
3. Curiosity.

I can't argue against that from personal experience because once Doom+ became available, I initially used pure vanilla for WADs declared for vanilla, and applied the Doom+ hack for "limit removing" WADs. But after a period, I said "what the heck" and started using Doom+ regularly for both unless I was obligated to use pure vanilla, such as for a Compet~n demo or the like.

In any case, aside from being the default way the game behaves and considering the amount of vanilla PWADs in the archive, which will always make it current, vanilla mapping does define a certain vague simple style by its limits. Some people like that and, as a result, #2 can become chronic because some want to always be ready to provide input on any bugs in vanilla maps. If that weren't the case, map testing would only be specific, conscious and limited. A large chunk of bug fixing comes from regular playing.

If Chocolate had a limit removal option, pure vanilla mapping would be diminished. It would still be supported by Chocolate, but more weakly because many of its users would remove the limit, and somewhat more by vanilla on DOSBox, but there would be less levels within the original limits.

Not that I would complain that much if Chocolate had a Doom+ limit raising option. With more people doing what I'm doing, it would just make me find less bugs on levels that exceed pure vanilla limits but are within Doom+ limits! But either way, since today many level designers are relatively knowledgeable about vanilla and -complevel 2, at least those bugs aren't as common as in the earlier 00s, and vanilla bug avoidance tends to pass on to limit removal, which is useful for more universal map design because not all ports have workarounds to all the vanilla weaknesses, but they all run vanilla levels.

Share this post


Link to post
Gez said:

And that's basically PrBoom's complevels.

How about forking Choco to remove limits (cf. Strawberry Doom) and stop nagging Fraggle?

Or how about forking PrBoom+ to change back the menu into its original form?

PrBoom would indeed be a deviation, and would obscure Chocolate Doom's mission.

It's so hard to convey meaning in a post. I wasn't intending to nag fraggle - if that's what I was doing, then fraggle, I apologize. I assume that input from the community is desired. On more than one occasion, this question of "Will Chocolate Doom support feature/wad X?" has occurred, and, especially with Chocolate Doom, it's seems to be a difficult decision process.

Indeed my goal was to lessen the impact of nagging, by suggesting that it's important to design a mechanism that can enclose any future changes. Changes that fraggle may or may not decide that he wants to add.

I was not suggesting that fraggle had to add anything that he didn't want to. Instead, I was merely pointing out that, from a development perspective, it makes sense to have already built a way to segregate any possible desired future change, so that the impact of any new features can be isolated.

Once again, if it sounded like I was demanding changes, that was not my intention. Damn, I was just trying to be helpful. Oh well, carry on. I'm sure fraggle will the right thing :)

-> myk: Largely agree. You know, it's really unfortunate that id endorsed this incompatible NRFTL - this discussion would be mainly unnecessary otherwise.

I just think that, from a newbie/naive perspective, it's reasonable to expect that Chocolate Doom can play the id-supplied levels properly. I think in the minds of someone new to Doom, it will reflect negatively on Chocolate Doom if NRFTL fails, even though Chocolate Doom is doing nothing wrong.

Anyway, Happy Halloween everyone!

Share this post


Link to post

On the subject of entryway's + hacks, is Chocolate Heretic in a vanilla compatible state yet? I want to compile a copy with increased limits matching Heretic+ for this project, since as I mention in that thread there's really no PrBoom equivalent for Heretic, and I figure more people would be happy with a native executable than running the hack in DOSBox. I haven't really followed raven/v2 branch development but I seem to remember some posts about it not playing back vanilla demos (I realize the opening demos are for 1.2 and don't even play back in vanilla).

Share this post


Link to post

Someone recently dropped by #chocolate-doom to ask about using Doomseeker for finding and launching Chocolate Doom multiplayer games. He said he wasn't able to join a game and that Chocolate didn't even launch. Unfortunately he left before I could ask him further details on the issue.

So out of curiosity I tried setting up Doomseeker on my own system (Win7). I believe I've configured it correctly, with correct paths to the IWADs and game executable(s). But when I choose to join the only available (empty) server and configure the match launch parameters in the Doomseeker popup window, Doomseeker simply crashes upon trying to launch Chocolate. I've tried numerous different parameter strings, but they all seem to crash Doomseeker. What gives?

Share this post


Link to post

Trying to get the build-chocolate-doom script to work on MinGW. The reason? I need clean, optimized DLLs, that's why. the output I get:

=======================================================
Building SDL_mixer version 1.2.12
=======================================================

Downloading tar file...
--2012-11-09 16:08:12--  http://www.libsdl.org/projects/SDL_mixer/release/SDL_mixer-1.2.12.tar.gz
Resolving libsdl.org... 69.163.143.10
Connecting to libsdl.org|69.163.143.10|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3707781 (3.5M) [application/x-tar]
Saving to: `STDOUT'

100%[======================================>] 3,707,781    507K/s   in 7.7s

2012-11-09 16:08:20 (471 KB/s) - written to stdout [3707781/3707781]

Extracting...
tar: SDL_mixer-1.2.12/Xcode/Frameworks/Vorbis.framework/Headers: Cannot create symlink to `Versions/Current/Headers': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/Vorbis.framework/Resources: Cannot create symlink to `Versions/Current/Resources': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/Vorbis.framework/Versions/Current: Cannot create symlink to `A': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/smpeg.framework/Headers: Cannot create symlink to `Versions/Current/Headers': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/smpeg.framework/Resources: Cannot create symlink to `Versions/Current/Resources': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/smpeg.framework/Versions/Current: Cannot create symlink to `A': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/Ogg.framework/Headers: Cannot create symlink to `Versions/Current/Headers': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/Ogg.framework/Resources: Cannot create symlink to `Versions/Current/Resources': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/Ogg.framework/Versions/Current: Cannot create symlink to `A': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/mikmod.framework/Headers: Cannot create symlink to `Versions/Current/Headers': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/mikmod.framework/Resources: Cannot create symlink to `Versions/Current/Resources': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/mikmod.framework/Versions/Current: Cannot create symlink to `A': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/FLAC.framework/Headers: Cannot create symlink to `Versions/Current/Headers': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/FLAC.framework/Resources: Cannot create symlink to `Versions/Current/Resources': File exists
tar: SDL_mixer-1.2.12/Xcode/Frameworks/FLAC.framework/Versions/Current: Cannot create symlink to `A': File exists
tar: Exiting with failure status due to previous errors
Archive failed to extract and is possibly corrupted.
Please run this script again.
Oopsie. Any ideas?

EDIT: fixed by removing XCode from the tar archive.

Share this post


Link to post
Janizdreg said:

Someone recently dropped by #chocolate-doom to ask about using Doomseeker for finding and launching Chocolate Doom multiplayer games. He said he wasn't able to join a game and that Chocolate didn't even launch. Unfortunately he left before I could ask him further details on the issue.

It was a bug. Fixed.

Share this post


Link to post

I've been playing around with the Chocolate DOOM source code, learning C as I go, and I was wondering if someone could help me... What would it take to alter said source to scale it to 640x400 in the same way it scales to 320x200 now? It would seem its not a simple matter of just changing SCREENWIDTH to 640 and SCREENHEIGHT to 400 in doomdef.h.

Share this post


Link to post

I'm not a programmer, but just for fun, I compared older source ports to Chocolate-Doom and tried to merge their high-resolution code into it. After a lot of trial and error I got it working. It seems to clash with Chocolate-Doom's scaling options, meaning it only works on certain Chocolate-Doom resolution settings. I can provide my source/binaries if you are interested. You would have to compare the code against Chocolate-Doom 1.7.0 to find my changes.

Share this post


Link to post

In Both 1.7.0 and v2, players using different endians cannot play with each other (at least on Debian Wheezy).

I've never used SDL_net. If some versions of SDL_net work while others do not, then you could auto detect whether byte swapping is needed or not.

Share this post


Link to post

That sounds pretty unlikely. The way that the networking code is implemented, it should be impossible for errors like that to occur. Are you sure that it's an endianness problem and not something else?

Share this post


Link to post

Actually, there is no endian issue, sorry about that. The issue is that on my server I have multiple IPs. If I listen on any address and any port, Chocolate Doom seems to be incapable of responding on the correct address.

So for example:

eth0 is an interface.
eth0 has two IPs, eth0:0 has 169.254.100.100 and eth0:1 has 169.254.100.200.
The client trying to connect has address 169.254.50.50
Connecting to 169.254.100.100 works.
Connecting to 169.254.100.200 fails.

chocolate-server appears to send the reply on the first address rather than the address that the client connected from. Of course with UDP is it only possible to know the remote address from the other side when the server is bound to a specific address.

So what Chocolate Doom needs to binding to a specific address, like many other servers.

In another topic, you can easily fix the wrong IP being in reversed order on the network connection screen along with the "Connected to" and "Failed to connect to" messages.

Hope this makes sense!

Share this post


Link to post

OPL mode sounds horrible with Alien Vendetta, like some kind of unholy mix of DOOM32X rejects and a Beavis & Butthead fartknocker marathon. Other stuff like Memento Mori II, Icarus: AV, IWADs, etc. all sound okay in OPL. So what's the deal with this megawad? Does it even play correctly with doom2.exe and a real SB?

Share this post


Link to post

It's a known bug. Alien vendetta's music uses some MIDI stuff that Chocolate Doom gets confused by. I've actually done some work on this recently that improves it but it still needs a bit more work.

Share this post


Link to post

Does this affect other ports with OPL emulation, such as PrBoom+ or ZDoom? If not, code comparisons might help.

Share this post


Link to post

How do I set up keyboard controls in Chocolate Heretic? I've just downloaded the latest SVN but there doesn't seem to be a setup program a la chocolate-setup.exe for Heretic...

Share this post


Link to post

Normally you would use chocolate-setup, but it's not linking correctly in the current revision with my automated build system. I have filed a bug report. Thanks for bringing it to my attention.

Share this post


Link to post

Has someone made a Doom+ equivalent version of Chocolate-Doom? With the following changes:

limit                         : old    * k   = new
-------------------------------------------------------
visplanes[MAXVISPLANES]       : 128    * 8   = 1024
drawsegs[MAXDRAWSEGS]         : 256    * 8   = 2048
SAVEGAMESIZE                  : 180224 * 16  = 2883584
activeplats[MAXPLATS]         : 30     * 256 = 7680
vissprites[MAXVISSPRITE]      : 128    * 8   = 1024
linespeciallist[MAXLINEANIMS] : 64     * 256 = 16384
openings[MAXOPENINGS]         : 16384  * 4   = 65536
(MAXVISSPRITE is the most important one for me, HR2 map 32 is getting annoying.)

I personally think this should be included as an option in the official release because increasing savegame limits, recording long ticks, and altering weapon keys (plus other things) have also been implemented as options but I'm not going to push for it beyond humbly stating my opinion. As long as a version exists, I'm fine.

PS. I took a look at this but I don't understand how to compile it into the Chocolate-Doom source code (sorry if I just said something stupid, I don't understand any of this programing business, anything more complex than QBASIC is completely foreign to me) or if it's even what I'm looking for. I have read the last 3-4 pages of this thread so I kinda understand the previous discussion that took place here.

Myk talked of Strawberry Doom but I don't like it's lack of Vanillaness.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×