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

SIGIL on an older source port

Recommended Posts

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

Share this post


Link to post

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 by Kizoky

Share this post


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

Share this post


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

Share this post


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

 

Share this post


Link to post

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.

 

 

Share this post


Link to post

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?

Share this post


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

Share this post


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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


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

Share this post


Link to post
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 by xzotikk

Share this post


Link to post

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

 

Share this post


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

Share this post


Link to post

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

 

 

Share this post


Link to post
10 hours ago, Grizzly said:

Crispy Doom supports Sigil!

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

Share this post


Link to post

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:

Share this post


Link to post

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

Share this post


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

Share this post


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

Share this post


Link to post

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)

Share this post


Link to post

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

Share this post


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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×