GZDoom 4.13.0 Released

[merlin86]

...snip...
I won't comment anymore on the matter.

I would say just bait...

[Professor Hastig]

Bait is putting it mildly. The whole thing looks like an ill-informed but deliberate attack, considering how little information got initially provided, both here and on Youtube.

[Rachael]

I see it as nothing more than an expression of the technical debt that is being racked up over the years and that is a perfectly valid complaint but it's not one that we really can do much about because this is actually quite normal for any project over time.

The biggest context that is missing though is the fact that he ran all of these on the same computer - not computers that were the "better available" of their time. So that skews the results a lot. So what you're missing is the fact that these versions he pointed out did in fact run kind of poorly even on the lower-end available computers of their time and the mapsets/mods that people commonly played for them. (And decently on the better computers of their time, but not the frame rates he's showing)

There is no solution for this. This is the price of progress. It's also precisely the reason why lately we've been discouraging actor additions in PR's because a single actor is already pretty bloated as it is in the current version.

Another context that is missing from the video is that this happens to all projects. Google Chrome got slower and more bloated over time. Firefox got slower and more bloated over time. Windows got slower and more bloated over time. Many game engines that survived for decades (including Unreal) got slower and more bloated over time. Treating this as if it's something unique to GZDoom is misleading. GZDoom just offers the old versions in the archive and they are still functional, that is probably really one of the biggest differences between that and many other projects.

The original Unreal game ran like absolute shit on the computer I had when I first got it. I didn't get a smooth gameplay until I upgraded my PC. But nowadays if I don't use custom drivers for the game I would have to use an actual framerate limiter in order to play it. Does that mean Unreal was bad in 1998 but is better now? Or is it just the same game and the system running it got better over time?

[Professor Hastig]

That's not really the issue. GZDoom hasn't gotten slower since 2.2. All that changed was how average fps get reported.

This map even runs just as badly on the most powerful PC at my workplace. CPU speed alone does not help with 40000 monsters where it all gets bogged down in cache misses.
2.2 does not run much better, it is choppy as hell. For one 15 ms frame I get several 1 ms frames when disabling vsync, which pushes up the average frame rate quite a bit without doing anything to make it run smooth. When disabling dpJudas's frame rate compensator there is not really much of a difference between 2.2 and 4.13 in terms of how they perform. Of course in 4.x the overhead is larger because of ZScript but not nearly enough to make the game feel better in the old version.

[Rowsol]

I see it as nothing more than an expression of the technical debt that is being racked up over the years and that is a perfectly valid complaint

One person here that has a brain.

I've been here 11 years. I noticed that the program has lost 92% of it's performance in 10 years. Apparently that makes me a troll. Okie doke.

[Professor Hastig]

Don't exaggerate. There was no performance loss at all. Just read up on what several people found out about how more modern versions try to even out the duration of a tic. Those 40000 monsters take their toll just as much on older versions. It's just the frame rate display in older versions that gives you bad information because the frames are of such uneven duration.

[dpJudas]

I can understand why someone might not realize the performance is about the same when the FPS number is very different. Frames per second, frame pacing and input latency is a problem that seem simple at a distance. Most people think higher fps = always better. Very few understand what the 1% percentile FPS numbers mean.

However nobody sane would actually prefer the 10 times 1 ms frames followed by a 16 ms frame that 2.x produces. If anything, you could actually make the argument the frame pacing compensation code could need some more work as it was still fluctuating a bit with the numbers Graf gave. If it took the playsim 15 ms to tick ideally all frames should then run at 15 ms as that gives the best user experience. If the FPS number was invisible, everyone would say 4.x ran that test better.

[Boondorl]

Using a map with 40k thinking enemies as any kind of benchmark is, in fact, trolling, especially when that map was explicitly made to run on vanilla-targeted source ports, and especially when you double down on it after having the inaccurate FPS counter called out. You even commented on how sluggish it felt but then chalked it up to NashMove being missing lol. I'm sure there's undeniably been some kind of performance loss as GZDoom shifts further and further away from Doom's vanilla code (something designed to run on a CPU from 1993), and there's still plenty of optimizations to be made on the backend, but this is a comical comparison. A map made for GZDoom that has even 200k enemies could also run fine since unlike old school Doom mapping, you can dynamically spawn in enemies as the map goes on.

[Deybar_TECH]

Thankfully dileepvr provides a short description of the process to set it up. There's also a detailed wiki article.

wow thanks.
I'll give it a try in the future.

[Graf Zahl]

A map made for GZDoom that has even 200k enemies could also run fine since unlike old school Doom mapping, you can dynamically spawn in enemies as the map goes on.

But then you have to remove the corpses. What costs time here is not the AI, but merely running the thinker loop over > 40000 actors. Even though each one only needs ~0.1 microseconds, this will inevitably add up.

[Blzut3]

Probably worth mentioning here that there are lot of resources explaining frame pacing from back when SLI and Crossfire were a thing. Multi-GPU was really good at increasing frame rates without actually making things smoother. The reason why became obvious when looking at frame time graphs. As dpJudas mentioned this is why 1% and 0.1% lows became common in benchmark reporting.

I feel like I should also mention that GZDoom has -timedemo like every other port. Would need a demo recorded for each version, but given the case in question is standing still not a huge deal. Performance of ticked frames only can be explored that way. Still doesn't paint the whole picture.

[Nems]

especially when that map was explicitly made to run on vanilla-targeted source ports

This is probably getting into source port philosophy but even vanilla wasn't meant to have that number of sprites and/or that much level detail to begin with. Sure, source ports have eased up on some of those limits but the limits of the engine are still there and I imagine they persist to this day, regardless of the port in question. Nuts was a jokewad when it came to stuffing that many sprites. I don't think it was ever intended to be a mapping standard.

I've learned to accept that there's just some things that shouldn't be played in GZDoom and that's okay. If I want to play something that's got 40k+ monsters and/or has a lot of detail that'll bog GZDoom down, there's other ports that can play it (mostly) okay. I'll use those. Heck, most of the readme files I've come across will even point out if you should even be playing it with GZDoom. If something doesn't have GZDoom listed, I can either use one of the ports listed or simply not play it.

Mind you, this is all coming from a player's perspective, someone who has very little modding and no mapping or coding experience.

[Cherno]

Thankfully dileepvr provides a short description of the process to set it up. There's also a detailed wiki article.

wow thanks.
I'll give it a try in the future.

After I noticed and reported that both CameraFOV and the ViewPos offset affect the orthographic size, dileepvr made a PR that is supposed to only make CameraFOV affect orthographic size.

[Major Cooke]

Splitting the map into smaller pieces with fewer monsters per piece should help.

Depends on context. I had a map that was split into more pieces but wound up combining them instead of relying on CPU culling, and it made the map faster for me. The fewer the sectors, the better the performance.

But again, it could depend on the map type. The one I was working on was an all-outdoor nature lake and it had a bunch of manual splits in various places.

[SyntherAugustus]

I don't know what black magic you folks may have done, but certain Eviternity 2 maps (MAP32, MAP36) run much better now.

AMD 7900x3d + RTX 3080

edit: Maps with large draw distances and sections with very busy sprite usage perform so much better now.