HX3 Foren - Einzelnen Beitrag anzeigen

**flickflack** · 14.12.2006, 16:00

Zitat von Garack

SAuber!

Das nenne ich mal ne kompetente Antwort. Da hab ich dazugelernt ! Danke !

Eine Frage noch : Was genau beschreibt denn der Desync in der Ping Anzeige von ArmA ? Die verlorenen Pakete ?

Das alles würde erklären warum ich immer zuckelnde Spieler sehe und auch BeifahrerLaggs(a la Söldner) ziemlich krass sind obwohl die Pings ok sind.(Und auch kein Desync bei keinem Mitspieler angezeigt wird).

Ich spiele zwischen 20 (In ExtremsituatiOnen aber nur) und 50 Frames auf 1280, Schatten aus, AA normal, AF aus, Rest auf Normal außer Shader hoch.

mit einer hochgetakteten x1800XT 512MB einem AMD 4000+ und 2 GB DDR500 RAM@500 mit maxmem=1000 und einer Raptor HD.

Nach der obigen erklärung fallen die Laggs weg, wenn ich sagen wir konstant 50 Frames habe oder ?

Was genau den Desync beschreibt, kann ich nur vermuten, weil der Netcode Closed-Source ist. Das müssen kompetentere Leute erklären

Ich vermute es sind Paketverluste.

Es wäre interessant zu wissen, in welchem Intervall die Pakete verschickt werden. Alles von den Frames abhängig zu machen, bringt in der Spieleprogrammierung eine Menge Probleme und ist glaube ich bei ArmA, auch für die Kommunikation so nicht implementiert.

Stell Dir mal vor, die Bewegungen Deines Avatars wäre abhängig von den Frames, dass heisst Du baust Dein Spiel so, dass je nach erkannter Bewegung, in jedem Frame die Bewegung berechnet wird.
Würde man das jetzt genau so, einmal in der DisplayLoop des Spieles, also einmal pro Frame machen, dann würde das für Leute mit 50 FPS bedeuten, das ihre Tastatur und ihre Bewegung 50x pro Sekunde abgefragt und berechnet wird. Der Mensch mit nur 15 FPS, hätte dementsprechend einen netto Verlust von 35 FPS, er hätte also 35 Abfragen und Berechnungen pro Sekunde weniger. Das bedeutet, der Spieler mit den 50 FPS ist schneller und hat Vorteile - erklärt sich aber denke ich auch von alleine.

Also benutzt man Timer für Bewegungen in der Szene, die man zum Syncen einsetzt. Das heisst, die Bewegung wird nicht mehr an die Frames gekoppelt, sondern an den Timer, der bei allen gleich läuft, das System Zeit ist physikalische Grundlage

Es wird so bspw. die Tastatur bei allen alle 20 ms abgefragt um Fairness herzustellen.

Selbst wann man nun die Kommunikation an einen Timer koppelt, löst das trotzdem nicht das Netzwerk-Sync-Problem, das sukzessive entsteht. Es kann sein, dass erst gezeichnet wird und dann die Position verschickt, oder aber es wird erst die Position berechnet, verschickt und dann lokal gezeichnet. Total egal: die erste Variante ist sofort wieder von der Zeichengeschwindigkeit der lokalen Maschine abhängig, die zweite Variante nach dem startenden Frame. Selbst wenn man das parallelisiert, wird das Paket erste veschickt, wenn ein anderer Schritt im Programm, als auslösendes Kriterium zum Einsatz kommt - ergo: Latte wie Hose. Das Problem bleibt -> Schleifende Clients sorgen für Desync. Wenn alle gute Pings haben, der Server was aushält und über eine ordentlichen Anbindung verfügt, und alle ohne große Ruckler, oder andere Flaschenhälse verbunden sind, läufts auch ruckelfrei - sollte es zumindest. Denn eins kann man sagen: Wenn es trotz der Auflösung aller physikalisch bedingten Flaschenhälse laggt, dann ist der NetCode scheisse - egal welcher Name da auf dem Produkt steht.

Zitat von GlasSchwert

Es ist in unserer Zeit aber einfach nicht Möglich solche Kapazitäten für "gross angelegte" Spiele ala über 100 Spieler zu nutzen. Vielleicht in 5 Jahren oder mehr. Eine kleine Option für die Bandbreite wär für einige Nutzer gar nicht mal so übel gewesen; wie´s bereits erwähnt in vielen anderen Spielen verfügbar ist.

Klar, aber dabei gilt es eine performante Lösung zu finden, die on-the-fly decoden und encoden kann. 'Nen schneller PackAlgo kann auf diese Packetgröße durchaus effektiv angewendet werden, zumal Suma oder Maruk (keine Ahnung genau) schon gesagt hat, dass sich die Paketgrößen im Gegensatz zu den Größen in OFP verringert haben.

Es gibt auch keinen wirklichen Bedarf in anderen Spielen, solche Datenmengen zu übertragen, die Komplexität ist schlicht nicht gegeben. Die Anpassung der Datendurchsatzrate, ist eventuell auch nur eine Art Komprimierung im Hintergrund anderer Spiele.

Selbst wenn man weiss wie man programmiert, zaubert einem das aber noch lange nicht die Fähigkeiten zu sauberen und optimiertem Code in den Körper

Die UDP/TCP Erklärung war auch für alle die gedacht, die sich nicht damit auskennen und einen kleine erklärenden Einblick lesen wollen. Jemand der sich damit auskennt, der schweigt und überliest

14.12.2006, 16:00	#8 (permalink)
flickflack His Awesomeness! Registriert seit: 25.07.2006 Ort: Regnum Borussiae Beiträge: 9.282	Zitat von Garack SAuber! Das nenne ich mal ne kompetente Antwort. Da hab ich dazugelernt ! Danke ! Eine Frage noch : Was genau beschreibt denn der Desync in der Ping Anzeige von ArmA ? Die verlorenen Pakete ? Das alles würde erklären warum ich immer zuckelnde Spieler sehe und auch BeifahrerLaggs(a la Söldner) ziemlich krass sind obwohl die Pings ok sind.(Und auch kein Desync bei keinem Mitspieler angezeigt wird). Ich spiele zwischen 20 (In ExtremsituatiOnen aber nur) und 50 Frames auf 1280, Schatten aus, AA normal, AF aus, Rest auf Normal außer Shader hoch. mit einer hochgetakteten x1800XT 512MB einem AMD 4000+ und 2 GB DDR500 RAM@500 mit maxmem=1000 und einer Raptor HD. Nach der obigen erklärung fallen die Laggs weg, wenn ich sagen wir konstant 50 Frames habe oder ? Was genau den Desync beschreibt, kann ich nur vermuten, weil der Netcode Closed-Source ist. Das müssen kompetentere Leute erklären Ich vermute es sind Paketverluste. Es wäre interessant zu wissen, in welchem Intervall die Pakete verschickt werden. Alles von den Frames abhängig zu machen, bringt in der Spieleprogrammierung eine Menge Probleme und ist glaube ich bei ArmA, auch für die Kommunikation so nicht implementiert. Stell Dir mal vor, die Bewegungen Deines Avatars wäre abhängig von den Frames, dass heisst Du baust Dein Spiel so, dass je nach erkannter Bewegung, in jedem Frame die Bewegung berechnet wird. Würde man das jetzt genau so, einmal in der DisplayLoop des Spieles, also einmal pro Frame machen, dann würde das für Leute mit 50 FPS bedeuten, das ihre Tastatur und ihre Bewegung 50x pro Sekunde abgefragt und berechnet wird. Der Mensch mit nur 15 FPS, hätte dementsprechend einen netto Verlust von 35 FPS, er hätte also 35 Abfragen und Berechnungen pro Sekunde weniger. Das bedeutet, der Spieler mit den 50 FPS ist schneller und hat Vorteile - erklärt sich aber denke ich auch von alleine. Also benutzt man Timer für Bewegungen in der Szene, die man zum Syncen einsetzt. Das heisst, die Bewegung wird nicht mehr an die Frames gekoppelt, sondern an den Timer, der bei allen gleich läuft, das System Zeit ist physikalische Grundlage Es wird so bspw. die Tastatur bei allen alle 20 ms abgefragt um Fairness herzustellen. Selbst wann man nun die Kommunikation an einen Timer koppelt, löst das trotzdem nicht das Netzwerk-Sync-Problem, das sukzessive entsteht. Es kann sein, dass erst gezeichnet wird und dann die Position verschickt, oder aber es wird erst die Position berechnet, verschickt und dann lokal gezeichnet. Total egal: die erste Variante ist sofort wieder von der Zeichengeschwindigkeit der lokalen Maschine abhängig, die zweite Variante nach dem startenden Frame. Selbst wenn man das parallelisiert, wird das Paket erste veschickt, wenn ein anderer Schritt im Programm, als auslösendes Kriterium zum Einsatz kommt - ergo: Latte wie Hose. Das Problem bleibt -> Schleifende Clients sorgen für Desync. Wenn alle gute Pings haben, der Server was aushält und über eine ordentlichen Anbindung verfügt, und alle ohne große Ruckler, oder andere Flaschenhälse verbunden sind, läufts auch ruckelfrei - sollte es zumindest. Denn eins kann man sagen: Wenn es trotz der Auflösung aller physikalisch bedingten Flaschenhälse laggt, dann ist der NetCode scheisse - egal welcher Name da auf dem Produkt steht. Zitat von GlasSchwert Es ist in unserer Zeit aber einfach nicht Möglich solche Kapazitäten für "gross angelegte" Spiele ala über 100 Spieler zu nutzen. Vielleicht in 5 Jahren oder mehr. Eine kleine Option für die Bandbreite wär für einige Nutzer gar nicht mal so übel gewesen; wie´s bereits erwähnt in vielen anderen Spielen verfügbar ist. Klar, aber dabei gilt es eine performante Lösung zu finden, die on-the-fly decoden und encoden kann. 'Nen schneller PackAlgo kann auf diese Packetgröße durchaus effektiv angewendet werden, zumal Suma oder Maruk (keine Ahnung genau) schon gesagt hat, dass sich die Paketgrößen im Gegensatz zu den Größen in OFP verringert haben. Es gibt auch keinen wirklichen Bedarf in anderen Spielen, solche Datenmengen zu übertragen, die Komplexität ist schlicht nicht gegeben. Die Anpassung der Datendurchsatzrate, ist eventuell auch nur eine Art Komprimierung im Hintergrund anderer Spiele. Selbst wenn man weiss wie man programmiert, zaubert einem das aber noch lange nicht die Fähigkeiten zu sauberen und optimiertem Code in den Körper Die UDP/TCP Erklärung war auch für alle die gedacht, die sich nicht damit auskennen und einen kleine erklärenden Einblick lesen wollen. Jemand der sich damit auskennt, der schweigt und überliest Geändert von flickflack (14.12.2006 um 16:19 Uhr).