2.2 Die Synergie zwischen FPS und Maxpackets

Vielen ist nicht ganz klar welche Vor- und Nachteile die Beziehung von com_maxFPS und cl_maxpackets hat. Warum werden die FPS in Call of Duty 4 (CoD4) beschränkt? Warum erlaubt der deutsche Bereich der ESL sogar nur 125 FPS? Welche tiefergehende Wirkung haben die Maxpackets im Zusammenhang mit den FPS?

Im folgenden Artikel werden diese und weitere Fragen geklärt. Aber Achtung: Es kommt auch ein wenig Mathematik vor! :p

Ein wenig Grundwissen um die folgenden Überlegungen anzustellen, kann man einer E-Mail von arQon einem Entwickler des CMPA Quake 3 Promode, entnehmen.

and cl_maxpackets give you the ability to send an update every frame or
every 2 frames, 3 frames, or 4 frames (and so-on) which means that the
amount of packets you send is still roughly connected to your frames per
second.

Dieses Zitat aus der E-Mail ist das wesentlichste der ganzen E-Mail. In der E-Mail wird aber noch wesentlich genauer auf diesen Satz eingegangen.

Maxpackets -> Maxfps

Wie wir aus einem anderen Artikel des GameGuides bereits wissen:

  • pro FPS maximal 1 Paket
  • Maxpackets müssen ein Teiler der FPS sein
  • der Teiler muss ein Integer-Wert sein

Weiterführend ist zu sagen, dass der Client (also der PC des Spielers) pro Frame ein Command erstellt. Ein Command enthält Informationen darüber, welche Knöpfe der Spieler gerade drückt, wohin der Spieler gerade schaut (View-Koordinaten), wo der Spieler gerade steht (Positions-Koordinaten) und wie die Maus bewegt wurde. Diese Command-Listen sind circa 20 byte (~0,00002 MB) Groß.

Wenn wir 125 FPS haben, erstellen wir also 125 Commands die Sekunde. Bei 250 Frames-per-Second logischerweise 250 CPS (Commands per Second). Bei 250 FPS wird also alle 4 ms abgefragt was wir gerade machen. Bei 125 FPS alle 8 ms und bei 100 FPS alle 10 ms. Das verdeutlicht, warum wir zum flüssigen Spielen nicht mehr als 125 FPS benötigen, wer erstellt schon mehr als 125 Aktionen in der Sekunde? (Dieser Satz war bezogen auf die ESL-DE Diskussion)

Eigentlich… Ja nun, wieso eigentlich “Eigentlich“? Es gab viele – vor allem “professionelle” – Spieler, die sich beschwert haben, das es bei 125 FPS ruckeliger wäre als bei 250 FPS. Aus eigener Erfahrung kann ich sagen: Ja es stimmt, aber… das liegt meiner Meinung nach größtenteils an der Gewöhnung. Als zweiten Grund habe ich eine Theorie, die ich so nicht 100%ig beweisen kann, welche aber – für mich zumindest – schlüssig und logisch ist. Wie wir wissen wird pro FPS ein Command erstellt. Dreht man sich nun um 180° innerhalb von einer Sekunde, können nur 125° in dieser Sekunde verarbeitet werden, der rest wird interpoliert. Sollte diese Theorie stimmen, muss man sich trotzdem Fragen, ob man wirklich dauerhaft in der Lage ist diese interpolation zu sehen – das bezweifel ich stark -. Ich denke man kann sich sehr gut daran gewöhnen.

Warum verbietet nun aber der deutsche Bereich der ESL FPS > 125? Durch diese Frage kommen wir der Überschrift dieses Abschnitts schon näher, nämlich der Beziehung von Maxpackets und FPS. Wir wissen, dass durch hohe FPS, Beispielsweise 333 FPS, Bugs auftreten. Lautloses gehen ist hier das Stichwort. Auch bei 250 FPS treten Bugs im Movement etc. auf, aber solch hohe FPS in Verbindung mit den richtigen Maxpackets haben enorme – sehr wahrscheinlich unfaire – Vorteile. Um das folgende Rechenbeispiel detailiert verstehen zu können, ist es ratsam den  Kapitel 2.1 Die Maxpackets Artikel gelesen zu haben. Bitte tut dies – falls noch nicht geschehen – bevor ihr weiter lest.

FPS max. zulässige MP =
100 100 1 Command / Paket
125 63 2 Commands / Paket
250 84 3 Command / Paket

100 FPS -> alle 10 ms ein neuer Frame
125 FPS -> alle 8 ms ein neuer Frame
250 FPS -> alle 4 ms ein neuer Frame

Nun rechnen wir aus in welchen Abständen und mit wievielen Command-Listen ein Paket gesendet wird, in Abhängigkeit der Einstellung von com_maxFPS.

100 FPS / 100 MP

  • jedes Paket besteht aus einer Command-Liste, also ein Frame
  • jeden Frame wird ein Paket verschickt
  • 1 Frame = 10 ms
  • alle 10 ms wird ein Paket verschickt. Inhalt: 1 Command-Liste

125 FPS / 63 MP

  • jedes Paket besteht aus zwei Command-Listen, also zwei Frames
  • alle zwei Frames wird ein Paket gesendet
  • 1 Frame = 8 ms; 2 Frames = 16 ms
  • alle 16 ms wird ein Paket verschickt. Inhalt: 2 Command-Listen

250 FPS / 84 MP

  • jedes Paket besteht aus 3 Command-Listen, also 3 Frames
  • alle drei Frames ein Paket
  • 1 Frame = 4 ms; 3 Frames = 12 ms
  • alle 12 ms wird ein Paket verschickt. Inhalt: 3 Command-Listen

Ich hoffe, dass es bis hierhin verständlich genug ist. Etwaige Fragen können in den Kommentaren gestellt werden. Hierfür benötigt ihr einen Account und müsst eingeloggt sein. Ich / Wir beantworte(n) alle Fragen sehr gerne und so schnell wie möglich!

Das Ergebnis der Beziehung

Um alles auf einen gemeinsamen Nenner zu kommen, habe ich die Zeit auf 240 ms gesetzt, hierbei ergibt sich folgendes Bild:

FPS / MP Pakete Command-Listen
100 / 100 24 24
125 / 63 15 30
250 / 84 20 60

Für den Abgleich mit dem Server ist es natürlich am besten wenn man die 100/100 nimmt. So wird – zumindest wenn alles Konstant ist (FPS, Leitung usw.) – alles was man macht übertragen. Der Server weiss schnell bescheid (10 ms) über jeden einzelnen FPS. Es sollte genaueres Zielen möglich sein und ebenso keinen Durchschuss geben. Nachteil: Schnelle Reaktionen im ms-Bereich werden schlechter übertragen und Dargestellt.

Wenn man einen Vergleich von 125 FPS und 250 FPS anhand obiger Tabelle ansieht wird relativ schnell deutlich, warum 250 FPS ein unfairer Vorteil sind. Bei 250 FPS ist die Synchronität mit dem Server besser, man meldet dem Server 25% öfter seine Aktionen. Nicht nur, dass man dem Server öfter Aktionen übermittel (Command-Listen), sondern auch wesentlich mehr, nämlich doppelt soviele Aktionen (60 zu 30).

Nun kann man eine Grundsatz-Diskussion darüber führen, ob nicht alle Spieler, die professionell Spielen wollen, Geld investieren müssen um 250 FPS Konstant nutzen zu können oder nicht. Sollange hierbei kein Ergebnis erzielt wird ist die einzig faire Variante die FPS-Obergrenze auf 125 zu setzen.

Und wofür sorgen die sv_FPS?

Die sv_FPS sind im Prinzip das gleiche wie die com_maxFPS. Es funktioniert im Prinzip gleich wie die com_maxFPS. sv_FPS 20 bedeutet also, dass der Server alle 50 ms eine Aktion ausführt. Er arbeitet also alle 50 ms alle ihm geschickten Command-Listen ab, führt diese aus, baut ein Gameworld-Update (Frame) und schickt diesen an den Client. Der Client empfängt also alle 50 ms ein Gameworld-Update (sofern diese den Wert snaps auch auf 20 hat). Ihr seht, es ist alles genauso wie beim Client.

Jetzt könnt ihr euch ausmalen warum sv_FPS 30 wesentlich besser sind. Durch sv_FPS 30 entstehen aber Bugs, da die Coder von Call of Duty 4 viele Werte und Berechnungen auf sv_FPS 20 hardgecoded haben. Dieser Fehler kann nur durch Mods behoben werden.

Wie mache ich was?

FPS-Begrenzung einstellen:
Entweder fügt ihr der Config “seta com_maxFPS XXX” hinzu, wobei XXX für den gewünschten Wert steht oder ihr öffnet die Console (idR. mit dem ^) und gebt dort “com_maxFPS XXX” ein. Natürlich jeweils ohne die Tüttelchen.

Maxpackets einstellen:
Config -> “seta cl_maxpackets XXX”
Console -> “cl_maxpackets XXX”

Die Serverframes:
Die Serverframes werden per Befehl “sv_fps XX” eingestellt. Dieser Befehl kann entweder in die Serverconfig oder in die Startparameter geschrieben werden. Der Befehl muss vor dem Serverstart aktiviert werden, nach dem Serverstart ist er Read-Only und kann nicht mehr geändert werden.

Glossar

  • MP = Maxpackets
  • FPS = Frames per Second
  • SV = Server
  • CPS = Commands per Second
  • ESL = Electronic Sports League
  • ms = milli-sekunden (1 sekunde = 1.000 ms)
Leave A Comment