Speeding up maps

I have mapped several maps, and some of them (my CTF void map in particular) causes my less than outstanding computer some slight framerate problems.

I vaguely remember when starting out WAD editing that there were various ways to speed up a somewhat slow map. One of them I thought was a REJECT lump generated by a reject map program, but I'm not sure

I also found a program that combines sidedefs (dshrink). I think that perhaps I could keep a backup copy of the WAD somewhere and dshrink my map and relsase the dshrinked version.

I have a few questions.

1. Are there other pointers for increasing the speed of a map, besides the obvious (don't have so many visplanes in view at once)
2. Does dshrink work with ZDoom (Doom in Hexen format) maps?
3. If a REJECT lump doesn't really speed up a map, what DOES it do?

Compressing the sidedefs (with that dshrink util) will only make a difference in size if you're using ZDoom -- because ZDoom decompressed those sidedefs again at loading time for some special effect.

As for the REJECT, it will speed up the map a but it'll most likely be barely noticeable on modern systems.

The only tip that I have left then is trying to manually "merge" different sectors that are exactly the same into one. That would lower the sector count and thus also the size of a REJECT lump and possibly the size of other structures like NODES and SSECTORS and SSEGS i think.

AlexMax said:

1. Are there other pointers for increasing the speed of a map, besides the obvious (don't have so many visplanes in view at once)

Aside from reducing detail: no!

2. Does dshrink work with ZDoom (Doom in Hexen format) maps?

It works but it doesn't have any effect. ZDoom always uncompresses compressed sidedefs, no matter what map format is used.

3. If a REJECT lump doesn't really speed up a map, what DOES it do?

The REJECT lump is a shortcut for sight check calculations. If you cannot see from one specific sector into another the respective bit is set in the REJECT lump so the code can exit immediately instead of calculating whether a monster in sector A can see the player in sector B. On old systems this could provide a significant increase in speed but with almost anything that exists today the effect is minimal.
A litte example:
MAP09 of Caverns of Darkness has over 600 monsters and is a really huge and complex map. Even after waking up all the monsters the sight checking never exceeded 5% of the entire calculation time, including rendering. (The average was about 2.5%.) You have to know that most of these calculations would have to take place anyway so the real gain lies probably between 1 and 3%.
That was done with Doom's original code. ZDoom uses Hexen's sight checking code which is significantly faster so the gain by a valid REJECT lump is even reduced more.
On modern computers the only use for REJECT are some special effects.

exl said:

The only tip that I have left then is trying to manually "merge" different sectors that are exactly the same into one. That would lower the sector count and thus also the size of a REJECT lump and possibly the size of other structures like NODES and SSECTORS and SSEGS i think.

I think across the entire map I only have around 10 types of unique sectors. I'll see if this has any effect, thanks.

EDIT: I just realized that I am a reing fucktard and should have posted this in the editing forum. My apologies.

AlexMax said:

I think across the entire map I only have around 10 types of unique sectors. I'll see if this has any effect, thanks.

10 sectors!!!

exl said:

The only tip that I have left then is trying to manually "merge" different sectors that are exactly the same into one. That would lower the sector count and thus also the size of a REJECT lump and possibly the size of other structures like NODES and SSECTORS and SSEGS i think.

That will decrease the size of REJECT, but not the nodes structures since those are based on lines as well as sectors.

Furthermore, as Graf said, the REJECT table is only for monster sight calcs, it has nothing whatsoever to do with rendering of the map and since this is a CTF map I highly doubt that excessive monsters is the problem.

Linguica said:

10 sectors!!!

Yeah, the contest might be been long over, but the idea is not dead yet.

I'd leave merging sectors/sidedefs to last. Because you might wish you hadn't later. Manually unmerging sectors can be a real pain, unpacking sidedefs doesn't always work (atleast with my copy of deepsea).

I have a habit of merging small identical sectors during the mapping process, and have never got into trouble by doing so. Just plan it out a bit. It also saves some editing time too since you don't have to select each and every fucking sector if you want to change the floor texture for example.

But yeah, less sectors != smaller NODES, and REJECT is almost pointless for monsterless maps (although I've heard some ports use the REJECT to marginally speed up rendering).

exl said:

I have a habit of merging small identical sectors during the mapping process, and have never got into trouble by doing so. Just plan it out a bit. It also saves some editing time too since you don't have to select each and every fucking sector if you want to change the floor texture for example.

Don't even think that merging sectors will speed up anything. All it does is marginally reducing the amount of memory being used. But even in extreme cases it's only a few hundred K of memory, nothing of value on anything that has been produced in the last 5 years.
Most resident background nonsense (like screensavers etc.) that's infesting more than 90% of the computers out there is affecting them more than the handful of saved sectors.

And don't forget that merging sectors can create sound problems of several kinds.

But yeah, less sectors != smaller NODES, and REJECT is almost pointless for monsterless maps (although I've heard some ports use the REJECT to marginally speed up rendering).

No, there aren't - at least not to my knowledge. The only port that uses precalculated visibility arrays is Vavoom and that's using subsector-based data, not sector-based like the REJECT table.