Chocolate Doom and "Computer Deathmatch v1.6"

Doomworld Forums : Powered by vBulletin version 2.2.5

Doomworld Forums > Classic Doom > Source Ports > Chocolate Doom and "Computer Deathmatch v1.6"

Pages (2): [1] 2 »

Author

All times are GMT. The time now is 23:29.

Porsche Monty
Member

Posts: 456
Registered: 06-10

http://www.giffer.com/public/dos/pg...es/IMMYDM16.ZIP

For anyone unfamiliar with IMMYDM, this was a sort of primitive modification that made it possible to play against bots in Doom2.

How it works is beyond me, and unfortunately it relies on a custom executable, some .dat files and even a couple of .com's that seem to be extracted during runtime, so support for this may be completely out of the question.

Works on my current Vanilla Doom2 installation (80486) except it won't display a certain menu mentioned in the official documentation, but IIRC, it didn't work back in the day either.

Any chance, as slim as it could be? just a small piece of Doom history which I believe deserves a second chance.

Regards.

12-03-10 05:28 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

I've played alot of this and stopped playing once I kicked all the enemy's asses since in the end they were real easy to beat regardless. To support something like this you'd have to disassemble what was modied in the original executable. From what I gather when I tried reverse engineering it was that it was more than just DeHackEd work. It was pretty interesting so this was my insipiration for my artificial intelligence programming in Doom. I've done a bunch of work on it but I just need to combine all my work and make something that can work well and work correctly.

12-03-10 05:37 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10193
Registered: 07-06

code:
Green Dude - Pistol and Shotgun. Each have 300 hps
             Will attack the nearest player...95% accuracy...pistol 
             dude will always go splat)They both will strafe (50% of
             the time) when you attack them.

Indigo Dude - Shoots Rockets, Have 200 hps (two rockets will give him 
              a taste of his own medicine). Will attack you from long 
              range...90% accuracy.

Brown Dude -  Chaingun, 200 hps. 75% accuracy. Will try to attack long
              range, but will miss eventually, dangerous if in close 
              range.
              Plasma, 150 Hps. 90% accuracy. Beware this cheap dude,
              will fire plasma constantly. Doesn't move around a lot,
              a taste of  his own medicine will have him splattered. 

Red Dude - BFG, 100 hps, 80% accuracy. Will try to kill you at all  
           costs, big red meanie from hell with an attitude. Will try
           to hit you from the  back or hit walls to wipe out 
           everyone. He is capable of firing a several rounds of bfg's  
           at his own will! Beware, his bfg has no warning power-up, 
           so it will come out insantly! His bfg's will even 
           wipe you out even if you have GOD MODE ON!

ROFLMAO, they sound like ZDaemon LBPs ;-)

12-03-10 09:27 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Never_Again
knows his birth month

Posts: 917
Registered: 04-03

I wonder if the author is the same Immy that went on to be a q2.god.

12-03-10 13:06 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

I remember reading about this wayyyy back in the day and almost thought it had to be a hoax or something. I have no idea how this was done during the time period it was done in. >_>

12-03-10 16:51 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

Quasar said:
I remember reading about this wayyyy back in the day and almost thought it had to be a hoax or something. I have no idea how this was done during the time period it was done in. >_>

Disassembler!

12-04-10 04:32 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Csonicgo

Posts: 4305
Registered: 03-04

Porsche Monty said:

Any chance, as slim as it could be? just a small piece of Doom history which I believe deserves a second chance.

I think that if we start allowing things like this, we should allow doom+ modes as well. Since, naturally, that won't happen, this won't either. There were lots of Programs like this that I remember that randomized items, some even modified game data for new levels (imagine E1M1 with the same blockmap but different paths, it's on D!Zone iirc) That were buggy, too many to list. DeHackEd is supported just from it being a doom community standard.

12-04-10 06:08 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Porsche Monty
Member

Posts: 456
Registered: 06-10

Csonicgo said:

I think that if we start allowing things like this, we should allow doom+ modes as well. Since, naturally, that won't happen, this won't either

No we should not, that's what prBoom+ is for. Chocolate Doom should stay vanilla-compatible, no more, no less, and this particular modification was intended for use with vanilla, it's just that it would be presumably difficult to support.

Recently an exception for Hacx 1.2's internal dehacked was added (something I wouldn't have expected to happen) but I guess that's minor compared to this, or even the infamous bunny3d, but then you have the "-merge" command for actual wads, so...

I say don't support anything vanilla didn't, that's where I'd draw the line, but it's not our project so we don't get to decide what goes and what doesn't.

12-04-10 07:08 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6571
Registered: 07-00

It looks interesting and I'm surprised I've never heard of it before. At first I thought it was a lot more clever but it does seem to just be an executable hack, with what looks like a fake IPX driver to make the game run as a 1-player netgame. This ensures that the level doesn't restart every time the player respawns.

The fake players are monsters (load IMMY-DM.WAD with the normal executable to see). I assume it's running the game with the -respawn parameter so that they come back after they're killed. They always use the same weapons. The game still doesn't consider them real players as the frag count doesn't increase when you kill them, and you'll notice that the animations aren't quite right either (the "injured" frame is the first frame of the player death animation).

I think it's entirely possible that it might just be a dehacked-style mod, although if it is then it's certainly a fairly "advanced" one. If that's the case it should be possible to reverse engineer it into a straight dehacked patch. I'm intrigued to see what GhostlyDeath has found out about it.

12-04-10 13:02 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14809
Registered: 04-02

Porsche Monty said:
No we should not, that's what prBoom+ is for.

No it isn't. PrBoom+, even in vanilla compatibility mode, makes many changes over Doom and Doom+. That is why many WADs tested with it and not with Doom or Doom+ display tutti frutti or medusa glitches, if not other issues. Strawberry Doom is currently filling in Doom+'s role among ports, but having two separate executable files when a parameter or option could work perfectly in one is dumb and counterproductive.

I say don't support anything vanilla didn't, that's where I'd draw the line, but it's not our project so we don't get to decide what goes and what doesn't.

Vanilla supports the Doom+ hacks in all its latest versions, which are compatible with all other vanilla add-ons and patches, just as much as it supports DeHackEd, and Doom+ itself can be considered a community standard, as various WADs were made while testing with it. Here's an obvious example.

12-05-10 15:06 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Porsche Monty
Member

Posts: 456
Registered: 06-10

myk said:
No it isn't. PrBoom+, even in vanilla compatibility mode, makes many changes over Doom and Doom+. That is why many WADs tested with it and not with Doom or Doom+ display tutti frutti or medusa glitches, if not other issues

So prBoom+ shows Tutti Frutti/Medusa where there would normally be any? that's something for the prBoom+ developers to fix. Right now not even Chocolate Doom gets the Tutti Frutti glitch correct, displaying it where it's supposed to but using the wrong colours. So far you've mentioned purely graphical abnormalities, nothing that would stop a demo from playing back correctly in prBoom+

myk said:
Strawberry Doom is currently filling in Doom+'s role among ports, but having two separate executable files when a parameter or option could work perfectly in one is dumb and counterproductive

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

myk said:
Vanilla supports the Doom+ hacks in all its latest versions

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.

myk said:
which are compatible with all other vanilla add-ons and patches, just as much as it supports DeHackEd, and Doom+ itself can be considered a community standard, as various WADs were made while testing with it. Here's an obvious example.

Limitless ports are the standard for limitless maps. Everything not working in Vanilla shouldn't work in Chocolate either.

12-05-10 22:32 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Xaser
Forum Staple

Posts: 2122
Registered: 07-03

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?

12-05-10 22:49 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Graf Zahl
Why don't I have a custom title by now?!

Posts: 7451
Registered: 01-03

IIRC it's a hacked version of Doom.exe with increased limits.

@Porsche Monty: Whether Chocolate Doom adds a Doom+ mode is entirely up to fraggle and nobody else. He's the only person who should decide what CD is supposed to be and what not. And if he wants to, you have no right to demand from him not to do it.

12-05-10 22:59 #

Profile || Blog || PM || Email || Search || Add Buddy

IP || Edit/Delete || Quote

Gez
Why don't I have a custom title by now?!

Posts: 9159
Registered: 07-07

Basically, Doom+ is the vanilla doom.exe where a few values have been hex-edited. I'm not sure which exactly, but several of Doom's limits are caused simply by the use of static arrays, so I guess what Doom+ does is change the value corresponding to the size of these arrays.

Since Chocolate Doom already has an option for using a larger save buffer, I don't think its purity would be compromised if there was a similar option for using Doom+ instead of Doom limits. But maintaining Strawberry Doom isn't that hard (if you can compile Chocolate): you can just increase the #defined sizes yourself. There's no code logic to modify.

12-05-10 23:08 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10193
Registered: 07-06

Porsche Monty said:
So prBoom+ shows Tutti Frutti/Medusa where there would normally be any?

I think myk meant that using a Boom derivative for testing "vanilla compatible" stuff can result in a lot of stuff being broken. AFAIK Boom (and everything expanding on it) have eliminated medusa and tutti frutti at the column renderer level (too short one-sided textures will tile rather than tutti-fruiting, which is why I adopted Boom's column function for Mocha Doom, rather than the original, which would require me to catch overflows every time).

Porsche Monty said:
So far you've mentioned purely graphical abnormalities, nothing that would stop a demo from playing back correctly in prBoom+

Unless you can formally prove on paper that graphics output in vanilla Doom couldn't interfere at all with any other part of the game and was a one way affair, you're in no position to claim that. Yes, I know that in bomb-proof code that ridiculous level of anality wouldn't be required, but if there's anything unlike it it's Doom, especially when tampering with limits.

Furthermore, I'd add that there are vanilla demos that won't play back correctly if not on the same machine that created them, and that's by using the same exact memory/register state (e.g. if you played 3 rounds of Bubble Bobble, one random flip-flop glitched, you loaded and unloaded smartdrive just for the kicks, and then played Doom recording a demo, only then you'll get the same exact behavior, including the same color of tutti frutti). And that at the same system timer accuracy. Dead-on. Which is well beyond what Chocolate Doom or even DOSBOX can ever hope to replicate.

Porsche Monty said:
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.

I think myk was referring to the fact that demos recorded with Doom+ (myk, maybe you meant Doom v1.91?) and thus with greater mouse resolution are playable in plain vanilla v1.9, or that Doom+ is able to play most vanilla demos perfectly (except those that were supposed to crash, which obviously won't). Of that it's possible to produce vanilla-playable demos with prBoom+. Dunno, too many typos on both parts.

12-05-10 23:17 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6571
Registered: 07-00

Graf Zahl said:
@Porsche Monty: Whether Chocolate Doom adds a Doom+ mode is entirely up to fraggle and nobody else. He's the only person who should decide what CD is supposed to be and what not. And if he wants to, you have no right to demand from him not to do it.

Thank you.

To clarify, the main reason for not implementing Doom+-style limits is to preserve my own sanity.

When I started develop Chocolate Doom, one of the key things that convinced me that I wanted to make it was that I could define an aim for the project. As you know, I already tried the "generic source port" route (like what ZDoom does). The problem with projects like that is that (1) it's a pretty thankless task and (2) there is literally an endless list of features that people want you to implement. OpenGL graphics? Client-server multiplayer? New editing features? AI Bots?

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.

12-05-10 23:56 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Porsche Monty
Member

Posts: 456
Registered: 06-10

Graf Zahl said:
@Porsche Monty: Whether Chocolate Doom adds a Doom+ mode is entirely up to fraggle and nobody else. He's the only person who should decide what CD is supposed to be and what not. And if he wants to, you have no right to demand from him not to do it.

That's exactly why I said "but it's not our project so we don't get to decide what goes and what doesn't" on my previous reply. It's no secret people here never read and love being antagonistic.

12-06-10 00:04 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

I stopped working on Strawberry Doom and I consider it dead.

As for IMMYDM, when I poked around in it that was back in 2003/2004 which is a very long time ago.

Looking at the files again:

IMMYDM1.DAT is the fake packet driver, but not really fake. It's for the NE2000 card (and surprisingly there's mention of "This program is free software; see the COPYING file for details) which has a high chance of being GPL.

IMMYDM2.DAT is the IPX driver, looking at the binary it's Novell driver.

IMMY-DM.DAT is DOOM2.EXE with whatever modifiations it made. The binary diff (bsdiff) is only 700 bytes long

The version of Doom 2 (1.9) is: 3104d991e2893d982220030ab714fc3fc079f7b4bb88c0e8e47403d75a68b2aefd381893fde
0b4932373d71e530b1ed8c32fb5619f135644cdc65a1bec5bbda2 doom2.exe
30ecefdb9da5733cd2e501e416c292a65f1fc1d68fc07859eeba166dd44709f1cae6800be38
aba10a54503eebbae3c724c484e1ca26386c55430ce467f2a930b IMMY-DM.DAT

Looking at the EXE unrelated, I wonder what "Bad I_UpdateBox (%i, %i, %i, %i)" means...

So from the looks of the binary it's just a DeHackEd patch. I'll have to hack up a doom2.exe to DEH converter if one doesn't already exist.

EDIT: If you don't like what's in a port, fork it (as long as the license permits).

12-06-10 02:59 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

GhostlyDeath said:
Looking at the EXE unrelated, I wonder what "Bad I_UpdateBox (%i, %i, %i, %i)" means...

I_UpdateBox is the function in the original DOS low-level video code which pushes dirty rects to the currently active page of VGA video memory.

None of this code ever made it into the release - the dirty rects system was ripped out along with all the DOS code when the game was ported to Linux.

It also didn't survive into Heretic or Hexen, because Raven also removed it for some reason when they arbitrarily changed Heretic over to using vanilla Mode 13h instead of a tweaked Mode Y (no page flipping in those games at all - made them feel slower on a 486).

It IS intact in Strife, and that's why I'm familiar with it. It was also already present and mostly functional in the prebeta EXE. However we don't have the original code for either of those.

12-06-10 03:07 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

GhostlyDeath
Forum Retard

Posts: 1008
Registered: 08-05

Quasar said:

I_UpdateBox is the function in the original DOS low-level video code which pushes dirty rects to the currently active page of VGA video memory. ... However we don't have the original code for either of those.

Well I do know that the dirty rectangle system goes along with V_MarkRect().

12-06-10 03:32 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Grazza
Inventor of "Y Y" to quit

Posts: 11784
Registered: 07-02

Porsche Monty said:
So prBoom+ shows Tutti Frutti/Medusa where there would[n't] normally be any?

No, the opposite. It doesn't display them in cases where they would occur in vanilla.

If you only test a wad that is intended to be strictly vanilla compatible in prboom+ with -complevel 2, then you won't detect certain type of visual glitches, or problems (such as crashes) due to exceeding certain limits. There are also some types of wad errors that it fixes on the fly, to avoid a crash. But it does emulate the in-game behaviour precisely in other respects.

Info on the raised limits in Doom+ can be found here. Note that this should not be confused with "Doom 1.91", which modified the exe to use longtics for recording and playback. That was a separate project entirely. The two hacks can be used together though. To clarify: Doom+ maintains demo full compatibility with vanilla (unless the relevant limits are exceeded), whereas Doom 1.91 has no demo compatibility with vanilla.

12-06-10 04:02 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Porsche Monty
Member

Posts: 456
Registered: 06-10

Maes said:
Unless you can formally prove on paper that graphics output in vanilla Doom couldn't interfere at all with any other part of the game and was a one way affair, you're in no position to claim that. Yes, I know that in bomb-proof code that ridiculous level of anality wouldn't be required, but if there's anything unlike it it's Doom, especially when tampering with limits.

If it involves anything other than graphics, then it's not purely graphical.

Maes said:
Furthermore, I'd add that there are vanilla demos that won't play back correctly if not on the same machine that created them, and that's by using the same exact memory/register state (e.g. if you played 3 rounds of Bubble Bobble, one random flip-flop glitched, you loaded and unloaded smartdrive just for the kicks, and then played Doom recording a demo, only then you'll get the same exact behavior, including the same color of tutti frutti). And that at the same system timer accuracy. Dead-on. Which is well beyond what Chocolate Doom or even DOSBOX can ever hope to replicate

Very interesting. I had heard about the demo playback issue but I didn't know this also affected the colours for the tutti frutti glitch.

12-06-10 07:43 #

Profile || Blog || PM || Search || Add Buddy

IP || Edit/Delete || Quote

Maes
I like big butts!

Posts: 10193
Registered: 07-06

Porsche Monty said:
If it involves anything other than graphics, then it's not purely graphical.

Well, the renderer and graphics subsystem does read -but not write to- map data, and it's able to call file I/O, memory caching and Z_Malloc subsystems. Only on a machine with maxed out RAM, no cache unloading etc. you can have a relatively steady situation, but otherwise it's fair game.

Also, there are overflow checks in the most basic rendering functions (in-game column renders are obviously not checked) that can "leak" beyond the screen buffer, and once again it would take a guru to know where THAT is situated (actually, there are five of them, so it's very improbable that a screen write would corrupt game data, but theoretically it's possible).

The most common overflows are those regarding visplanes (some are explicitly checked and may break the game, but it's possible to exceed the visplane limit without it being caught immediately). Similarly, vissprites and ssegs overflow silently, so even if they are not -per se- raw screen writes, it's possible that they will go overwrite where they are not supposed to. Thinkers are quire different than the rest of vanilla's Doom objects in that they're the only truly dynamically allocated and garbage collected structure, almost like the way you'd think of Java and C++ objects. As such, they may be "poked" just about anywhere in memory, as malloc sees fit (OK, I'm over-generalizing here and some C/C++ gurus/compiler designers may cringe, but as a principle it's true).

Porsche Monty said:
Very interesting. I had heard about the demo playback issue but I didn't know this also affected the colours for the tutti frutti glitch.

Since tutti frutti is essentially a visualized memory overflow, whatever may affect "garbage" in memory before and while you're running Doom matters.

It's possible, though very hard to say if what lies beyond a valid patch_t's data is another chunk of data actually being used by Doom at that time, or just "available memory", but as a rule of thump, the contents of tutti frutti will depend on the "history" of a particular machine and Doom instance, just like any sufficiently complex system. Doom ain't no simple n-state machine.

To answer that you'd need real good inside knowledge of the Z_Malloc system, and knowing how/where/when it will allocate/deallocate stuff. The very least it will behave very differently in machines with just 4 MB and machines with lots of RAM: on the former stuff will be unloaded a lot more often, and the tutti frutti patterns will change accordingly. On one with more plentiful RAM stuff will be more lazily unloaded -or not at all-.

In any case, AFAIK precise Z_Malloc behavior isn't emulated under anything but DOSBOX -and then again it provides a relatively sterile DOS environment-.

Well, who knows, maybe in the future someone will use some crazy solution like a neural network to simulate Doom ;-)

12-06-10 09:53 #

Profile || Blog || PM || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

Virtually none of the overflows in the renderer are known to produce gameplay effects (none of them are in my personal knowledge, at all). Rather they generally crash the game immediately.

The only code in R_ modules called by the rest of the game engine as far as I can remember is R_PointToAngle. Changing that function will desync demos easily because it's used everywhere.

Well technically also R_PointInSubsector. But that is hardly a "rendering" function to begin with - it does BSP tree traversal to classify a point.

If the renderer had an effect on gameplay it would be impossible to use -nodraw to profile the game engine by running demos, and this is simply not the case.

12-06-10 14:28 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14809
Registered: 04-02

Porsche Monty said:
So prBoom+ shows Tutti Frutti/Medusa where there would normally be any? that's something for the prBoom+ developers to fix.

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.

So far you've mentioned purely graphical abnormalities, nothing that would stop a demo from playing back correctly in prBoom+

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.

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.

It isn't, and yeah, that's the main issue. At least it exists in some form, though. Something is better than nothing.

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

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.

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.

See the "applicability" point below.

Limitless ports are the standard for limitless maps.

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.

Xaser said:
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?

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.

fraggle said:
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.

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:

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.

12-06-10 18:41 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

fraggle
Super Moderator

Posts: 6571
Registered: 07-00

Dumping a dehacked patch is easy: simply point dehacked at the two files and save a patch. Patch is available here for download.

To play:

code:
chocolate-doom -server -deh immy.deh -file immy-dm.wad -respawn -altdeath

(You'll need to hit enter at the multiplayer wait screen to start a 1-player netgame)

It seems to play the same as the Vanilla version as far as I can tell. On a side note, although these obviously aren't the best AI bots by any means, considering that this does appear to be just a dehacked patch, I think they work impressively well.

EDIT: I recorded a demo of myself playing against the bots using the Vanilla-based modified exe, and it plays back perfectly in Chocolate Doom (you need to specify the -netdemo parameter). No comments about my lame deathmatch skills please :-)

EDIT 2: If that wasn't enough, just to be completely certain, I loaded the immy.deh I created on top of a clean doom2.exe. The resulting exe matches the patched one created by comp-dm.exe exactly.

Case closed I think.

12-06-10 19:13 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

Quasar
Moderator

Posts: 5158
Registered: 08-00

So then the only thing really needed to support this is a -solo-net mode. Which EE and prboom-plus already have :)

12-06-10 19:58 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

RjY
anARCHy

Posts: 857
Registered: 05-02

fraggle said:
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.

If I or someone else were to write it, would you accept a patch that added a compile-time option to increase vanilla rendering limits? Something like

code:
./configure --enable-visplanes=1024

Then anyone building the game, including obviously those who do SVN builds for everyone else, can easily build chocolate-doom and a "chocolate-doom-plus" just with two runs of the build process with different ./configure options, instead of having to patch the code.

I know you said you made chocolate-doom easy to fork but it's always better to get changes upstream than maintain a fork forever. That's what the kernel people always say...

12-06-10 20:50 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote

myk

Posts: 14809
Registered: 04-02

Quasar said:
So then the only thing really needed to support this is a -solo-net mode. Which EE and prboom-plus already have :)

Even vanilla has it, once you set up IPX and apply -nodes 1 with ipxsetup, as well as plain PrBoom using the server and -N 1. Other ports may be able to do it similarly.

12-06-10 21:11 #

Profile || Blog || PM || Email || Homepage || Search || Add Buddy

IP || Edit/Delete || Quote