[Blade of Agony] Road to Wolfenstein Devblog Part 07 | p173

[Tormentor667]

No matter if you can whip something up or not: Thanks for taking your time and trying to find a solution engine-wise. This is very much appreciated.

[shadstarn]

did you release a weapons mod only ?
if not please do that.. so we dont have to go into the files and removing the maps
or can i just use a map command?

[ZikShadow]

If you're looking to only use the weapons/enemies, you can already check out WildWeasel's Nazis! mod, BoA's stuff was based from that.

[RockstarRaccoon]

did you release a weapons mod only ?
if not please do that.. so we dont have to go into the files and removing the maps
or can i just use a map command?

Some of this stuff was made exclusively for Blade of Agony, and they've already said that they don't want to release that stuff to the public until after Blade of Agony is complete. My suggestion, if you want to make a Mod, would be to treat this as a standalone game and make your Maps with this.

And, seeing as I've thought about that, I should probably release my GZDB configuration that I use to edit Blade of Agony stuff.

[Graf Zahl]

Some more testing with C3M3:

The one thing with the single most impact on performance in that map is the portal to the cellar staircase in the large building in the northern part of the village.
Just removing that portal increases performance by another 5 fps. I checked with two graphics cards from the point where you come out of the river:

With a Geforce 550ti I get 22 / 28 fps with/without portal.
With a Geforce 1060 I get 27 / 32 fps from the same location.

I think if you can replace this one portal with a traditional Boom sector to sector teleport somehow it'd make the map a lot more playable already. What's left after that needs to be done through engine-side adjustments, but I can outright say that the portal alone will be enough to prevent 60fps in the village, even if the engine side changes can eliminate 90% of the processing time.

Even though this portal may look simple, the devil is in the details: The entire village is constructed out of 3D floors and two-sided walls, so the portal is 'visible' from everywhere.
This means, no matter what, the engine needs to process it, resulting in a full graphics pipeline stall so that it can draw the stencil. This causes several milliseconds of GPU actions to be waited for (depending on the card I used it was either 3 or 6 milliseconds) which has a devastating effect on performance, especially on older hardware. Using portals in such richly detailed scenes with no one-sided walls in sight is a surefire way to get performance issues.

Unrelated: There's some glitchy geometry right in front of the village's main gate.

[Wiw]

Is that what causes the game to run so sluggishly? Not the models, but... portals?

[Rachael]

No - what causes it to run so sluggishly is the team's obsession for detail over playability and frame rate. Whether a system can handle it or not - they don't care. And sorry, I am going to be blunt here -

If they spent half as much time going over "gameplay do's and don't's" as they do bragging over their linedef counts, I think the mod would be a whole lot better for it in the end.

Portals don't destroy a scene. Portals + 20,000 linedefs and sprites on a single screen, do. In the end, this just is not worth it. It looks pretty, but it's not fun to play, and not just because it runs like ass on anything made before the year 2050. Oh, whoops, that's a few decades into the future!

All effort is being focused on the visual aspects of it, but literally none is being made toward the things that really matter: what the player finds fun and engaging, as well as running with at least 30 FPS on an average system that GZDoom runs on. I think the team really needs to realize that it's okay to sacrifice visual quality for the other two things. It would do something that's taken such a monumental effort, as this clearly has, some real justice, and ensure that none of that effort goes to waste.

[Graf Zahl]

This one portal is an extreme case. It's smack in the middle of the most detailed open scene of the entire map set and thus will always be added to the processing chain. But with that extremely detailed scene and the way the engine works, that means it will start to get processed several milliseconds before that scene actually finishes rendering. And a portal requires drawing a stencil, then waiting for the stencil to be drawn, before the scene inside the portal can be processed.

I tested this on two different graphics cards. And the effect was considerably worse on the older one. With a Geforce 1060 and that portal being disabled, I can actually run the map at 30 fps - but never forget that this isn't an "average" system at all. It got both a modern and fast graphics card plus a relatively fast CPU (6 year old 3.4 GHz Core i7), so it stands to reason that on "average" hardware the map will still hover around 20 fps.

@Rachael: I have to concur. I haven't been looking at the map for a longer time now - so what did I see? Yet more detail being added to the village scene that already posed performance problems. I actually measured a 20% performance drop between the last version I had from last summer and the current one. Had this not been done but the map been optimized instead, I guess it'd easily run at 40-45 fps. I can only do so much with engine optimizations. Stuff that sounds good on paper is hard to do because there's secondary concerns.

Just talking about dpJudas's static mesh tests for Frozen Time and a 300 fps performance should give some ideas:

Yes, you can render all that stuff 300 times a second on modern hardware. But you still have to
- process all walls for decals
- process all walls and sectors for dynamic lights
- check all linedefs for skies which require special treatment
... and a few other things.
So even if it can be pulled off, we may realistically be at maybe 100 fps. And that map is a lot less taxing that C3M3 of BoA because its only real problem is excessive use of crossbeam bridges. It got no portals, no lighting effects, no skybox, no scripting or other performance hogs. Just removing the crossbeam bridges and replacing them with 3D floors makes it run at over 60 fps on my home system and 40 fps on my work Mac with an integrated Intel chipset.

With BoA another point that's easily overlooked is the time the playsim needs which is then missing for the renderer. This is on the high end of high on most maps.
So village aside, one thing I'd do is to split far more maps at convenient points. Just lowering the think time may already help some of the maps quite a bit, especially on slower systems.
Speaking of splitting. That portal in this map looks like a great transition point to another map to me. It'd solve the portal problem and distribute the think time better. The other point where I'd split it is the subterranean river, which again is a single passage between sections that do not interact at all.

[RockstarRaccoon]

Good example of that, stuff like the portal near the beginning of C2M1, or the back office in INTERMAP, which shocked me when I was playtesting the game. It felt like the entire purpose of those portals was to give the map that non-euclidean geometry that you guys are always doing. Why not just put that part of the map where it goes logically and build the other part of the map around it? Hell, it might even be a cooler map if there was a door leading to a balcony overlooking that earlier area...

Seriously, this is one of my favorite games made in this engine, but every time I play a new level I find a spot where you guys have decided that you're going to have a whole Mountain Side detailed out and then you put some sort of portal overlooking it, just in case the player's computer could have handled that. With the amount of skill that goes into this project to make it as impressive as it is, I'm surprised that the mapping team has this much trouble understanding basic engine limitations.

The saddest part is, last night I downloaded and played Tormentor's Refinery, and that map was even more intricate and detailed than any of the maps in this game, with detailed areas beneath complicated catwalk bridges, and a section where you fall through a floor to go through a giant worm thing which goes beneath another floor and pops out in the yellow key room, which is surrounded by detailed hallway. All of that looked amazing, and was done without any portal abuse, just a bunch of 3D floors, which, by the way, use a relatively small amount of resources, even if they are transparent or sloped.

Like I said, great project, but you can do most of this without portals eating the frame rate.

[Graf Zahl]

Let's be clear: "The portals" do not eat the frame rate. This particular portal, due to its placement, is a big problem, though. And what for? A staircase into the cellar? Sorry, this can be done with cheaper features, even if it won't be totally seamless.

[Ozymandias81]

Recently I have improved perfomance on my crappy pc (Athlon X2 250 3ghz DualCore, 4gb ram 1333mhz ddr3 single bank, GeForce GT-610 Palit 1024, Win7 64bit with .NET Framework 4.7) for TITLEMAP, as you can see on this commit (check the imgur album on the commit).
Now I tried something with C3M3 as a test, and noticed this: https://imgur.com/a/94RSi4C - I get 4 fps without any changes at the start, 16+ with them.
While surely things could be split, removed and resized, how much important is to have portal aligned properly engine wise? Shouldn't this cause more issues?

[Graf Zahl]

The portal alignment really shouldn't matter. If it does, it is mainly a sign of a very unoptimized BSP being generated. Better alignment can certainly split the BSP at a far higher level and reduce traversal time a bit, but it shouldn't make too much of a difference. If there is there may be some hidden problem that isn't visible when playing.

All this doesn't matter in the village, though. What costs time there is the mere presence of the portal and the GPU costs of setting it up. But wait: Did you say 4 fps at the start? On my system that part manages 60fps easily. I think you are hitting some GPU bottleneck somewhere with that low end card. Your comparisons would be more useful if you could provide some engine timing stats with them to see which code makes the difference.

[Ozymandias81]

Which commands should I use then to provide those timing stats? Plain "Stat think" or something different? A benchmark too? I can also build up 2 little videos, well their performance will loss a couple of frames thanks to OBS recording but if this could help I am all for it.

[EDIT]: Gonna build a little imgur album for now, with "stat" comparisons and I'll aslo drop a benchmark here, even if it isn't exactly useful

[Graf Zahl]

A printout from the 'bench' CCMD would be great. That gives all the information what changes if you move the connected portal section.
I've also seen the suggestion about the automap to only show what's currently visible. I think that would be a great visual debugging tool for cases like this.

[Ozymandias81]

Okay did becnhmarks and also an imgur album for the purpose, but not sure what you mean with "automap currently visible", so I did the following:

3 attempts with my changes, which span from none to "trees" removal and "portal" alignment - Noticed that if I press ESC or console key then return in game, I gain a couple of fps (3-4)

Benchmarks, that has been commented to let you know which is which:

benchmarks.txt

Tested with GZDoom g3.4pre-406-g751e318c4

(3 KiB) Downloaded 18 times

These comes directly from GZDB testing sessions and not from IPK3 / PK3 playtests, also I have never moved the player (maybe only one time while typing IDDT)