Performance Warnings

[Rachael]

An oddly constructive idea that came up with all the Discord shit posting was to have GZDoom annoy and pester the user with when a mod uses too many resources.

The program itself can run some diagnosis on the mod about why performance is failing - whether it's the scene being too complex (telling a potential mapper to cut back on linedefs) - whether the thinker times are too high (if non-actors then cut down on level geometry, or if it's with actors them cut down on actor spawns) - etc - whatever the problem may be.

This should not actually be time based but it should track how many code cycles each operation takes - but a user could set a higher threshold for faster computers.

This in particular would help with complaints about mods or maps taking up too many resources, where the blame is always shifted to GZDoom - when the blame should rest squarely on the mods themselves being run for pushing the limit with far too great resource usage that GZDoom simply can't handle on lesser systems.

Ideally the warnings should be difficult to disable as well - requiring a deep dive into the menu, or having to switch off a cvar that cannot be autoexec'd. If the warnings are annoying enough, it should cause authors to scale back on resource usage so that there are less performance complaints overall, which helps both the authors of the mods in question and the maintainers of the port.

[Graf Zahl]

I'm not sure this is going to work. The performance difference between high end and low end is too steep and most of these issues come from developing on a fast system where everything is fine and then playing on a low end system where things break down.

[Rachael]

I think to address that, this feature should work in "tiers" - where even on a fast system if you want, you can set it to the strictest setting and get warnings about what would cripple lower end systems - but by default it would work in the most generous tier where you won't get warnings except in more extreme cases.

Idea being - the mod authors in question advertise what "tier" system their mod is designed for.

[Marisa the Magician]

Thinking this through... The whole premise falls apart when it comes to measuring when something will be a problem for lower end systems. How these measurements would scale if, say, testing on a high end system FOR a low end system... That's very unclear.

I mean, can't make it just a factor of the cpu speed, for example. As I showed in a recent twitter post, a 2.56GHz intel atom is still outperformed by a latest gen ryzen with its max frequency capped to 1.4GHz.

[Graf Zahl]

Clock frequency is an utterly pointless value.

My last 4 CPUs all ran between 3.0 and 3.5 GHz and each was roughly twice as fast as the previous one.
One other thing is that graphics cards behave very differently. What runs well on a modern discrete card may still be choppy as hell on in integrated one. Even the latest offerings of Intel are mediocre at best.

[Rachael]

Thinking this through... The whole premise falls apart when it comes to measuring when something will be a problem for lower end systems. How these measurements would scale if, say, testing on a high end system FOR a low end system... That's very unclear.

I mean, can't make it just a factor of the cpu speed, for example. As I showed in a recent twitter post, a 2.56GHz intel atom is still outperformed by a latest gen ryzen with its max frequency capped to 1.4GHz.

That's why it would track the amount of code that is run - not how long it takes.

[Xeotroid]

Wouldn't tracking the code complexity be another overhead that would only result in more complaints anyway? Modders would complain they can't get rid of a forced message, user complaints – in addition to those about engine optimisation – would now also include that mod X shows irremovable (for someone who doesn't play around with CVARs) messages.
Diagnostic tools for modders to be able to inspect what parts of their mod eat the most performance are a good idea, but this just sounds like it would cause more trouble. Hell, an average "le jay-z doom slow and unoptimised" user would definitely not be convinced otherwise with an annoying pop-up message.

[Graf Zahl]

Wouldn't tracking the code complexity be another overhead that would only result in more complaints anyway?

Yes, absolutely. There is no way to measure this stuff efficiently so there's no data which then can be used to print a message.

I'd file this under well intentioned but ultimately unreasonable.

[Caligari87]

Correct me if I'm wrong but aren't there existing tools for this with profilethinkers and the various stat commands? Seems to me this could be accomplished via some automated collating of those existing tools and warning messages + some averages when the framerate drops below some target value for some length of time.

Alternatively if profiling is too complex, some way to simply emulate playing on a slower CPU and / or GPU would be helpful for modmakers who do want to try and account for lower-spec systems than they themselves have on-hand.

[Graf Zahl]

Sure this can be done - but we still face the problem that results from fast computers are meaningless for slow ones - you can't just add a universal factor to declare "this may be too slow."
You also cannot emulate playing on a slower CPU and even less on a slower GPU. You got to have it tested on the target hardware itself to see how it fares. Speed inprovements are not linear - the times of more performance by higher clock speed are over.

You also need to make makers of commercial games aware that they cannot just take GZDoom's minimum requirements and have them listed for their game - chances are that it won't work that well on hardware that's just barely good enough to play vanilla at lowered resolutions.

The main problem here is that many people are not even remotely aware how much slower a system at the bottom end of the support list really is so they never adjust for that if they want support.

[Redneckerz]

More over - Which mods/maps are expected to actually tank performance?
Judging by experience most folks tend to complain about Brutal Doom and/or Project Brutality, or maps like Frozen Time/Planisphere 2/The Given.

I'd rather suggest the opposite - Take the 2 mods that raise the most issues (PB/BD) and print a system message when you are using that on a rig that is pretty much guranteed not to run those well. Or atleast a warning.

Then again, is this really a task that GZ should do? This would only be an answer to a symptom - Namely that users are too clueless and just want to play the aforementioned mods and think it runs on Granny's PC from 2007. No warning message can erase what essentially is common sense.

So the above is just a train of thought.

[Graf Zahl]

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.

[Rachael]

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.

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?!

[Enjay]

"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.

[Redneckerz]

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?''

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.