Engine limitations and performance issues

I started making what was to be my largest Doom map a month or two ago. Only a few hours in, I discovered my map didn't run much better than Nutz.wad did.

I'm pretty certain I'm going to have to scrap this map, however, I'm curious as to what exactly is causing such an obscene frame rate drop.

It can't be the detail of the map - as the shots below will show, there's not a huge amount.

http://img25.imageshack.us/img25/7450/sundermap07early.jpg
http://img7.imageshack.us/img7/9278/sundermap07prob.jpg

The area in the second shot, being the source of the huge frame rate dip.

Especially compared to another map I made, which minus a small issue or two, runs fine.

http://img149.imageshack.us/img149/4898/sundermap053.jpg

Now, it cannot be the amount of monsters in the map, either.

So, is it just the engine having to repeat textures over lots of vast areas?

And in case the problem isn't blatantly obvious (I suspect it most likely is), here's a editor shot as well.

http://img7.imageshack.us/img7/6052/sundermap07map.jpg

However, if this map isn't a lost cause, I'd like to know. It would be fun not to have to start over :) (And find a way to work around these limitations, which I've obviously hit.)

Tested it in ZDoom, GZDoom, and PRBoom.

If I had to guess, it's the engine having to go through so many segs when rendering. Your other map's screenshot, while very large and detailed, had a lot of 1-sided lines that kept it from having to render anything directly behind them.

Dude, this mother fucker is INSANE!!!!

How long did it take to map that thing, dood?

Looks like taken from Lord of the Rings, so don't scrap them, just wait until you (or the people in general) get a better computer.

Do all your maps look epic like that?

From the looks of the map from the editor shot it does indeed look like the problem is likely to be down to the sheer number of segs generated in the BSP process.

The best advice I can offer is to try breaking up the line of sight by introducing some void into the center of the map. Failing that, you might attempt to coerce the BSP process into producing a lighter dataset by introducing new linedefs but then there are obvious disadvantages with that and some node builders might ignore your attempts anyway.

Insane_Gazebo said:

Tested it in ZDoom, GZDoom, and PRBoom.

Did you try it with glboom-plus 2.5.0.2? It should be at least 2x faster I think

And what wrong with nuts? I have 150 fps timedemo in my uv-speed demo of nuts.wad. Can play it without any problems with 2 years old Core2

Those are some amazing looking pictures.

Whilst I'm far from an expert, I have been messing around in Doom Builder making maps far simpler than these (though still requiring a limit-removing port), and have obviously placed something wrong which causes both the editor and games to lag to the point of unplayability.

My solution was to load an incremental backup, make the final additions I'd decided on previously, and all worked fine. Probably not what you wanted to hear.

esselfortium said:

If I had to guess, it's the engine having to go through so many segs when rendering. Your other map's screenshot, while very large and detailed, had a lot of 1-sided lines that kept it from having to render anything directly behind them.

That would make sense. I suppose I could put in some walls bridging off from the central tower, and get them to block off some stuff.

entryway said:

Did you try it with glboom-plus 2.5.0.2? It should be at least 2x faster I think

And what wrong with nuts? I have 150 fps timedemo in my uv-speed demo of nuts.wad. Can play it without any problems with 2 years old Core2

Yeah, just tried it out in GLBoom. Ran fine. Made me wonder why I hadn't actually tried GLBoom before. (Though, not being able to figure out where the crosshair was annoying :P)
I guess it's because I like playing stuff in software mode. (ZDoom, etc.)

DaniJ said:

From the looks of the map from the editor shot it does indeed look like the problem is likely to be down to the sheer number of segs generated in the BSP process.

The best advice I can offer is to try breaking up the line of sight by introducing some void into the center of the map. Failing that, you might attempt to coerce the BSP process into producing a lighter dataset by introducing new linedefs but then there are obvious disadvantages with that and some node builders might ignore your attempts anyway.

Sadly, I have no damn idea what you mean by any of this, hah.

TKOJ said:

Dude, this mother fucker is INSANE!!!!

How long did it take to map that thing, dood?

It took me uh, about three or four nights of mapping, I think? Maybe a little longer.

Anyhow, I posted a preview of the maps I was working on here if you wanted to see them:

doomworld.com/vb/wads-mods/46002-sunder-an-experiment-in-masochism/

There's also my old wad I had partly completed, linked there too, but I suspect the link has gone dead by now. (Just some old maps that I never finished.)

I think DaniJ is trying to say is add some one sided lines to reduce line of sight calculations.

What are your comp specs? Does it still lag in zdoom with monsters turned off?

Those screenshots look awsome.

What are those zillions of red things around the perimeter? I assume enemies; if so maybe that's it.
With that map open in doombuilder, double click doombuilder.exe again so you have 2 open. Copy lines, then copy things into a new map (so you won't risk altering the main one), maybe save the dummy test version as __dummy if necessary. Then you can do simple experiments on that to see what is causing it. Like delete half the things and see if its still slow. Or select a large portion of the more detailed sectors and click 'merge sectors' to see if the resulting seg/linedef reduction makes it faster. I have played a wad where a custom sky texture somehow made it slow (maybe too high resolution of an image or something) whenever the sky was in view, but I don't think your map has any custom textures afaik.

TimeOfDeath said:

What are your comp specs? Does it still lag in zdoom with monsters turned off?

My specs are:
Core 2 Duo E8400 @3.00ghz
Ati Radeon 4850 (1 gig of RAM)
4gig of DDR2

Not the best system out there, but still able to run some of the newest games without too much trouble.

With -nomonsters, yeah, there was some improvement, but nothing amazing. It's most certainly something to do with all that architecture in the bottom left.

gggmork said:

What are those zillions of red things around the perimeter? I assume enemies; if so maybe that's it.
With that map open in doombuilder, double click doombuilder.exe again so you have 2 open. Copy lines, then copy things into a new map (so you won't risk altering the main one), maybe save the dummy test version as __dummy if necessary. Then you can do simple experiments on that to see what is causing it. Like delete half the things and see if its still slow. Or select a large portion of the more detailed sectors and click 'merge sectors' to see if the resulting seg/linedef reduction makes it faster. I have played a wad where a custom sky texture somehow made it slow (maybe too high resolution of an image or something) whenever the sky was in view, but I don't think your map has any custom textures afaik.

Those zillions of red things is a moat of lava :P

I know that if I delete that section of the map, the frame rate jumps up. I'm pretty certain it's just the draw-distance, and the way that it manages drawing such a huge area.

I think the obvious solution, is to break up the line of sight with something, so it's not trying to draw the entire map in one go. (I've already done a *heap* of sector merging. If you see something that should share some sector properties with something else, then I've most likely merged it already.)

As for custom textures - yeah, I've used some, but they're all just standard resolution textures that either I've made, or aquired from some of the commonly used texture wad's around here.

Insane_Gazebo said:

Yeah, just tried it out in GLBoom.

I did not mean GLBoom - it is slow on levels with sectors with many linedefs. I spoke about glboom-plus 2.5.0.2 or newer

The main contributor of lag in my own experience has been # of sidedefs. I have a map with 23254 sidedefs and that one started getting slow I believe, but maybe it depends on computer speed and port used etc. I guess you're using doombuilder 2 so not sure if that displays # of sidedefs (also not sure if merging 2 sectors that are far away from eachother helps much given that that doesn't reduce sidedefs, but I don't know much technical doom stuff). Maybe just draw a long tall test wall to visually temporarily cover the detail and see if not seeing it all at once would even help. I don't know how kyka made meaculpa so damn complex and they didn't seem to lag at all. His map1 has 48452 sidedefs and didn't lag at all (zdoom though)- maybe just because its not all seen at once.

entryway said:

I did not mean GLBoom - it is slow on levels with sectors with many linedefs. I spoke about glboom-plus 2.5.0.2 or newer

Whoops. Sorry, I meant GLBoom-Plus version... 2.5.0.1. Oh. Looks like I'm out of date.

*Downloads 2.5.0.3 test*

Hah, yeah, runs even better. :) If only such performance were possible in software mode, for crazy people like myself who prefer it.

gggmork said:

The main contributor of lag in my own experience has been # of sidedefs. I have a map with 23254 sidedefs and that one started getting slow I believe, but maybe it depends on computer speed and port used etc. I guess you're using doombuilder 2 so not sure if that displays # of sidedefs (also not sure if merging 2 sectors that are far away from eachother helps much given that that doesn't reduce sidedefs, but I don't know much technical doom stuff). Maybe just draw a long tall test wall to visually temporarily cover the detail and see if not seeing it all at once would even help. I don't know how kyka made meaculpa so damn complex and they didn't seem to lag at all. His map1 has 48452 sidedefs and didn't lag at all (zdoom though)- maybe just because its not all seen at once.

What's this Meaculpa map you speak of? I have not heard of it, and cannot seem to find it in the idgames database. I'd like to have a look!

Insane_Gazebo said:

Whoops. Sorry, I meant GLBoom-Plus version... 2.5.0.1. Oh. Looks like I'm out of date.

*Downloads 2.5.0.3 test*

2.5.0.2 release is faster than 2.5.0.3.test (~30%), because it is release, so if you want speed, you have to use 2.5.0.2 release, but 2.5.0.3.test has awesome fog based sector light mode :)

entryway said:

2.5.0.2 release is faster than 2.5.0.3.test (~30%), because it is release, so if you want speed, you have to use 2.5.0.2 release, but 2.5.0.3.test has awesome fog based sector light mode :)

Yeah, I tried out the fog based stuff on the map - looked interesting, I must say :)

In terms of speed, I just put on 2.5.0.2 as you suggested, but the difference in performance didn't seem all that big. (Both ran the map fine.)
I tried running the map in 32bit/16bith mode etc, to see what would happen, and it doesn't look like GLBoom-Plus likes drawing such long distances - as the main outside walls, had some rather interesting problems. (Though fine in GL mode.)

http://img39.imageshack.us/img39/6506/sundermap07glboomplus.jpg

meaculpa thread:
http://www.doomworld.com/vb/wads-mods/45306-4-level-zdoom-mapset-beta/
wad:
http://www.sendspace.com/file/8xkkn6
(thread's host/link expired)

Insane_Gazebo said:

I tried running the map in 32bit/16bith mode etc, to see what would happen, and it doesn't look like GLBoom-Plus likes drawing such long distances - as the main outside walls, had some rather interesting problems. (Though fine in GL mode.)

Yeah, software rendering is outdated and still has some of vanilla bugs, but probably you can 'fix' that 'problem' with long lines (unprecise) by means of putting vertexes on them after each 256 units or something