does (floor height > ceiling height) produce boom/zdoom problems/lag?

[gggmork]

If I have lots of dummy sectors with the floor set taller than the ceiling, like:

ceiling = 8
floor = 512
etc

Is that known to cause slowdown/bugs/etc in prboomplus or zdoom, if anyone knows off the top of their head?
I have that situation and am not getting any lag myself, but other people are getting perplexingly slow frame rate (for some reason, perhaps not even related to this).

[spaztacus]

Why are you setting your floors soo off? What effect are you trying to achieve. Not sure if it would cause a problem, but if the game has to account for that much memory usage, it could cause a problem.

Do you have a copy of the wad i could look at to see if it has a problem for me?

[gggmork]

Unfortunately it has a texture pack so there's 2 downloads if you want to check it out. Its kinda complex/hard to decipher, but that big triangle of stuff out to the left has sectors where floor is greater than ceiling (they're dummy sectors causing floors/ceilings to lift to the appropriate heights).

the wad (its map 30):
http://www.speedyshare.com/482275779.html

the needed texture pack for it:
http://www.speedyshare.com/690873234.html

(I drag/drop both simultaneously into prboomplus or zdoom)

Basically the problem is this map runs 100% normal speed for me as far as I can tell (in prboomplus 2.5.0.3 and zdoom 2.3.1), but it has slow framerate lag for other people (even if a lot of lines are removed apparently). The idea that lag might be due to floor > ceiling is just a wild guess, maybe wrong.

[spaztacus]

wow, interesting idea for a map 30.

It lagged for me a little bit at the begging of the map. I was running GZdoom.

My guess is that there is so much going on with all of the moving sectors, that some CPU's might have a issue. It might depend on the engine running it. I wll try it with Zdoom and see.

My suggestion is to make it how you want it and warn people that it might have lag issues. Scythe 2 had that problem on one level with a high "bridge" on a big open level.

[gggmork]

'My suggestion is to make it how you want it and warn people that it might have lag issues.'

I'd do that normally, but its part of a community megawad. I never tried gzdoom, but it runs normal frame rate for me for some reason in prboomplus/zdoom whereas other people apparently experience lag and I don't know if the floor > ceiling is any contributor to that. Guess I could tediously test/edit to find out.

[Graf Zahl]

I'm not surprised that this causes lag.

You got an insane amount of linedefs all visible. This causes an extremely large BSP which takes longer to traverse - not to mention that rendering a short linedef causes almost the same processing overhead than rendering a long one. This will be even more apparent in GL ports because the ratio of overhead to actual drawing is much larger than in software.

In other words: Your dummy sectors are not at fault - it's just a kind of map design that tends to show performance problems on weaker systems.

[gggmork]

Ok, thanks a lot, that info probably saved me a lot of work trying to edit all those dummies.

[Jodwin]

Graf Zahl said:

I'm not surprised that this causes lag.

You got an insane amount of linedefs all visible. This causes an extremely large BSP which takes longer to traverse - not to mention that rendering a short linedef causes almost the same processing overhead than rendering a long one. This will be even more apparent in GL ports because the ratio of overhead to actual drawing is much larger than in software.

In other words: Your dummy sectors are not at fault - it's just a kind of map design that tends to show performance problems on weaker systems.

Since this map is posted here too, I guess I'll ask this: The map uses a lot of "teleport to line with same tag", with "invisible" short lines. Do these teleport target lines also affect the performance? Would it matter if they were made self-referencing? Or should the teleports be simply made to work with teleport destination things?

[gggmork]

I don't think teleport things could be used anyway (right now all squares on one side are tag 316 etc. Teleport destinations would have to be in uniquely tagged sectors. However that would mean the dummy player1 would have to walk over fifty thousand lines to make all the sectors move correctly (now it just walks over a single '316' tag line).

But (probably, not sure) the unused bottom left lines in the romero head sector could be deleted (and maybe corresponding lines inside the map). Also the back sides of the big scrolling circle columns could be made a single flat non-scrolling wall (but that'd have to be careful because you might see that hacked off bit from an odd angle or something).

Also when you merged those sectors, there's now lots of redundant vertices (like bottom left dummy triangle has 2 of them, etc).

[Jodwin]

gggmork said:

I don't think teleport things could be used anyway (right now all squares on one side are tag 316 etc. Teleport destinations would have to be in uniquely tagged sectors. However that would mean the dummy player1 would have to walk over fifty thousand lines to make all the sectors move correctly (now it just walks over a single '316' tag line).

But (probably, not sure) the unused bottom left lines in the romero head sector could be deleted (and maybe corresponding lines inside the map). Also the back sides of the big scrolling circle columns could be made a single flat non-scrolling wall (but that'd have to be careful because you might see that hacked off bit from an odd angle or something).

Also when you merged those sectors, there's now lots of redundant vertices (like bottom left dummy triangle has 2 of them, etc).

Only the lines that are visible matter for the slowdowns, that is, lines included in the dummy sectors are irrelevant. But it's a good point, that using teleport things would probably complicate the conveyor belts too much...

[gggmork]

Another possibility is I usually just select all 2 sided lines and paste front upper/lower and back upper/lower textures on them all (out of laziness).
So maybe certain lines have unneeded textures set, if that would matter (but cleaning that would be tricky/tedious maybe; as soon as the stairs move it reveals needed textures that weren't initially visible).

[Graf Zahl]

If the textures are completely below the floor or above the ceiling it doesn't matter. These parts get clipped long before anything about the textures is calculated.

No, the only reason this map lags is because its design is not performance friendly - and obviously that can't be changed. You will have to live with it.