Newbie questions about ports

[2mg]

Hi, please bear with me I'm sorta new to modern source ports.

My questions are:

 

1.) Do any DOS vanilla DOOM I/II/Ult/Final versions support anything more than 320x200?

 

2.) Aside from doom95 port and Classic Doom port (BFG edition), are there any official (id/Bethesda) modern plug'n'play ports that support bigger render resolutions?

 

3.) Can DOOM 3 BFG exe or Classic RBDOOM 3 exe be made a standalone source ports that don't require DOOM3BFG installation (kinda like doom95 exe is a launcher/executable)? Or with copying specific files from D3BFG installation so I can uninstall it?

[Graf Zahl]

1) no

2) Not for PCs. Some later ports to other platforms may have been adjusted for the newer hardware.

3) I don't think so, as I understand it, it uses the backend code of the parent game.

 

[Alper002]

The only way you're going to get doom at a higher resolution without resorting to console versions is probably going to be community-made sourceports. PrBoom+ for example is as close to vanilla that you can get while running at resolutions other than 320x200. There's a wide world of sourceports, and they all have their pros and cons. Try them out and see which one you prefer most.

[2mg]

1 hour ago, Graf Zahl said:

1) no

2) Not for PCs. Some later ports to other platforms may have been adjusted for the newer hardware.

3) I don't think so, as I understand it, it uses the backend code of the parent game.

 

Regarding 3, I saw this post:

So I was wondering if this is the only current way to do it? I still have to test it, and to test it with Classic RBDOOM, but thought someone made a port with all these open sourced or something as a package/full port.

 

 

1 hour ago, Alper002 said:

The only way you're going to get doom at a higher resolution without resorting to console versions is probably going to be community-made sourceports. PrBoom+ for example is as close to vanilla that you can get while running at resolutions other than 320x200. There's a wide world of sourceports, and they all have their pros and cons. Try them out and see which one you prefer most.

While I do like what Doom Retro and Crispy Doom offer (vanilla with hi-rez), I was interested into official ports, since D3BFG does it perfectly out of the box. Even the hated doom95 with bitchy tinkering can work on Win7.

[Graf Zahl]

In case you haven't noticed: Even the current Steam releases are just the DOS EXEs running in DosBox. Apparently even id considered the game executable nothing more than a token effort, with all the ports floating around.

The closest you are going to get if you want pure vanilla gameplay with higher resolution is Doom Retro - and if you want full HD support, PrBoom+ on its most conservative configuration.

 

[seed]

9 minutes ago, Graf Zahl said:

The closest you are going to get if you want pure vanilla gameplay with higher resolution is Doom Retro - and if you want full HD support, PrBoom+ on its most conservative configuration.

 

Any chance you mean Crispy instead?

 

Because DR is definitely not accurate (I think this is what the OP is looking for as well, something very faithful). PrBoom+, Crispy, or Choco is as far as they can get there.

 

1 hour ago, 2mg said:

I was interested into official ports

 

Apart from various console ports, Doom95, and perhaps some other relics from the past, there's no such thing.

[MadGuy]

For BFG I already try on my own and right now I manage to make it work with the size of 175MB in which 61.5MB is Classic RBDoom with it's dll's and another 71.9MB is just the wads and that is the more "deluxe" version I can make (with the cinematic intro)

[Graf Zahl]

59 minutes ago, seed said:

 

Any chance you mean Crispy instead?

 

 

Oops. Yes, I meant Crispy, but these two are easy to mix up... ;)

 

[2mg]

1 hour ago, MadGuy said:

For BFG I already try on my own and right now I manage to make it work with the size of 175MB in which 61.5MB is Classic RBDoom with it's dll's and another 71.9MB is just the wads and that is the more "deluxe" version I can make (with the cinematic intro)

 

Mind telling me what essential files are necessary to make it a faux-standalone? I see the page I linked has some essential files, and there are some essentials in BRDOOM GitHub readme too.

 

 

1 hour ago, seed said:

 

Any chance you mean Crispy instead?

 

Because DR is definitely not accurate (I think this is what the OP is looking for as well, something very faithful). PrBoom+, Crispy, or Choco is as far as they can get there.

 

 

Apart from various console ports, Doom95, and perhaps some other relics from the past, there's no such thing.

 

So it's either doom95 ("fixed" for modern OS/run in VM+old OS), BFG Classic, or BFG (Unity) for consoles, as far as modern official goes?

 

Do Retro, Doomsday and Doom Legacy fit the "faithful enchanced" list like Crispy? Doomsday and Legacy seem a bit old, dunno what they do, and what separates Retro from Crispy?

Edited August 7, 2019 by 2mg

[MadGuy]

25 minutes ago, 2mg said:

 

Mind telling me what essential files are necessary to make it a faux-standalone? I see the page I linked has some essential files, and there are some essentials in RBDOOM GitHub readme too.

Well it ain't pretty but to put it simple you will need to extract the _common.resources and keep only a selective few of it's files.

Here is the file/ folder list you should keep from the extraction:

generated/images/generated

generated/images/guis

generated/images/lights/square...

generated/images/makeintensity

generated/images/newfonts

generated/images/textures

generated/images/ui

generated/swf

guis/cursor.gui

materials

newfonts

renderprogs

script (can be reduced but require to modify the doom_main.script)

 

also aside from the wads and classicmusic make sure to take and these:

 strings

video/loadvideo.bik (for the intro)

 

and if you want the intro video to work I suggest to take the _ordered.resources (and it's crc)

[ketmar]

2 hours ago, 2mg said:

Do Retro, Doomsday and Doom Legacy fit the "faithful enchanced" list like Crispy?

that is easy to check: see if "attract mode" demos are working, and won't desync. if there is no attract mode at all, or everything goes weird after some time, the port is not "faithful".

[seed]

7 hours ago, 2mg said:

So it's either doom95 ("fixed" for modern OS/run in VM+old OS), BFG Classic, or BFG (Unity) for consoles, as far as modern official goes?

 

Do Retro, Doomsday and Doom Legacy fit the "faithful enchanced" list like Crispy? Doomsday and Legacy seem a bit old, dunno what they do, and what separates Retro from Crispy?

 

As far as modern/recent ones go, yes.

 

As about faithfulness, an easy way to determine that could be done by checking the compatibility comparison table on this page, although it is incomplete and lacks ports such as Legacy:

 

https://doomwiki.org/wiki/Comparison_of_source_ports

 

Usually, if a port lacks demo support it is a good indication that that port is probably not accurate due to how demos work in vanilla. If it isn't, this usually means things such as enemy behavior and physics are different, but usually those aren't noticed at first by people who aren't accustomed to vanilla (and that doesn't make the games unplayable or "bad" by any means anyway, just not very faithful, and you need to know what to look for to notice the differences sometimes).

 

Doomsday falls under "Average" it seems (I've personally never used it, same for Doom Legacy), and Legacy is not listed. But according to its FAQ page, demo support was removed a while ago, so chances are its accuracy is probably no higher than "Average". Retro isn't listed but it also lacks demo support, and it comes with an "unfaithful" configuration by default (colored blood and corpses, mirrored corpses, deep water effects, new liquid flats animations, and so on). In a nutshell, Retro is Crispy but Boom-compatible and less accurate.

 

Either way, my advice would be to test a variety of ports and make up your own mind. See what you like :).

 

8 hours ago, Graf Zahl said:

Oops. Yes, I meant Crispy, but these two are easy to mix up... ;)

 

I would never be able to mix them up considering how different they are :p.

[Gez]

It's important to note that demo compatibility is extremely volatile. For example, the Heretic IWAD demos desync in vanilla Heretic. Raven made some minor changes that they didn't expect would break demos, but they did, and they didn't notice so they didn't record new demos.

 

Doom broke demo compatibility throughout its life, and very few people would argue that the gameplay in Ultimate Doom is noticeably different from the gameplay in Final Doom, or that Doom II is "not very faithful" to Doom 1.

[Graf Zahl]

1 hour ago, seed said:

Usually, if a port lacks demo support it is a good indication that that port is probably not accurate due to how demos work in vanilla.

 

Keep in mind that even fixing some seemingly ridiculous bugs in the game code will cause demos to desync, like this little gem from A_VileTarget:

 

    fog = P_SpawnMobj (actor->target->x,
               actor->target->x,
               actor->target->z, MT_FIRE);

 

I'd say a port fixing these things (and there are a few) is still faithful towards gameplay mechanics but no longer demo compatible.

 

 

1 hour ago, seed said:

Doomsday falls under "Average" it seems (I've personally never used it, same for Doom Legacy), and Legacy is not listed. But according to its FAQ page, demo support was removed a while ago, so chances are its accuracy is probably no higher than "Average". Retro isn't listed but it also lacks demo support, and it comes with an "unfaithful" configuration by default (colored blood and corpses, mirrored corpses, deep water effects, new liquid flats animations, and so on). In a nutshell, Retro is Crispy but Boom-compatible and less accurate.

 

Doomsday is a strange beast. On the one hand it went out of its way to modernize the engine internals and on the other hand it made as little changes as possible to the actual game code. The end result is an engine that neither feels traditional nor modern, my main issue with it nowadays isn't how it plays but that it eats computing resources like crazy for very little effect. Even playing MAP01 uses more than 500 MB of RAM and don't ever try to play a medium sized map - the frame rate will start to tank. It also has strong stylistic clashes between its own UI and the games themselves

 

Doom Legacy on the other hand is one of the least faithful ports around - the original makers were notorious for adding gratuitous gameplay changes without any off-switch and little regards to how these changes affect existing maps. The worst I can remember is that if you touch a harmful sector surface it will reset the damage timer and immediately do damage, making it impossible to run across such sectors quickly without getting hurt.

 

 

1 hour ago, seed said:

I would never be able to mix them up considering how different they are :p.

 

I guess it depends on how much use you have for them. They appeared around the same time and I frequently mix up which one is just Chocolate Doom with higher resolution and which one has added a few more features.

 

[seed]

3 minutes ago, Graf Zahl said:

I guess it depends on how much use you have for them. They appeared around the same time and I frequently mix up which one is just Chocolate Doom with higher resolution and which one has added a few more features.

 

Crispy is Choco with higher resolution (640x400, it can also be changed back to 320x200) and some new features :).

 

I'm not using it very often either since most stuff I play is usually Boom-compatible or ZDoom.

 

8 minutes ago, Graf Zahl said:

Doomsday is a strange beast. On the one hand it went out of its way to modernize the engine internals and on the other hand it made as little changes as possible to the actual game code. The end result is an engine that neither feels traditional nor modern, my main issue with it nowadays isn't how it plays but that it eats computing resources like crazy for very little effect. Even playing MAP01 uses more than 500 MB of RAM and don't ever try to play a medium sized map - the frame rate will start to tank. It also has strong stylistic clashes between its own UI and the games themselves

 

So it is indeed true that Doomsday is garbage in terms of performance then? That's by far the most common criticism that I usually see directed to the engine. 500MB on MAP01? Yeah, in that case it probably means that any map of a more considerable size or complexity is going to eat your machine like there's no tomorrow.

 

11 minutes ago, Graf Zahl said:

Keep in mind that even fixing some seemingly ridiculous bugs in the game code will cause demos to desync, like this little gem from A_VileTarget:

 

    fog = P_SpawnMobj (actor->target->x,
               actor->target->x,
               actor->target->z, MT_FIRE);

 

I'd say a port fixing these things (and there are a few) is still faithful towards gameplay mechanics but no longer demo compatible.

 

Is that the code for the Arch-Vile attack fire sprite? I remember seeing this on github somewhere and fixing it in a way that is demo-compatible proved to be fairly challenging. Supposedly axdoomer managed to find a way to do it recently.

 

Also I agree, fixing bugs does not make the game any less faithful in any capacity, but depending on what gets addressed, it will likely result in no longer being demo-compatible.

 

16 minutes ago, Graf Zahl said:

Doom Legacy on the other hand is one of the least faithful ports around - the original makers were notorious for adding gratuitous gameplay changes without any off-switch and little regards to how these changes affect existing maps. The worst I can remember is that if you touch a harmful sector surface it will reset the damage timer and immediately do damage, making it impossible to run across such sectors quickly without getting hurt.

 

Makes me wonder what the goal of the original team was honestly. Changing things that affect existing maps to such an extent? That was one way to make people avoid using it if most community content would simply not work correctly.

 

40 minutes ago, Gez said:

It's important to note that demo compatibility is extremely volatile. For example, the Heretic IWAD demos desync in vanilla Heretic. Raven made some minor changes that they didn't expect would break demos, but they did, and they didn't notice so they didn't record new demos.

 

Hm, "Things about Heretic you've just found out".

 

What kind of changes by the way?

[2mg]

9 hours ago, MadGuy said:

Well it ain't pretty but to put it simple you will need to extract the _common.resources and keep only a selective few of it's files.

Here is the file/ folder list you should keep from the extraction:

 

I'll cross-reference this with that other thread and see what comes out when I get the time, thanks.

 

 

 

 

1 hour ago, seed said:

Either way, my advice would be to test a variety of ports and make up your own mind. See what you like :).

 

58 minutes ago, Gez said:

Doom broke demo compatibility throughout its life, and very few people would argue that the gameplay in Ultimate Doom is noticeably different from the gameplay in Final Doom, or that Doom II is "not very faithful" to Doom 1.

 

42 minutes ago, Graf Zahl said:

I'd say a port fixing these things (and there are a few) is still faithful towards gameplay mechanics but no longer demo compatible.

 

I guess it depends on how much use you have for them. They appeared around the same time and I frequently mix up which one is just Chocolate Doom with higher resolution and which one has added a few more features.

 

Thanks, I actually came here to get informed about status of official ports (weird there are no modern ones, and I even heard recent consoles had various issues) since I'm quite a noob with ports (and there are SOOOO MANY).

 

If I want vanilla, I go with "damn I wanna play Doom today, will it work on this OS" and "I just wanna play it without harsh DOS era constraints", so any bugfixes/under the hood improvements, QoL improvements (like quicksaving or keybinds), mouse movement, and similar are more than welcome - I'm not looking a 99.9% vanilla, in fact, something quite vanilla-like, but without it being literally archaic (sry, no 320x200 for me).

 

If I want to go all out, it's obviously GZDoom with a conversion ala BrutalDoom, or BrutalDoom64.

 

So, with hardcore vanilla ports ala Choc on one side, and cutting edge stuff like GZDoom on the other, I thought "well, why just not go with what id/Beth intended?".

 

Guess something around Crispy or Classic RBDOOM fits my vanilla taste perfectly.

[Graf Zahl]

7 minutes ago, seed said:

So it is indeed true that Doomsday is garbage in terms of performance then? That's by far the most common criticism that I usually see directed to the engine. 500MB on MAP01? Yeah, in that case it probably means that any map of a more considerable size or complexity is going to eat your machine like there's no tomorrow.

 

Performance on Doomsday is really bad.

It has been a long time since I profiled various ports, but it went down to less than 10 fps on P:AR's maps at a time when GZDoom was capable of playing them with 60+ fps, and the primary focus on development since then has been on the UI, not improving the engine. And all that time is not spent rendering but is lost in its complex abstraction between the game data and its rendering engine.

The large memory footprint mainly comes from its launcher interface which consists of ultra-high-res images that apparently never get unloaded.

 

 

7 minutes ago, seed said:

Is that the code for the Arch-Vile attack fire sprite? I remember seeing this on github somewhere and fixing it in a way that is demo-compatible proved to be fairly challenging. Supposedly axdoomer managed to find a way to do it recently.

 

A demo compatible fix would mean making it optional, for affected compatibility levels. Not really a big deal, but these things tend to add up if you want to fix them.

 

 

7 minutes ago, seed said:

Makes me wonder what the goal of the original team was honestly. Changing things that affect existing maps to such an extent? That was one way to make people avoid using it if most community content would simply not work correctly.

 

AFAIK the goal was to avoid cheating in multiplayer by jumping across the damaging sector - the change ensured that each time a player lands, they get hurt. A classic case of not thinking it through. Early ZDoom also had lots of such changes which took quite a bit of time to find and undo over the years - of course sometimes only through a compatibility option because there were already maps depending on the altered behavior. Remember, these were made at a time when demo compatibility in its current form hadn't become an issue yet.

 

 

7 minutes ago, seed said:

 

Hm, "Things about Heretic you've just found out".

 

What kind of changes by the way?

 

Nobody knows. The source with which the demo was made was never released.

 

[seed]

9 minutes ago, 2mg said:

So, with hardcore vanilla ports ala Choc on one side, and cutting edge stuff like GZDoom on the other, I thought "well, why just not go with what id/Beth intended?".

 

Guess something around Crispy or Classic RBDOOM fits my vanilla taste perfectly.

 

I think you'll be happy with Crispy and PrBoom+ in this case, those should fit your requirements pretty nicely.

 

Just remember to set the right -complevel required by the WAD when using PrBoom+ .

 

11 minutes ago, Graf Zahl said:

Performance on Doomsday is really bad.

It has been a long time since I profiled various ports, but it went down to less than 10 fps on P:AR's maps at a time when GZDoom was capable of playing them with 60+ fps, and the primary focus on development since then has been on the UI, not improving the engine. And all that time is not spent rendering but is lost in its complex abstraction between the game data and its rendering engine.

The large memory footprint mainly comes from its launcher interface which consists of ultra-high-res images that apparently never get unloaded.

 

Amazing. Truly outstanding.

 

If even GZDoom which is usually also being criticized for its performance on larger/complex maps runs so much better then indeed, Doomsday sounds like quite the disaster here. Improving the UI and not the engine itself? Sure, I get it, an unintuitive interface can be a nightmare to navigate, but if so much effort was put into it instead of the engine itself... that's quite the resource mismanagement. Somehow, Doomsday also requires an even newer version of OpenGL than GZDoom does, although not by much (3.3 vs 3.2).

 

17 minutes ago, Graf Zahl said:

Early ZDoom also had lots of such changes which took quite a bit of time to find and undo over the years - of course sometimes only through a compatibility option because there were already maps depending on the altered behavior. Remember, these were made at a time when demo compatibility in its current form hadn't become an issue yet.

 

Some of which are only now finally getting addressed, like a SMM issue from a while ago. And the Mage's Frost Shards not showing up correctly, which was probably there ever since the scaling options were implemented.

 

But there are some things ZDoom changed which I never understood. What was the reason for changing the explosion physics for instance? And flying monsters jumping up if they take a rocket from beneath. There's compatibility flags for both now (one probably older than another).

[ketmar]

12 minutes ago, seed said:

Doomsday sounds like quite the disaster here. Improving the UI and not the engine itself?

afaik, the idea was to make something like an "universal engine" that can be used to create very different games. on the other hand, Doom rendering is very specific task, which fits badly into modern 3d engine architecture. so Doomsday authors tried to create some "abstraction layers" to hide at least some of those ugly things, and they end up having too many abstractions, and no other games for their engine. so they managed to get the worst from both worlds.

 

please, note that i am not an expert in Doomsday, and not a telepath, so my conslusions may be totally wrong. and i am not intending to bash Doomsday authors. they have their own goals, and seems to follow their plan.

[Gez]

44 minutes ago, seed said:

What kind of changes by the way?

The only change I know for sure is that they've deleted some unused actors, as this has affected the mobj type table and broken compatibility with the Heretic version of DeHackEd. Fraggle did a lot of work analyzing HeHackEd patches and coming up with heuristics to try to detect automatically which Heretic version they target, because that was unfortunately not stored in the HeHackEd files themselves.

 

An example of such a removed actor is the bits of wrapping. The enemies that they ended up calling golems (and "nitrogolems") in the manual are internally called mummies, so I suppose they were planned to drop bits of wrapping when you hurt them; in the same way as the chickens will drop feathers when you hurt them or the explosive pods will drop spores when you hurt them. (Use weak weapons if you want to hurt these actors without killing them instantly to test it.) You can still see the sprites in the Heretic IWAD, IIRC they're named something like SHRD.

 

There was also a change in how the firemace spots behave. As you may know, there's a certain chance of the firemace appearing on one, and only one, of the mace spots in the map. In older versions of Heretic, on all spots where a firemace didn't appear, something else was spawned (depending on episode); in the current version nothing is spawned. Obviously the presence or absence of an extra monster is going to completely mess with a demo. Now this only affects levels in which firemace spots are present, of course.

[Graf Zahl]

48 minutes ago, seed said:

If even GZDoom which is usually also being criticized for its performance on larger/complex maps runs so much better then indeed, Doomsday sounds like quite the disaster here. Improving the UI and not the engine itself? Sure, I get it, an unintuitive interface can be a nightmare to navigate, but if so much effort was put into it instead of the engine itself... that's quite the resource mismanagement. Somehow, Doomsday also requires an even newer version of OpenGL than GZDoom does, although not by much (3.3 vs 3.2).

 

TBH, those people criticizing GZDoom's performance on larger maps really do not know how the engine works. There's a hard ceiling of what kind of performance can be reached - and the larger the open areas in a map get, the more time needs to be spent. And if that gets combined with underpowered hardware and/or inadequate settings for the hardware they use, the performance will drop. For example, trying to run the engine with 4x upscaled textures is bound to be an unpleasant experience, because all that texture scaling is not free.

Another example: I can run the view from the start of the bridge in Frozen Time with 60 fps on my system (1920x1080, 4xAA, Geforce 1060), but trying to run the same scene on a current MacBook merely yields 30 fps, because the GPU is so much weaker and Apple's OpenGL overhead is a lot more severe.

 

PrBoom+ really cannot be used for comparison because the engine has no rendering effects at all and far less mapping features and therefore can run a signficantly simpler render loop that contains several shortcuts, which, when employed, would make it impossible to render effects like dynamic lights etc.

 

 

 

48 minutes ago, seed said:

But there are some things ZDoom changed which I never understood. What was the reason for changing the explosion physics for instance? And flying monsters jumping up if they take a rocket from beneath. There's compatibility flags for both now (one probably older than another).

 

Don't ask me. I can understand why the explosions were vertically limited but all the rest is just an obtuse mess of code that added a lot of volatility to the engine for basically no gain at all. It's just too bad that several mods need the altered physics with several effects built upon it, or I would have removed that piece of shit code years ago.

 

BTW, both flags were added at the same time, because the stronger one is often undesirable, it'd create havoc with 3D floors, for example.

 

[2mg]

Thanks for for chiming in!

 

To conclude my questions, I have to post an off-topic one:

How do you get SIGIL or SIGIL_compat (both without soundtrack WAD) to work Chocolate? I get them visplane errors, but Romero stated that SIGIL_compat ought to work with stricter engines?

[Graf Zahl]

Stricter engines, yes, but you need something limit removing. Sigil does not work with Vanilla limits, which are all preserved by Chocolate Doom.

 

[Gez]

SIGIL_COMPAT is about working with engines that do not support MAPINFO, so the levels are shuffled to the third episode instead of forming a fifth. The levels themselves are identical, so you need limit-removing regardless of which version you use. (Of course, all MAPINFO-compatible ports are limit-removing AFAIK.)

[seed]

20 minutes ago, Graf Zahl said:

Stricter engines, yes, but you need something limit removing. Sigil does not work with Vanilla limits, which are all preserved by Chocolate Doom.

 

Ye. Choco preserves all vanilla bugs and limitations, and Sigil is limit-removing.

 

To run Sigil, you'll need to use at least Crispy Doom, either with SIGIL.WAD or SIGIL_COMPAT. Version 5.6 should support Sigil as an Episode 5 now so there's no need to use the COMPAT version anymore, apart from speedrunning purposes. The COMPAT version was specifically designed for ports that don't support a new Episode 5 and replaces an existing level from the IWAD (Inferno in this case).

[Bauul]

Yep Sigil works with Crispy and up, it was never designed to work with Chocolate Doom (although I recall right it incorrectly claims it does on an FAQ on the Sigil website).

 

Given you're new to Doom ports, just as an FYI generally custom wads are described as having a certain level of "minimum" compatibility, meaning the simplest source port you can use for that wad.  There are always edge cases, but generally the compatibilities are:

• "Vanilla" - can run on anything, Chocolate Doom included
• "Limit-Removing" - works on everything except Chocolate Doom (Crispy is the simplest port you can use)
• "Boom" - actually covers a few quite similar types of compatibility, but generally means you can play it on everything except Chocolate and Crispy.  Most "Boom compatible" wads are tested against PRBoom+ as the 'minimum' source port required
• "[insert specific advanced port here] compatible" - finally you get wads designed for specific source ports, e.g. GZDoom, Eternity, Risen3D etc.  They tend to only work with the specific source port named as they'll use advanced features unique to that port.

 

[drfrag]

 I think the ports being closest to vanilla are Chocolate Doom and RUDE (strong limit removing based on an old version of Choco). Those contain the original game bugs. But in short for high res you'll want to use PrBoom+ or Crispy Doom.

[2mg]

3 hours ago, Graf Zahl said:

Stricter engines, yes, but you need something limit removing. Sigil does not work with Vanilla limits, which are all preserved by Chocolate Doom.

 

3 hours ago, Gez said:

SIGIL_COMPAT is about working with engines that do not support MAPINFO, so the levels are shuffled to the third episode instead of forming a fifth. The levels themselves are identical, so you need limit-removing regardless of which version you use. (Of course, all MAPINFO-compatible ports are limit-removing AFAIK.)

 

3 hours ago, seed said:

Ye. Choco preserves all vanilla bugs and limitations, and Sigil is limit-removing.

 

3 hours ago, Bauul said:

Yep Sigil works with Crispy and up, it was never designed to work with Chocolate Doom (although I recall right it incorrectly claims it does on an FAQ on the Sigil website).

 

Oddly enough, SIGIL_compat works with ClassicRBDOOM port, which doesn't work with SIGIL, yet even the official BFG port and RBDOOM ports already have some static limits removed, so I guess it's the MAPINFO which causes the issue (it replaces 3rd episode in Doom I when SIGIL_compat is loaded).

 

Anyway, thanks for all the responses.

[Diabolución]

8 minutes ago, 2mg said:

doesn't work with SIGIL

 

https://www.wad-archive.com/wad/1639f1308e8eaef1677f4aab484e2841

 

Quote

This is a patch wad for John Romero's SIGIL for Classic RBDoom 3 BFG Edition.

 

It seems you are supposed to load this PWAD.

[2mg]

25 minutes ago, Diabolución said:

 

https://www.wad-archive.com/wad/1639f1308e8eaef1677f4aab484e2841

 

 

It seems you are supposed to load this PWAD.

 

It patches EXPINFO as I understand it? Works with SIGIL.wad 1.1?