Doom2 v1.92 - no more visplanes and drawsegs overflows

In order to use it with Scythe2, you will need to extract the dehacked lump from inside the wad and apply it to the exe. You'll also need to run deusf over the wad (deusf -app scythe2.wad).

Or have you done all that and are still getting problems? If so, on which maps?

There are also a few maps that use Boom specials, and so won't work no matter what.

xit-vono said:
It had a problem with numlumps or something.

Yeah, that means it needs the extra flats and sprites DeuSF adds.

Is it possible to edit the program to make it work with scythe2?

Assuming you have DOOM and DOOM II in different directories (because if not DOOM will interfere with the process), put deusf in your DOOM II dir and type:

deusf -app scythe2.wad

That makes the wad Doom2 compatible by adding some stuff (sprites and flats from DOOM II). Then you need to add the DeHackEd patch to a copy of Doom2+. Normally you need to extract the DEHACKED lump like Grazza said (with XWE or whatever), though here is a copy. Next get DeHackEd 3.1 if you don't have it, put it in a directory of its own, and edit its DEHACKED.INI file to say the following where applicable (there are notes below, and you should edit the paths to whatever you use):

# For DOOM II
editname = d:\doom\scythe2.exe
normalname = d:\doom\doom2p.exe

(The normalname should point to the Doom2+ file, wherever it is, and the editname is the scythe2 compatible EXE it will create from Doom2+; it will ask you if you want to create it when you start DeHackEd.)

# For DOOM II
wadname = d:\doom\doom2.wad

(Your DOOM II IWAD.)

# The directory to look for patch files in.
patchdir = d:\doom\hack

(The directory where you put scythe2.deh; it could be the DOOM II dir, if you don't care to make a folder for DEH patches.)

# Doom version #
#        0 for Doom 1 1.666
#        1 for Doom 2 1.666
#        2 for Doom 2 1.7, 1.7a
#        3 for Doom x 1.9
#        4 for Ultimate Doom 1.9
version = 3

(States that it's for DOOM II; normally this is either 3 or 4, depending on the game).

Once you've edited the INI, type:

dehacked -load scythe2.deh

It'll ask if you want to create scythe2.exe; hit the Y key, and it's done.

As Grazza said, a few maps have Boom stuff and thus need Boom or PrBoom. I think they were all mentioned in the Scythe2 demos thread. A good deal work fine with Doom2+, though.

I am a bit confused on the download section of Doom-plus. When clicking on the "Notes" next to each version, are these the complete changes for that version, or are they all accumulative? Also, I've noticed a "1.9.5" version... is this supposed to be "1.92.5"?

EarthQuake said:

I've noticed a "1.9.5" version... is this supposed to be "1.92.5"?

I believe that should read 1.92.5, yes.

EarthQuake said:

I am a bit confused on the download section of Doom-plus. When clicking on the "Notes" next to each version, are these the complete changes for that version, or are they all accumulative?

Up until 1.92.5 they were the full list of changed limits. For 1.92.5 it only mentions the change since 1.92.4. Again, I presume this is just an inconsistency/error. The full list of extended limits in 1.92.5 is as Andrey gave earlier in this thread and on the features page.

A thing about the changelog: It say it's the PrBoom+ changelog :P

This is very exciting. A few questions I hope not to disturb anyone.

-Is the link in the first post the one for the latest version of this patch?

-Do you think you could do the same for Final DOOM exe, but without modifying the teleport "bug" (that I think looks cooler than the normal teleport efect).

-Also in Final DOOM there's a problem with the demos, it ask for demo4 (I think) and when it doesn't find it crash returning to Dos, do you think you could fix this?

-Another thing, could you modify the bug with the skies when you finish an "episode" in DOOM 2/Final DOOM?

-Are v 1.9 demos compatible with this?

I don't think the purpose of this hack was to correct bugs... just expand the limits. I don't even know if it would even be possible to do it anyhow and still keep compatibility.
The latest version is 1.92.5 on the download page, and as for demos, yes most 1.9 demos are supposed to run with this.

One thing is on my mind though... I remember there being a hacked 1.91 a while back with a higher mouse resolution something or another. Does 1.92 have this?
EDIT: I guess it does. :P

EarthQuake said:

and as for demos, yes most 1.9 demos are supposed to run with this.

All.

Forget about Carmack's EXE.
You should use Doom2-Plus always now :)

entryway said:

You should use Doom2-Plus always now :)

It would be nice if we could use a UDoom-Plus :\

EarthQuake said:

I remember there being a hacked 1.91 a while back with a higher mouse resolution something or another. Does 1.92 have this?
EDIT: I guess it does. :P

No, it doesn't, as this would completely break demo compatibility (while giving it compatibility with -longtics demos, obviously). I'm not 100% certain, but I imagine the 1.91 patch could be applied to Doom2 v1.92.

Andrey: Given that you described how to make a UDoom version above, is there any chance you could include it in the next release?

Grazza said:
I'm not 100% certain, but I imagine the 1.91 patch could be applied to Doom2 v1.92.

Sure it works (I applied it and recorded stuff), and so does any DeHackEd patch for v1.9.

Are there any problems with additional floors in PWAD in DOS EXE? It seems to me, if you place all additional floors after "FF_START" label (they should be below IWAD's floors in LUMPS table) it will work correctly always.

entryway said:
Are there any problems with additional floors in PWAD in DOS EXE? It seems to me, if you place all additional floors after "FF_START" label it will work correctly always.

Yes, plus F_END at the end. You get a numlumps error with any other combination of F markers (or the lack of).

Grazza said:

No, it doesn't, as this would completely break demo compatibility (while giving it compatibility with -longtics demos, obviously). I'm not 100% certain, but I imagine the 1.91 patch could be applied to Doom2 v1.92.

Ahh, yes that makes sense now, changing the mouse would definitely break backwards compatibility. It seems they were talking about chocolate-doom when they mentioned the 1.91 hack was supported.

Add another mark to my tally for being a dumbass and not reading thoroughly.

@entryway: Do you plan to release patched versions of the Ultimate & Final Doom executables too? Those (especially the Ultimate Doom one) would be useful.

I don't know any vanilla-compatible levels for Ultimate Doom where it could be useful. In overwhelming majority of cases big levels are designed for Doom2.

Doom/2+ as it stands can be used for any PWAD for The Ultimate DOOM, loading the ultimate version's IWAD, except, of course, for anything replacing E4 levels. Demos recorded with it would be "complevel 2" compatible.

I've been using it for Mapgame, for example.

My impression is that it would be useful to have an Ultimate Doom version. I'd use it, at least.

If you play Ultimate Doom wads with Doom2 1.92, then aside from E4 levels not being accessible (and the lost soul behavior demo incompatibility of course), you could also get some unwanted effects in ExM8 levels (e.g. if there is a cyber in E1M8, etc.).

There are some wads that are UDoom+limit-removing. Drawing up a list would take some time and research, but off the top of my head, there is odam.wad and dreadful.wad. If I could get through to wip, then I could probably list some more. What about ClassEp2? The text-file doesn't suggest that it uses any Boom specials, and (again judging from the txt) Death Tormention 3 (which is on Ep4) contains some levels that don't have Boom stuff. And maybe there are ones described as needing Boom that only need it for limit-removal.

Also, there are plenty of levels that are said to work with Doom.exe but with a (slight) risk of VPOs, or that haven't been extensively tested for them. It would certainly nice to be able to play these without any such risk.

Grazza said:
What about ClassEp2?

Yep; I played this some time back with Doom and most of the maps ran on the plain thing, except the last level, that easily suffered HOMs and some VPOs due to the detailed cracks on the floor.

You might be able to change the 8MB memory but that all depends on the call to CWSDPMI, if the version of DPMI does not support that much memory then doom could fail on memory allocation.

You should be able to apply 1.92 ontop of 1.91 since 1.91 has the same file size. (Best bet would be to use 1.93). You would have to find

#VERSION 109

and change it to

#VERSION 192, wherever the definition.

The 1.91 patch only makes the recording tics longer so there is more precision in demos. It happens when you do a -net -record with someone else. Due to that the mouse sens would reset to 5 every time you strated a net game (and beleive me that 5 is too slow when your under windows - because Kahn is in windows) and I play at 63 (although i think it resets back to 61) and it stays at the sensitivity that you changed it. (If your wondering how I got 63/61, edit default.cfg).

ANother thing: Increasing sound channels for sound blaster.

I think there is an option that allows you to change the sound channels in default.cfg, but I don't know if it will stay or not. Also, mixing depends on the sound driver installed either true sound blaster or just emulation (I have SB emulation using AU30DOS.COM - Aureal Vortex AU8830 DOS Sound Blaster Pro Emulation - Actually emulating SB Pro 2.0). Doom mixes in the sound but too many channels might overflow the card and may cause errors. Also setting the music higher then 14 (or is it 15) cause s problems such as terrible music quality if you hit the right value.

I wonder if there's any way you could extend the openings limit. The openings array, in r_plane.c in the source code, is an array used for vissprite clipping and in DOOM it is way too small. Lee Killough figured out there's a static limit guaranteed high enough, and that limit is exactly the max vertical resolution times the max horizontal resolution, or in Vanilla Doom's case, 320*200*2 bytes (the array is of type short int). Maps which exceed the openings limit by having too many consecutive transparent vs non-transparent posts will overflow this array silently and cause a venetian blinds crash :)

Andrey, the venetian blinds error that occurs in s227 also happens at the start of Null Space Junior. It's the same issue, evidently, as without monsters there is no crash on Nulljnr, like in s227.

GhostlyDeath said:
I think there is an option that allows you to change the sound channels in default.cfg, but I don't know if it will stay or not.

Hmm, it does stay. Now I'm wondering whether there really is a limit or that was just something arbitrary set on the Setup application for stability purposes because of some older sound cards. I can't tell if 16 and 32 are improving sound over 8 channels, though.

(Best bet would be to use 1.93).

No point changing the version unless the demo format changes; "v1.92" is still v1.9, unless it's v1.91 (patched with the longtics hack).

Quasar said:
Maps which exceed the openings limit by having too many consecutive transparent vs non-transparent posts will overflow this array silently and cause a venetian blinds crash :)

Perhaps that is what Equinox Map13 does, which has a venetian blinds crash on loading which is not related to thing placement (it's not the glitch affecting Null Space Junior).

Quasar said:

I wonder if there's any way you could extend the openings limit. The openings array, in r_plane.c in the source code, is an array used for vissprite clipping and in DOOM it is way too small. Lee Killough figured out there's a static limit guaranteed high enough, and that limit is exactly the max vertical resolution times the max horizontal resolution, or in Vanilla Doom's case, 320*200*2 bytes (the array is of type short int).

I should increase the original limit #define MAXOPENINGS SCREENWIDTH*64 up to SCREENWIDTH*SCREENHEIGHT*2, should I?

Maps which exceed the openings limit by having too many consecutive transparent vs non-transparent posts will overflow this array silently and cause a venetian blinds crash :)

Do you have any examples of such maps?

myk said:

Perhaps that is what Equinox Map13 does, which has a venetian blinds crash on loading which is not related to thing placement (it's not the glitch affecting Null Space Junior).

I have checked up this level in prboom.exe -geom 320x200 The number of used openings does not exceed an original limit 320*64.

P.S. It's crashes in first loop in P_UpdateSpecials

P.P.S. Overflows of linespeciallist[MAXLINEANIMS] happens there (too many scroll textures). I can increase this limit in doom+. But it can lead to loss of compatibility if overflow did not lead to crash (in overwhelming majority of cases this overflow will crash Doom immediatelly)

This test version works without crash on MAP13 @ Equinox.wad
(after deutex.exe -app Equinox.wad of course)

linespeciallist[MAXLINEANIMS] : 64 => 16384 (*256)

myk said:

Andrey, the venetian blinds error that occurs in s227 also happens at the start of Null Space Junior. It's the same issue, evidently, as without monsters there is no crash on Nulljnr, like in s227.

It happens because the sizes of blockmaps on these maps is greater than 65535. You should compress BLOCKMAP lump by means of ZenNode:

ZenNode.exe -bc -r- -n- scythe2.wad MAP27
deutex.exe -app scythe2.wad

attrib.exe -R nulljnr.wad
ZenNode.exe -bc -r- -n- nulljnr.wad

entryway said:
linespeciallist[MAXLINEANIMS] : 64 => 16384 (*256)

Whoa, this fix also allows it to run the four maps in DV. Without it only Map04 worked.

It happens because the sizes of blockmaps on these maps is greater than 65535.

Indeed... at least it's an issue that can be easily spotted by opening the wad with XWE, etc.

myk said:

Whoa, this fix also allows it to run the four maps in DV. Without it only Map04 worked.

Deus Vult with DOS EXE? Is it possible now? heh

entryway said:

I should increase the original limit #define MAXOPENINGS SCREENWIDTH*64 up to SCREENWIDTH*SCREENHEIGHT*2, should I?

Do you have any examples of such maps?

Well, it would be SCREENWIDTH*SCREENHEIGHT in terms of the data type size for the array (short int). In bytes, it would be SCREENWIDTH*SCREENHEIGHT*2.

Quasar said:

Well, it would be SCREENWIDTH*SCREENHEIGHT in terms of the data type size for the array (short int). In bytes, it would be SCREENWIDTH*SCREENHEIGHT*2.

I wish to create a test level which will cause overflow of an original limit. How can I do it?