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

Doom2 v1.92 - no more visplanes and drawsegs overflows

Recommended Posts

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.

limit                         : old    * k   = new
-------------------------------------------------------
visplanes[MAXVISPLANES]       : 128    * 8   = 1024
drawsegs[MAXDRAWSEGS]         : 256    * 8   = 2048
SAVEGAMESIZE                  : 180224 * 16  = 2883584
activeplats[MAXPLATS]         : 30     * 256 = 7680
vissprites[MAXVISSPRITE]      : 128    * 8   = 1024
linespeciallist[MAXLINEANIMS] : 64     * 256 = 16384
openings[MAXOPENINGS]         : 16384  * 4   = 65536
The patched EXEs with crk files can be found here. Is it interesting for you?

Share this post


Link to post

Cool! Would it be possible to make it into an installable patch instead of a full executable, like the 1.91?

Share this post


Link to post

Certainly very interesting!

Can dehacked patches be applied to this as normal?

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

Share this post


Link to post

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

Share this post


Link to post
Grazza said:

Can dehacked patches be applied to this as normal?

I think "yes", but I tested it only with my levels and had no problems

Share this post


Link to post

This would be a nice optional extra to Chocolate Doom, but I get the feeling it won't be added.
I can hope :p

Share this post


Link to post

Psycho Siggi said:
This would be a nice optional extra to Chocolate Doom, but I get the feeling it won't be added.

Well, it already supports the "1.91" hack. Though it would be cool (and more handy) if this (1.92) hack were released as a patch, with perhaps an extension of the "save game buffer" as well.

Share this post


Link to post
myk said:

Cool! Would it be possible to make it into an installable patch instead of a full executable, like the 1.91?

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

Share this post


Link to post

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

Share this post


Link to post
myk said:

Well, it already supports the "1.91" hack. Though it would be cool (and more handy) if this (1.92) hack were released as a patch, with perhaps an extension of the "save game buffer" as well.


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.

Share this post


Link to post

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

Share this post


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

Share this post


Link to post

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?

Share this post


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

Share this post


Link to post

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

Scythe Map26; free the Revenants and run around in the lower section, you'll see some of the monsters in the upper section disappear intermittently. And Nuts, heh.

Another limit that might be hackable is the one on the number of active plats (platforms); this one can affect TNT's Map22 (the text file for this demo comments about it.)

Share this post


Link to post

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

Budko > with a doom2.exe hacked by vv, niv was working on a directsound driver for WinXP ... I wonder if you could do this too.

Share this post


Link to post

Leet hax0ring in other words :) Why in the world did it take so long for somebody to think of doing this? To think of all the time we suffered under ridiculously low static limits :P

Share this post


Link to post

Yeah, imagine what impact this would have had if someone had done it in 1995...

Share this post


Link to post

To think of all the time we suffered under ridiculously low static limits :P

To think of all the time we wasted on source ports /joke

Share this post


Link to post

yeah it's too bad we can't take that exe hack back in time 10 years.

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?

A lot of rhetorical questions there, sorry about that.

Share this post


Link to post
DeumReaper said:

So theoretically vanilla maps using this patched .exe can run more detailed maps and more monsters without problems?

Yes, a lot of maps (but by no means all - some will fall foul of other limits and/or Doom2.exe bugs) that previously required "a limit-removing port" should work with this.

Note that you will still need to use deusf.exe (deusf -app wadname.wad) with wads that include sprite or flat replacements. And load any deh patches using dehacked.exe, etc.

Share this post


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

Share this post


Link to post

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.

Share this post


Link to post

Doom City was cut apart and shrunk due to Doom2.exe limitations. Lord knows what awesome things that map looked like before being gutted.

Share this post


Link to post

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.

Share this post


Link to post

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.

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
×