SIGIL on an older source port

[nname]

So I was wondering if I could run SIGIL on an older source port, maybe something like ZDoom 2.8.1 or (DOS) Boom? Do you think that it'll be possible without running into any issues such as non-working switches etc.?

[Kizoky]

SIGIL is compatible with Vanilla Doom, so it should work with any old source ports out there in the wild

edit: oops sorry, it needs a limit removing source port

Edited February 10, 2020 by Kizoky

[JBerg]

3 minutes ago, Kizoky said:

SIGIL is compatible with Vanilla Doom, so it should work with any old source ports out there in the wild

 

It requires a limit removing source port or that version of the vanilla .exe that removes limits

[Kizoky]

2 minutes ago, JBerg said:

 

It requires a limit removing source port or that version of the vanilla .exe that removes limits

oops, didn't knew that!

[Allard]

40 minutes ago, xzotikk said:

So I was wondering if I could run SIGIL on an older source port, maybe something like ZDoom 2.8.1 or (DOS) Boom? Do you think that it'll be possible without running into any issues such as non-working switches etc.?

 

[Diabolución]

Short answer: Yes.

 

Long answer: Yes, any limit-removing engine which can load BEX patches and fixes the Medusa effects and the tutti-frutti artifacts is fine. For Boom you should use the compat version and load manually its DEHACKED patch (use Slade3 to extract it) via the -deh parameter. And use a text editor to replace all instances of "par 5" with "par 3". Also, I think you should set original_doom_compatibility as 1 (in the boom.cfg file), because being able to push monsters off of ledges is annoying.

 

 

[nname]

So it should work fine with the OG ZDoom 2.8.1? I mean ZDoom (2.8.1) removes all the limits to be able to run SIGIL, am I right?

[JBerg]

1 minute ago, xzotikk said:

So it should work fine with the OG ZDoom 2.8.1?

yes ZDoom 2.8.1 and even DOS Boom 

[Diabolución]

ZDoom 2.8.1 should support just 100% fine the non-compat version, and the MP3 soundtrack.

[Bauul]

9 minutes ago, xzotikk said:

So it should work fine with the OG ZDoom 2.8.1? I mean ZDoom (2.8.1) removes all the limits to be able to run SIGIL, am I right?

 

Yep. On the scale of "has the bare minimum required features" to "is years more developed and powerful" ZDoom 2.8.1 is firmly in the latter category. 

 

ZDoom 2.8.1 came out in 2016. In the context of the 26 year old game, that doesn't at-all count as an "old" source port.

[nname]

Lovely! Thanks for all the help!

[Pablo_Doom_Guy]

yes , if you are going to play under ms dos i suggest using MBF 2.04 snm 10 by sakitoshi https://github.com/Sakitoshi/mbf_sigil/releases/tag/v2.04-snm10 . Latest unoficial update of MBF for ms dos/dosbox 

[Marcaek]

Consider using Doom2+ if you want to play pure oldschool without mapping limits.

[nname]

Oh yeah, one more thing. I reffered to ZDoom 2.8.1 as 'the OG ZDoom 2.8.1', I hope your realize that I meant ZDoom, not GZDoom. Just want to make things clear

[pcorf]

SIGIL should have no problems running under Boom v 2.02 as long as you use the version that replaces Episode 3.

 

I play using Zdoom 2.8.1 pretty much all the time.

[VGA]

On 2/10/2020 at 9:29 PM, Allard said:

 

Someone in the comments there mentioned Boom 2.04 has problems in a later map, so I don't think it can be considered compatible.

[nname]

On 2/14/2020 at 12:16 AM, VGA said:

Someone in the comments there mentioned Boom 2.04 has problems in a later map, so I don't think it can be considered compatible.

Good to know.

 

Edit: How about MBF?

 

Edit: Oh, I guess it'd work after reading the comments

Edited February 15, 2020 by xzotikk

[Diabolución]

Most likely that commenter did not load manually the DEHACKED patch. Then, of course, killing the spiderdemon will end prematurely the map.

 

[nname]

Just now, Diabolución said:

Most likely that commenter did not load manually the DEHACKED patch. Then, of course, killing the spiderdemon will end prematurely the map.

 

Huh? So it is possible to get over that error?

[Diabolución]

Quoting myself:

 

On 2/10/2020 at 8:30 PM, Diabolución said:

For Boom you should use the compat version and load manually its DEHACKED patch (use Slade3 to extract it) via the -deh parameter. And use a text editor to replace all instances of "par 5" with "par 3".

 

Relevant lines (of the patch):

[CODEPTR]
FRAME 631 = NULL

 

 

[Grizzly]

Crispy Doom supports Sigil!

[nname]

10 hours ago, Grizzly said:

Crispy Doom supports Sigil!

Great! I like Crispy Doom, so that's a good option.

[Redneckerz]

As i was researching EXE hacks for future use, i came across SIGEXE by XTTL. Its a hacked executable based off of Entryway's Ultimate Doom Plus hacked executable that raises several limits in vanilla without changing the fundamental behavior. XTTL used this as a base for his hack to SIGIL. It thus runs on Vanilla instead of being limit-removing.

 

Warning: This needs to run in pure DOS. It can run in DOSBOX, but it is beyond slow. You have been warned!

 

Info:

• Release post with a few extra details
• List of features
• More information on how this was achieved

[VGA]

Nice! But the hacked vanilla exe is also hacked to remove (extend) limits. So Sigil isn't what we call vanilla compatible.

[Redneckerz]

1 hour ago, VGA said:

Nice! But the hacked vanilla exe is also hacked to remove (extend) limits. So Sigil isn't what we call vanilla compatible.

It is vanilla compatible: it does not change the fundamental vanilla behavior. Thats why this hacked exe exists. 

 

This is stated as such by XTTL himself. By that virtue, Doom-Plus is not vanilla compatible either.

[Edward850]

28 minutes ago, Redneckerz said:

It is vanilla compatible

limit removing would be the better definition. Vanilla requires the v1.9 limits.

[Redneckerz]

4 minutes ago, Edward850 said:

limit removing would be the better definition. Vanilla requires the v1.9 limits.

Thats the tricky bit - its not exactly the same as say, Boom which actually removes limits and introduces new things.

 

The Plus exe hacks raise limits instead of removing them.

 

Either way, im just repeating what has been stated back then. If that's faulty, blame the authors. :P

[Juza]

Fun fact, most Sigil levels could easily be made vanilla-compatible with the removal / lessening of minor detailing, since its gameplay areas are quite light, because none of them have an abundant use of multiple brightness levels nor heavy height variety. (I did test it myself with an Editor for curiosity a long time ago)

[Diabolución]

Sigil is, yes or yes, limit-removing. The best definition of limit-removing I have found so far is this one:

 

Quote

Levels for Phase 1 and Phase 2 must be compatible with any limit removing engine. This means that you may exceed the limits of the original Doom, but do not depend on any additional mapping features.

 

https://github.com/freedoom/freedoom/blob/827153a16f4af7ac291be81a7204cfb06eca38ad/README.adoc#levels

[Gez]

9 hours ago, Redneckerz said:

It is vanilla compatible: it does not change the fundamental vanilla behavior. Thats why this hacked exe exists. 

 

This is stated as such by XTTL himself. By that virtue, Doom-Plus is not vanilla compatible either.

I feel like the whole thing is a logical dead-end: if you hack vanilla to change its fundamental behavior (example of fundamental behavior: crashing with a visplane overflow when there are more than 128 visplanes), then it's not vanilla.

 

Some people seem to believe that as long as you take the vanilla executable, and then change it, it's still vanilla. But no! I could make an xdelta patch between vanilla doom2.exe v1.9 and the latest gzdoom.exe, and then distribute this patch -- this would take your vanilla exe to turn it into GZDoom, so GZDoom is vanilla now, right?

 

It's like the whole DEHACKED thing. Most people around here see dehacked as a vanilla feature, so mods that rely on dehacked to change actor behavior will still be seen as vanilla-compatible. But actually, vanilla Doom doesn't support dehacked, it's the other way around: Dehacked that supports vanilla doom.exe. That's why dehacked stuff don't work in official ports, be they old like Doom95 or new like the recent Unity-shelled ports.

 

Then there's the question of "vanilla-compatible". What does this actually mean? If you apply it to maps, that's easy enough: a map is vanilla-compatible if it runs on vanilla Doom. But if you're applying it to engines, like Doom-Plus? I don't see how to makes sense of the proposal. By definition, you will not run Doom-Plus on vanilla Doom, but you also won't run vanilla Doom on vanilla Doom: doom -file doom.exe will not give you anything useful.

 

Personally, I'd say a vanilla-compatible engine is an engine that is compatible with the vanilla Doom IWADs. That includes Final Doom because I'm generous this way. This way, an engine is vanilla-compatible if it's compatible with the vanilla game data; and game data is vanilla-compatible if it's compatible with the vanilla engine.