Announcement

Collapse
No announcement yet.

RadeonSI Gallium3D Might Run As Well As Catalyst For CS:GO Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by My8th View Post
    It be nice to see power usage stats with Vsync on, I always have it on. It be nice to see some phoronix tests with it to see what cards/drivers combos have the best power efficiency and have consistent fps(don't drop) with Vsync on.
    Found a link were they have done a few tests. Basically if you cap the fps, the larger the fps decrease, the larger the power savings. So an old game that you can run at 140 fps, v-synced down to 60 will have larger energy savings than a game that could run at 80fps.
    http://ecogamer.co.uk/viewpages.php?...ency_and_Vsync

    Comment


    • #42
      Originally posted by AnAkIn View Post
      Actually, this is wrong in most FPS games, there is a use to higher FPS than your refresh rate: on HL1 and Source engine games, the client will send a command packet on every frame. If you limit your FPS to your refresh rate, then you'll limit the number of command packets you're sending to the server, which mostly means that you'll have a worse bullet registry. TF2 servers run at a tickrate of 66, which means you should at least have 66 FPS on your client if you want to send 66 packets/s. CS GO, it depends of the server, but a lot of servers are tickrate 128...so it would be best to have at least 128 FPS.

      Yeah. The early valve games (hl1/tfc/cs) had that design flaw. They did a good number of things right, but not everything. Having the updates be in sync with the fps is bad as it gives some players a more responsive game. Players could exploit that to their advantage because of that. Because of the lessons learned from those early pioneers, it is now considered best practice to have the packet rate seperate from the fps.

      Comment

      Working...
      X