Denuvo itself, if correctly implemented, has minimal impact. The thing is most games call it too often or wrongly implements it, which slow things down considerably.

That may be the case, but doesn't change the fact, that games run better without Denuvo. It also doesn't change the fact that the activation limit is stupid as hell when you are using Linux and every Proton change counts as a new activation. As far as I know Denuvo also hinders the development of native Linux builds of games. And if you see video games as art, Denuvo actively stands in the way of preservation. Obviously it is anti-consumer as you can't do backups, need constant internet convection, if any part of the chain breaks you are screwed out of your game, it hinders mod developers and so on.

Its only positive, is that the denuvo license is non-perpetual. This is what has led to the trend of it getting removed after a while, because if the publisher wants to keep using it, they have to keep paying. They aren't removing it because people hate it, they're removing it because once launch year has passed, and the crack is out, there's little reason for the publisher to keep paying denuvo for the license. Much better than it being on there forever on every game that ever launched with it.

Okay, but if lots of games are doing it wrong, it's still Denuvo's fault.

It's the developers' fault, but it's caused by Denuvo, if that's what you meant.

I don't need to be convinced. I'm all for DRM-free games and have been using GOG for quite some time. Fuck Denuvo, all my homies hate DRMs; but still, let's not misinform because of our opinions, that would be falling low.

Yea, they often want to secure the first month-year of sales as it's most of the sales anyway. Sometimes there's some user pressure but that's really rare.

If very many developers integrating Denuvo are making errors with it, it's because of Denuvo. Their documentation is insufficient or their interface is poorly designed or something. Or maybe their code really is just shit. Most likely some combination of factors. Regardless, I'm not letting them off the hook; this is still their fault as much as it is that of the companies choosing to use it.

No, I mean that if lots of developers are using Denuvo wrong, it's Denuvo's fault for being too difficult to use correctly or not providing enough support to developers. Even if it's the developers using it wrong, if lots of developers are doing that then it's a fault with Denuvo.

Somehow the same logic is not applied when people talk about Linux. It's always the developers fault if something doesn't work on it, such as multiplayer games, standard engineering softwares, or even computer accessories.

Could be the case I guess. I'd still blame the developers, I would imagine Denuvo has some type of support & docs to help prevent these issues, as in the end it hurts their business.

But it is. There's nothing Linux devs can do if game/anticheat devs block Linux.

Because those developers are not actually trying to get it to work in Linux, they are trying to get it to work in Windows. Game developers that are licensing denuvo probably are trying to get their game with denuvo. Linux intended software does not have the performance issues denuvo has.

So you admit games simply run better without it.

"It's not that it adds overhead on top, it's just that it adds to the top some head over.

Yes, but not by much if applied correctly

You must not get my point. What I’m saying is that is Denuvo is implemented properly, we shouldn’t see a difference that’s more than like 3%. If it’s more, then it’s called too often and thus a bad implementation from the devs. When comparison videos are shared, it’s often on games with bad implementations. You can also find some comparisons that don’t affect performance as much. In the end it’s the Denuvo implementation that’s slowing down, and that’s on the dev, not the company making unoptimized code. I’m not denying that it impacts performance: it does, but not as much as you might believe **if properly implemented**, which if not, is not Denuvo's (the company) fault, but rather the devs'.

They’re just providing a service. We should mostly blame the editors/devs that are making the choice of including it. I hate the tool but idc about the company

I get you, but I think at a certain point if we're relying on it being properly implemented and a large group isn't then I'd say we're back on denuvo as the party at fault for not addressing it and preventing it. It sucks, but we have to expect and plan for when people are stupid to a point because that is always going to be a key source of failure.

Just to be clear, I wasn't making a moral argument in my previous comment, only a technical one. If their software causes slowdowns in many real-world cases, I blame them for it, not just the people who are using it.