""I think it's super hard for a gamer," Ullmann tells Rock Paper Shotgun. "I'm a gamer myself, and therefore I know what I'm talking about. I think it's super hard to see, as a gamer, what is the immediate benefit for me that a certain game developer, game publisher, is using our anti-piracy services." This gap, coupled with the fact that Denuvo "simply works" and "pirates cannot play games" which use it, as Ullmann puts it, are two main contributors to its negative reputation, he argues."

Let's not forget about being always-online or not being able to test different wine/Proton setups for fear of activating the DRM. Or even trying simply to run the game in some situations...

  • Drathro@dormi.zone
    ·
    7 days ago

    Regarding performance implications: I believe Denuvo DRM runs through a type of virtual machine environment. While this theoretically should be relatively transparent, there are definitely documented instances of it negatively impacting performance, sometimes severely. Maybe the VM it runs in is just bad with certain instructions/calls on certain CPU's or api's, hard to tell for sure. But it's not nothing.

    • NuXCOM_90Percent@lemmy.zip
      ·
      7 days ago

      Basiaclly all DRM models have had variations of that problem. It, again, boils down to what the check is, when they do it, and how often they do it.

      For example:

      • Back in the day, Splinter Cell Conviction (and a few other ubi games) actually connected to a remote server for game logic. If you were running a cracked version and a blocker (I think peerguardian is what we used? Been a minute) then you would actually notice your game just completely hang when you went through certain doors and Sam wouldn't start talking until you turned PG off.
      • Similarly, quite a few securom and even starforce games would add the DRM check as part of the fundamental gameplay loop so you were potentially checking dozens of times per SECOND. This was a rapid checksum or a value in memory but it was still very noticeable

      And Denuvo is kind of the worst of all worlds since it is an activation model which, potentially, involves phoning home to a server.

      To my knowledge, every single case of "Denuvo killed performance in mah gerhms!!" was either

      • Complete noise. Like, less than 5% difference which could just as easily be a case of having a different tab open in your browser
      • A case of a poor implementation where the checks were way too frequent

      I am not aware of anything that was fundamentally denuvo itself. I would love to know more if you can point to a documented example but everything I have seen that actually has numbers ends up being one of the above.

      • Drathro@dormi.zone
        ·
        edit-2
        7 days ago

        You seem to be arguing it's all about the implementation of the phoning home itself- I'm arguing that running the entire executable/binary through a virtual environment likely has far more drastic performance implications than a phone home, regardless of frequency. It probably IS mostly an implementation problem, but I'm more inclined to believe that the implementation of the Denuvo virtual environment is at fault, not just a server call and response delay. **EDIT: Apologies, forgot to include a link- see HERE. Looks like a substantial/measurable difference. Not massive, as measured here, but certainly enough that if your hardware is just barely able to run a game it could easily make or break the entire experience.