Hi. I have increased some limits in original EXE's to reduce the risk of crashes, premature program exits and certain visual problems. This is done without loss of compatibility - in other respects, Doom(2)-plus behaves exactly like the original DOS EXEs. Dehacked patches can be applied as normal, for instance, and any demo that plays back correctly with Doom(2).exe will also play back with Doom(2)-plus.

Grazza said:
It chokes on Equinox map13, but maybe that's not too surprising.

It likely exceeds the expanded limits, though there can be other reasons why a wad may have problems; I played through SargeBaldy's Warehouse of Evil! but had to edit the name of the start marker for the new flat (or it would crash with a numlumps error.)

entryway said:
I will have made it after increase of the game-saving buffer

Awesome! Another thing you could increase is the number of things viewable at a time (where things disappear if there are many... a limit which is visible in Hell Revealed and other wads with many enemies.)

Jon said:
The 1.91 hack fixes a bug, whereas this 1.92 pushes one arbitrary limit up to the next, and is really more of a feature.

Maybe, but DeHackEd, DeuTex, and Novert also provide "features" that aren't immediately available to a user of the DOS engine, and these are supported by Chocolate Doom, which also supports two raised limits (save game buffer and screen resolution.)

myk said:
Awesome! Another thing you could increase is the number of things viewable at a time (where things disappear if there are many... a limit which is visible in Hell Revealed and other wads with many enemies.)

I never knew about this limit. (#define MAXVISSPRITES 128) It is easy for fixing. Only five minutes. At which map I can see it?

I think the third map in the Doom1 version of The Artifact is good for this. At least the text file talks about disappearing sprites. Although it mentions the invisible platforms there are so many sprites visible that it is more likely this limit.

BTW, how do you change these things? They are fixed size arrays in the source so it can't just be changing a few values, can it?

Graf Zahl said:
BTW, how do you change these things? They are fixed size arrays in the source so it can't just be changing a few values, can it?

These variables (visplanes and drawsegs) are not initialized and consequently are in the virtual segment (.BSS). I provided additional memory space by increasing virtual size of .bss segment, then patched all offsets referencing visplanes and drawsegs to point to this new space and corrected executable fixup table

I know where you're coming from but I'm glad it wasn't available back then. I could cite dozens of reasons why but for one:

Hypotheticaly, do you think there would have been the same fever around the DOOM source release if most of the hard coded limits had already been expanded to a point that was unreachable in maps of that era due to hardware limitations?

I sumise that the community's response would have been a lot slower and would have lacked direction initially. Would people like Lee K have even gotten involved in the DOOM community if it weren't for the fact the visplane limit existed, was so easy to reach and presented the kind of techinal problem us geeks dream of solving?

DaniJ said:
I know where you're coming from but I'm glad it wasn't available back then. I could cite dozens of reasons why but for one:

If I went back to 1996 with a floppy disk and told my younger, dumber self, "hey Andy, I have here a hacked version of Doom 2 that lets you play levels with way higher visplanes, but watch out because it might make people not care so much when the source is released", I think my 1996 self would have grabbed that shit out of my hand.

If I went back to 1996 with a floppy disk and told my younger, dumber self, "hey Andy, I have here a hacked version of Doom 2 that lets you play levels with way higher visplanes, but watch out because it might make people not care so much when the source is released", I think my 1996 self would have grabbed that shit out of my hand.

I'd hope your 1996 self would do the Right Thing and NOT release it on the net. Elsewise creating a paradox as entryway would have had no need to have created it in the present.

DaniJ said:
Hypotheticaly, do you think there would have been the same fever around the DOOM source release if most of the hard coded limits had already been expanded to a point that was unreachable in maps of that era due to hardware limitations?

It's likely necessary to have the source to do something like this (though Andrey can answer that more precisely.) Also, hacking at DOOM in many ways didn't stop people's interest in the source; there obviously are many things you can't hack into the engine or a wad, that perhaps would have been dealt with even faster and with more dedication had static limits been extended early on; extensions for super-huge maps happened recently, and maybe would have happened some time back had the limits been rasied earlier, given the push of level designers wanting something more to work with.

Because of things like DeHackEd and related investigation and experimentation (DOOM FAQ, specs, etc.) and sharing of information, the "DOOM community" was knowlegable about DOOM; without a community with such interest and knowledge, the source would have probably gone largely unnoticed.

vv did hack doom2.exe as well. He extended the heapsize up to 32 megs instead of the regular 8 megs... allowing bigger levels to be loaded and much higher -maxdemo

That was a bit easier compared to this though. It requires just changing 2 values in the code, one at 0x5CCA6 (check for heap cap) and another at 0x5CCAD (enforce heap cap). I was once asked to do this one too, but I thought it would be too difficult/boring to start searching for and updating each goddamn memory reference. I guess you (entryway) instead opted to just move visplanes and drawsegs to the end of BSS and left some unused space to where they originally were? Me being my dumbass self never thought about doing it this way. :-(

It's likely necessary to have the source to do something like this

It's not absolutely necessary, but at least for myself it does make it quite a bit easier to make some sense out of the disassembler's output.