ZDoom

by **Darkcrafter** » Sun Nov 06, 2022 12:45 pm

Can't even imagine how many warnings it gets with my mapset if ever introduced

by **yum13241** » Wed Nov 02, 2022 5:22 am

You could also track how many times an actor is spawned too, maybe track A_SpawnItemEx?

by **wildweasel** » Tue Nov 01, 2022 2:07 pm

That's not really what the problem is. The number defined actors isn't the source of most performance issues in mods; it's generally going to be thousands of spawned instances of one actor, like a blood droplet, a bullet spark, smoke effects from a gun, or a weather system that spawns thousands of rain drops every second. The engine has trouble keeping up with all that.

by **yum13241** » Tue Nov 01, 2022 10:46 am

And of course there's mappers for which the visual presentation is all that counts, screw performance. Here again they are doing their thing without awareness of how costly it is, but when they have to scale down they run out of ideas.

Super true with AAA game studios too. Then again there's stuff like NUTS.WAD which intentionally tries to lag your PC.

IMO if GZDoom detects there are a LOT of actors being loaded it should show a dialog box to the screen with this. (since most, if not all laggy mods have a bunch of actors):

HOLD UP! Potentially slow setup detected!
---
The mod(s) you are loading contain X actors. We cannot ensure that the game will perform well and any complaints should be directed to the mod developer(s) and not to the GZDoom developers. Please make sure that your hardware is up to the task.

[OK, I understand] [Cancel]

Again some mods might use a lot of actors that are just

ACTOR InventoryItemForReload : Inventory {}

which should be excluded from the check? Maybe check to see if it has at least 100 lines of code.

by **Graf Zahl** » Fri Jul 22, 2022 12:02 am

Matt wrote: and the fact that we're now dealing with a large proportion of the userbase for whom their formative computing experiences are opaque, locked-down mobile device UXs that are very removed from the reality of managing disk space and checking what programs are running and what's taking up RAM, and don't have any "natural instinct" for knowing when to start pruning things to maintain performance.

That's indeed the problem most of the time. I started programming on a C64 where efficiency was paramount, and to this day I can see what code may be slow. Modern programmers/scripters often lack that awareness and the result can be awful.
And of course there's mappers for which the visual presentation is all that counts, screw performance. Here again they are doing their thing without awareness of how costly it is, but when they have to scale down they run out of ideas.

by **Matt** » Thu Jul 21, 2022 8:34 pm

Rachael wrote:GZDoom only does what you tell it to do. If you tell it to spawn 500,000 actors that do absolutely useless shit and barely even add to the experience - it's going to spawn 500,000 wasteful actors that do absolutely nothing except slow the computer to a crawl. Computers can only do a limited amount of things at a time - no matter how well "optimized" GZDoom itself is - GEE, WHO KNEW? Didn't see that one coming, did you? The amount of sheer idiocy from people blaming the wrong things and playing hot potato with the optimization issues is deafening, and the buck has to stop somewhere. There's only so much you can do to optimize GZDoom before the authors of said mods have to start taking responsibility themselves for the things they're doing wrong in the engine.

I think a lot of these complaints about GZDoom's performance come from a combination of

(a) a lot of old DECORATE methods that require spawning new temporary actors
(b) the more significant overhead in initializing each actor since ZScript became a thing
(c) insufficient testing on slaughtermaps

and the fact that we're now dealing with a large proportion of the userbase for whom their formative computing experiences are opaque, locked-down mobile device UXs that are very removed from the reality of managing disk space and checking what programs are running and what's taking up RAM, and don't have any "natural instinct" for knowing when to start pruning things to maintain performance. (Some of the setups I've seen for people's autoloads, and some of the DECORATE methods I've seen get recommended because "ZScript scary", feel like the equivalent of people who would run up a month's worth of internet in a week because they're streaming all their music and storing all their photos on the cloud at the highest resolution their (completely needlessly high-res) phone cameras have to offer. Anyway, gonna stop before I go on a much worse rant.)

(Obviously I'm not innocent either, with all the slide shows in HD that have only fairly recently been addressed with substituting particle effects...)

by **Graf Zahl** » Thu Jul 21, 2022 1:45 am

I also doubt that it is this bad. One important thing about GZDoom's file system is that it keeps its resource files open. Which also means they cannot be modified while open. And AFAIK these AV checks are only being performed when the file is opened, not when some random content is read from it.

In any case, I never had AV related performance issues ever - with any of my computers - and I've been using Defender for many years.

by **Enjay** » Thu Jul 21, 2022 1:12 am

That may well be correct (as in, I don't know, but I can believe it) but there is an obvious problem there. You are suggesting that GZDoom puts up a message that essentially says "switch your malware protection off". I'm sure you can see how such a suggestion might be interpreted by some people who see it.

by **Ihavequestions** » Wed Jul 20, 2022 9:34 pm

As someone who's used all kinds of machines -- low-end, mid-range, and high-end -- with GZDoom, the best way to speed it up on any Windows system is to exclude its program folder from Windows Defender's real-time protection.

Other AV scanners might suffer from similar issues, too, but Windows Defender's behavior is especially bad as it will scan anything GZDoom reads from disk over and over again, every single time, really. It is bad already with vanilla but becomes exponentially worse with PB/BD and other demanding mods. On slower machines, it can render an otherwise well-running game unplayable.

So telling people about the AV exclusion would be a good first step. Perhaps check for a running Defender exe, and then make the user aware of those issues.

by **Marisa the Magician** » Wed Jul 20, 2022 1:29 pm

I think the best course of action to call out badly coded mods would be an analysis video or something, to be honest.

by **Rachael** » Wed Jul 20, 2022 10:51 am

The idea is more to put the PB/BD authors themselves on the spot, than to actually educate the users, themselves. And making it hard to ignore.

Here's a fun fact: Without PB my computer runs GZDoom between 300 and 500 FPS. And it's not even a good computer. So yeah, some "unoptimized piece of shit" GZDoom is.

So yeah - the idea is to embarrass the authors themselves. And making GZDoom warn about the mods, specifically, just isn't going to have the intended effect. The effect we want is for the authors to be more aggressive with optimizations on *their* end - rather than just blaming GZDoom - and if they are, then GZDoom stops embarrassing them. If the mods themselves are singled out, there is no motivation at the end for the mods to fix their problems.

You might say "2 can play at that game" - sure the authors can put messages in their mods directly about how much GZDoom sucks. But to that I say - then why are you using it? Go, move your mod to prBoom, which apparently works "so much better". I'll wait for you to come back after you realize that you can't even port the first line of code over.

GZDoom only does what you tell it to do. If you tell it to spawn 500,000 actors that do absolutely useless shit and barely even add to the experience - it's going to spawn 500,000 wasteful actors that do absolutely nothing except slow the computer to a crawl. Computers can only do a limited amount of things at a time - no matter how well "optimized" GZDoom itself is - GEE, WHO KNEW? Didn't see that one coming, did you? The amount of sheer idiocy from people blaming the wrong things and playing hot potato with the optimization issues is deafening, and the buck has to stop somewhere. There's only so much you can do to optimize GZDoom before the authors of said mods have to start taking responsibility themselves for the things they're doing wrong in the engine.

by **Redneckerz** » Wed Jul 20, 2022 9:20 am

Graf Zahl wrote:
Redneckerz wrote:and think it runs on Granny's PC from 2007. No warning message can erase what essentially is common sense.
"It's Doom, it used to work on 1993 PCs..."

So much for common sense.

That's the second response. The first is ''Why is BD lagging?''

Rachael wrote: People have no idea what is going wrong when GZDoom lags on their machine, and they tend to blame GZDoom without any proper diagnosis much less technical knowledge to even know that it's really the cause.

But how would you go at this? Does GZ actually need to ''teach'' these people by implementing a warning sign on the system level? At best it gets read and still ignored, at worst it gets ignored completely before said user will complain to Graf either way, whether it is a small message in the corner, or a full screen message.

Setting a flag that essentially checks the system's hardware and then does ''IF_BD/PB_Then_Not_Execute'' when the hardware is (roughly) not up the task for it before displaying a message saying the hardware isn't up to task would only serve the purpose that people will complain anyway (and blame Graf).

What is there to do against a user that:
- Only cares about playing Popular_Mod_XXX
- Will hoof their feet when anything prohibits that experience
- Will then go to these forums
- And blame Graf.

Every warning sign will get ignored or ''not seen''.

So instead of GZ having to tell users what to do, i am thinking two ideas:
- Have GZ check if a user is running BD/PB and warn against the requirements, making it mandatory to require to read it before continuing. If it doesn't work and they complain here, you can cancel out that they weren't warned. However this is similar to the things stated above
- When users create a thread, have the option to state ''Is this a performance issue about PB/BD? Then do this first'' of some sorts, prior to posting the thread. This likely weeds out the initial complaint as people have to do an additional step first. Its not very user-friendly though.

by **Enjay** » Wed Jul 20, 2022 6:05 am

Graf Zahl wrote:"It's Doom, it used to work on 1993 PCs..."

And yet, I assume, no one who says this would actually expect Frozen Time, or Project Brutality to run using DOOM.EXE on a 1993 486.

i.e. it's a false argument and they know it.

by **Rachael** » Wed Jul 20, 2022 5:53 am

Redneckerz wrote:and think it runs on Granny's PC from 2007. No warning message can erase what essentially is common sense.

Graf Zahl wrote: "It's Doom, it used to work on 1993 PCs..."

So much for common sense.

This is exactly what spawned this suggestion.

People have no idea what is going wrong when GZDoom lags on their machine, and they tend to blame GZDoom without any proper diagnosis much less technical knowledge to even know that it's really the cause.

But GZDoom is only doing what it is instructed to do, and no amount of "LEL graf optimize UR ENGINE U DUM!" is going to change the fact that some mods, like Project Brutality, or some maps, like Frozen Time, are designed in such a way that they give not only GZDoom problems but other source ports as well. (Have you ever tried Frozen Time in Edge? It's a party, lemme tell ya!)

At this point it's become a thing where people just blame Graf because that's what everyone else does anyway - and in the end the true cause of these problems gets ignored and swept under the rug. (I am thinking in particular with Project Brutality in this case - thankfully a lot of people are quite well aware that the bridge constructs and the linedef peaks in Frozen Time cause much of the issues there)

So yeah - something like this is needed, somehow. The problem is we can't come up with a viable solution that would actually work and wouldn't impact anything else negatively. And common sense? LOL - have you met the internet?!

by **Graf Zahl** » Wed Jul 20, 2022 5:34 am

Redneckerz wrote:and think it runs on Granny's PC from 2007. No warning message can erase what essentially is common sense.

"It's Doom, it used to work on 1993 PCs..."

So much for common sense.

ZDoom

Performance Warnings

Post a reply

Expand view Topic review: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings

Re: Performance Warnings