Menü
Marketing

Warum fühlt sich CS2 trotz hoher FPS schlecht an?

Hohe FPS bedeuten nicht automatisch gutes Spielgefühl. Warum Frame Times, 1%-Lows, Render Queue und Latenz in CS2 wichtiger sind als Average FPS.

Hohe FPS sind schön. Sie sind aber nicht automatisch gutes Spielgefühl. Wer mit 600 FPS auf einem 540-Hz-Monitor in CS2 trotzdem das Gefühl hat, die Maus klebt einen Tick zu lange, hat keinen Aussetzer in der Wahrnehmung – sondern liest die falsche Zahl. Die Beschreibungen klingen dabei fast immer gleich: Das Spiel «laggt», fühlt sich «schwammig» an oder läuft «nicht smooth», obwohl der FPS-Zähler glänzt.

Average FPS ist eine grobe Durchsatz-Kennzahl. Spielgefühl entsteht aus etwas anderem: Frame-Time-Stabilität, 1 %- und 0.1 %-Lows, Render Queue, Display-Pipeline, Eingabe­latenz, Netzwerk und Spielmechanik. Wer eine dieser Achsen ignoriert, optimiert das Falsche. Diese These ist auch die Grundlage der CS2-Latency-Fallstudie, und sie ist hier der Einstieg statt des Mess-Protokolls.

Average FPS vs. Frame Times

Average FPS sagt: «über diesen Zeitraum wurden so viele Frames gerendert.» Das ist eine Aggregations­kennzahl, kein Erlebnis. Frame Times sagen: «dieser Frame brauchte X Millisekunden, der nächste Y, der nächste Z.» Subjektiv spürbar wird nicht der Durchschnitt, sondern die Differenz zwischen den einzelnen Frames.

Ein Lauf mit 600 Average-FPS, der zwischen 1.2 ms und 5 ms schwankt, fühlt sich schlechter an als ein Lauf mit 400 Average-FPS, der konsistent bei 2.5 ms liegt. Auf hohen Refresh-Raten ist das besonders spürbar, weil das Auge die unregelmässige Aktualisierung registriert, ohne dass es einen klaren Stutter gibt. «Schwammig» ist oft genau dieses Phänomen.

Die saubere Werkzeugwahl: CapFrameX zeichnet die Frame-Time-Verteilung auf, statt nur einen Durchschnitt zu rapportieren. Erst diese Verteilung erlaubt eine Aussage über Stabilität.

Warum 1 %-Lows und 0.1 %-Lows relevant sind

1 %-Lows sind die schlechtesten 1 % der Frames in der Messung. 0.1 %-Lows die schlechtesten 0.1 %. Sie repräsentieren genau die Momente, in denen Spielen anstrengend wird – oft synchron zu engagementreichen Situationen wie Smokes, Molotovs, vielen Spielern auf demselben Sichtfeld oder Kampfeffekten.

Wenn die 1 %-Lows weit unter dem Average liegen, ist die Pipeline nicht stabil, sondern schubweise. Genau diese Schübe entscheiden Duelle. Eine ausführliche Begründung, warum diese Werte ehrlicher sind als der Durchschnitt, steht unter Average FPS lügt.

Warum ein FPS-Limiter helfen kann – aber nicht immer

Ein externer Frame-Limiter unter der durchschnittlichen GPU-Auslastung kann die Frame-Time-Verteilung straffer machen. Die Logik ist banal: wenn die GPU nicht in den Throttle rennt, läuft die Pipeline gleichmässiger. Im Latenz-Beitrag zu CS2 zeigte das auf einem konkreten Setup einen deutlichen Sprung in den 1 %-Lows – ohne dass die End-to-End-Latenz spürbar litt.

Trotzdem ist das keine pauschale Empfehlung. Auf einem System mit geringerem CPU-Headroom verändert ein Limiter die Latenz-Bilanz anders. Auf einem System mit GPU-Headroom kann das Limit zu konservativ liegen und Performance liegen lassen. Die Schritte sind einfach, aber sie sind eine **Mess-**Anleitung, kein Setting:

  1. Limit ungefähr 10 % unterhalb der durchschnittlichen FPS im Spiel setzen.
  2. In 10-FPS-Schritten senken.
  3. Bei der höchsten 1 %-Lows-Marke bleiben.

Wer das ohne Messung macht, dreht im Dunkeln.

Reflex, V-Sync, G-Sync – keine Pauschalempfehlung

Reflex reduziert die Render-Queue und damit die Eingabelatenz. Nvidia hat es zur CS2-Veröffentlichung explizit dokumentiert und beschreibt die Pipeline auch im Kontext des Reflex Latency Analyzer. G-Sync und V-Sync greifen in die Display-Pipeline ein und verhindern Tearing, kosten aber Latenz – Reflex hebt diesen Penalty teilweise wieder auf.

Was alle drei nicht sind: ein Allgemein-Setting. Auf einem 540-Hz-Monitor mit hoher GPU-Reserve verhält sich die Kombination anders als auf einem 240-Hz-Monitor mit knappem Frame-Budget. Wer die Empfehlung «GSync + VSync + Reflex» blind aus einem Reddit-Thread übernimmt, akzeptiert, dass jemand für ein anderes Setup gemessen hat. Die Mess-Realität auf konkreten Konfigurationen steht im Latenz-Beitrag, inklusive der Stellen, an denen die Valve-Empfehlung etwas mehr Latenz zeigte als ein simples -noreflex mit externem Limit.

Warum Deathmatch anders ist als der lokale Benchmark

Eine Dust2-Benchmark-Map auf localhost ist eine Mess­arena ohne Server-Last und ohne Netzwerk. Genau deshalb ist sie für Hardware-Vergleiche praktisch. Genau deshalb ist sie aber irreführend, wenn man «das Spiel» messen will.

Auf einem Valve-Deathmatch-Server kollabieren die 1 %-Lows nicht selten deutlich gegenüber der lokalen Messung. Die Ursachen sind banal: Tickrate, Server-Auslastung, viele simultane Hit-Box-Events, Memory-Verkehr durch andere Spieler, Routing-Schwankungen. Ein Setup, das lokal 450 1 %-Lows liefert, kann online unter 250 fallen. Diese Differenz erklärt einen grossen Teil des subjektiven «schwammig»-Eindrucks.

Wer ehrlich messen will, vergleicht beide Szenarien – und zieht keine Schlüsse aus dem schöneren von beiden.

Warum «schwammig» manchmal ein Mechanikproblem ist

Nicht jedes ungute Gefühl kommt aus der Pipeline. Inkonsistentes Counter-strafe, eine zu niedrige Crosshair-Höhe oder ein First-Shot, der minimal daneben sitzt, fühlen sich auf hohem Refresh erstaunlich oft wie «Lag» an – obwohl die Hardware sauber liefert. Die ausführliche Trennung steht in Input Lag vs. Aim Leak.

Kurz: Wenn Frame Times stabil sind, Click-to-Photon im erwarteten Bereich liegt und Du trotzdem Duelle verlierst, ist die nächste Datenquelle keine Treiber-Option, sondern eine eigene Demo. Werkzeuge wie der Demo Analyzer von NextFrag machen Mechanikfehler sichtbar – mit den bekannten Limits einer Demo-Auswertung.

Messreihenfolge

Eine sinnvolle Reihenfolge spart viele Stunden im Treiber-Menü:

  1. Frame Times mit CapFrameX. Stabilität prüfen, 1 %- und 0.1 %-Lows lesen. Wenn sie schon hier wackeln, hat es keinen Sinn, an Latenz zu schrauben.
  2. Click-to-Photon, falls verfügbar. Reflex Latency Analyzer oder vergleichbar. Ohne dieses Werkzeug bleibt die Latenz-Seite eine Annahme. Microsoft Learn beschreibt die Zeitgeber-Pipeline, die unter all dem läuft – Pflichtlektüre, bevor man bcdedit-Folklore übernimmt.
  3. Demo-Analyse. Erst nach 1) und 2) lohnt es sich, die Mechanik zu untersuchen.

Diese Reihenfolge ist nicht originell. Sie ist nur unbequem genug, dass viele sie überspringen.

Methodischer Hintergrund

Diese Reihenfolge ist kein CS-Trick, sondern angewandte Mess-Methodik. Was hier zwischen Average und Frame Times unterschieden wird, lässt sich in jedem datengetriebenen Feld wiederfinden – mehr dazu in Empirische Forschung – Vor- und Nachteile. Den Projektrahmen, in dem die CS2-Messungen entstanden sind, beschreibt die Nextfrag-Projektseite.

Fazit

Average FPS ist Marketing. Frame Times sind Beweismaterial. Wer in CS2 das Spielgefühl ernst nimmt, schaut nicht auf den OSD-Balken, sondern auf die Verteilung dahinter – und auf eine Click-to-Photon-Zahl, wenn das Setup sie liefert. Hohe FPS sind Voraussetzung, nicht Ergebnis.

Quellen und Einordnung

Caveat: alle Beobachtungen hier sind methodisch, nicht universell. Jede Hardware-Konfiguration, jede Treiber-Version und jede Map verschiebt das Bild. Was funktioniert, gehört gemessen, nicht geglaubt.