News Killer Instinct: Spielgeschwindigkeit auf dem PC an FPS gekoppelt

[yii]

Es ist relativ normal dass Fighting Games die Animationsgeschwindigkeit an die Frames binden. Normalerweise laufen diese Spiele auch festgesetzt mit 60fps.

Ich denke das Problem bei Killer Instinct ist forced VSync, dass bei Monitoren mit höheren Wiederholraten die Framerate an diese anpasst.
Und da es ein wunderbar gesperrtes Windows Store Exclusive ist, kommt man auch nur schwer über den Grafikkartentreiber oder andere Programme ran um die Framerate zu locken ohne sich dabei sein System zu zerschießen.

 

[DeusoftheWired]

da Killer Instinct als UWP-App (Universal Windows Platform) wurde

Gibt es überhaupt ein UWP Spiel das einwandfrei läuft? Das Gears of War Debakel, die UWP Version von Tomb Raider lief auch nicht sauber und jetzt Killer Instinct. Dazu kommen noch die bekannten UWP Einschränkungen (Borderless Fullscreen, SLI ect). Ich ahne schlimmes für Quantum Break. […]

MS versucht auf Biegen und Brechen, 10 und die UWPs durchzudrücken. Ist nur doof, wenn das, was als Köder dienen soll, eher abschreckt als animiert.

Welcher Progrmmierer ist so blöd und macht das noch? Das sollte seit Mitte der 90er nicht mehr passieren da es deutlich bessere Taktgeber als die FPS gibt.

Ist nicht nur MS passiert, sondern vor kurzem erst Bethesda mit Fallout 4. €dit:luda war schneller. /€dit

 

[Ned Stark]

Ernsthaft?!

Also ich arbeite ja gerne mit den kostenlosen Engines WaveEngine und Unity3D. Und diese kostenlosen Engines bieten einem eine gameTime Variable an die man einfach nur für die bewegungen mit rein kalkulieren muss, fertig!!!

Das ist doch nicht so schwer!

Das wird mit an Sicherheit grenzender Wahrscheinlichkeit eine andere Engine sein.

Ist halt auch ein gewisser Vorteil der Konsolenplattformen das man so etwas machen kann um sich das programmieren zu vereinfachen...

Als Programmierer würde ich hier sagen der Code riecht.

 

[Chillaholic]

Welcher Progrmmierer ist so blöd und macht das noch? Das sollte seit Mitte der 90er nicht mehr passieren da es deutlich bessere Taktgeber als die FPS gibt.

Bethesda

 

[McNugget]

Die meisten Probleme bei UWP-Spielen sollen ab Mai behoben sein. Wurde vorhin auf der Build-Konferenz von Phil Spencer gesagt. Siehe zwischen 1:30:24 und 1:31:05. https://www.youtube.com/watch?v=GgutlKV42SY

 

[El_Sheepy]

Das wird mit an Sicherheit grenzender Wahrscheinlichkeit eine andere Engine sein.

Davon würde ich auch ausgehen. Ich frage mich nur warum die nicht einfach eine von den Engines genommen haben

 

[Schaby]

Bei Lightning Returns-FF13 ist das Spawnen der Gegner an die FPS gekoppelt. Auf dem PC-Port kann man da zwischen 30 und 60 FPS wählen. Bei 60 FPS kann man keine 2 Meter laufen ohne zu kämpfen. Anfangs fand ichs ganz witzig, aber mit der Zeit ist es einfach nur Ätzend obwohl man im Spielverlauf alle Monster "ausrotten" sollte.

 

[MR2007]

Man sollte vllt noch erwähnen, da hier viele fragen "warum machen die das?", dass man das nicht einfach so macht, sondern sich automatisch ergibt, und das es genau der umgekehrte Fall ist, dass die Frameunabhängigkeit zusätzlicher Aufwand ist (und wie der Autor bereits bemerkte, kann das nachträglich je nach Struktur sehr ätzend sein).

Das Problem ergibt sich völlig natürlich:

Ein Frame wird in einer Schleife gerechnet. Wie oft diese Schleife in einer Sekunde ausgeführt wird, ist dann die FPS.

while (Spiel_laeuft)
{
    // Irgendwo in einer weit entfernten Gala... Funktion:
    Object->Position->X++;

    // Rendern
}

Das wäre Frameabhängige Bewegung. Entkoppelt wäre es, wenn noch ein Faktor dazu kommt, der von der Zeitdauer des Schleifendurchlaufs abhängt. D.h. dauert es lange eine Schleife zu berechnen (FPS sinkt) erhöht sich dieser Faktor (da in einem bestimmten Zeitraum, die Bewegungsberechnung seltener ausgeführt wird, und deshalb der Betrag der Bewegung größer sein muss), läuft sie schnell durch (FPS steigt), wird dieser Faktor folglich klein.

Wenn man dies konsequent durchzieht, ist es auch ein Einzeiler diesen Faktor mit einer Spielgeschwindigkeitskonstante zu koppeln (wie in #8 erwähnt). Hat man dies jedoch nicht gemacht. Nun, dann muss man wohl durch sämtliche Tiefen des Breis nochmal durchtauchen.

Heutzutage müsste es aber bestimmt auch andere, bessere Möglichkeiten geben, hatte damit seit Jahren nichts mehr am Hut.

 

[yii]

@MR2007

Das ist zwar richtig, aber nicht relevant für Fighting Games wie Killer Instinct, Mortal Kombat, Street Fighter etc.
Die laufen seit jeher mit 60fps, und daran gebundenen Animationen. Der Sprung von Charakter X dauert 45 Frames, der Overhead-Kick von Charakter Y 15, der Uppercut von Charakter Z 21 Frames usw. Es gibt Attacken die man nicht Blocken kann, d.h. man muss ihnen mit Springen oder Dashen ausweichen. Dafür muss man wieder die Animationszeit des Angriffs und die Animationszeit des Sprunges berücksichtigen.
Der unblockbare Angriff benötigt 25 Frames 'Vorlauf'animation, der Sprung aber nur 15, woraus sich ein Fenster ergibt in dem man auf den Angriff reagieren kann.

Das hängt vor allem mit menschlicher Reaktionszeit zusammen, und wie man diese mit Skill in Verbindung bringen kann. Wie schwer ist es, eine Combo frameperfekt aneinanderzureihen oder einen Combobreaker unterzubringen. Wie viel Frames hat man Zeit, um auf einen schweren oder leichten Angriff zu kontern/blocken etc. Das sind Sachen die in diesen Spielen eine Rolle spielen.


Es ist ein etablierte Herangehensweise der Entwickler festzulegen, wie viel Frames der Aufbau einer Animation bis zum eigentlichen Hit benötigt, um eine Balance herzustellen. Kann man das auch mit Delta-Zeit Frameberechnung machen? Sicherlich, aber es dürfte ungemein schwieriger sein.

Killer Instinct Fehler ist, dass es nicht auf 60 FPS gelockt ist - unabhängig von der Wiederholrate. Das ist alles. Wenn du auf 60Hz mit 60 FPS spielst läuft es einwandfrei.

 

[TheInterceptor]

Das sollte seit Mitte der 90er nicht mehr passieren da es deutlich bessere Taktgeber als die FPS gibt.

Das ist technischer Unfug. Um Zeit zu messen brauchst du allgemein einen Taktgeber. Ob du jetzt die Bildrate misst oder was anderes, du misst Zeit.

Was hat jetzt die FPS mit der Bildschirmfrequenz zu tun?

Framelock. Da wird wohl VSync erzwungen.

Welche die normalerweise nur für die Konsolen entwickeln. Ist halt auch ein gewisser Vorteil der Konsolenplattformen das man so etwas machen kann um sich das programmieren zu vereinfachen...

Naja, idR reicht die billige Konsole ja nicht aus um etwas konstant auf der Zielbildrate zu halten.
Sowas müsste dem Studio spätestens bei der Entwicklung Probleme bereiten.

 

[ZeT]

Welcher Progrmmierer ist so blöd und macht das noch? Das sollte seit Mitte der 90er nicht mehr passieren da es deutlich bessere Taktgeber als die FPS gibt.

Erinnert mich an Snake....

 

[karamba]

Wo ist der Turboschalter, wenn man ihn braucht.

 

[Cool Master]

Bethesda, siehe Fallout 4.^^

Ist nicht nur MS passiert, sondern vor kurzem erst Bethesda mit Fallout 4. €dit:luda war schneller. /€dit

Bethesda

Ok, das würde wieder für dafür sprechen, dass die Konsole die Lead Platform war.

Das ist technischer Unfug. Um Zeit zu messen brauchst du allgemein einen Taktgeber. Ob du jetzt die Bildrate misst oder was anderes, du misst Zeit.

Eben sag ich ja. Es ist technisch einfach misst das über die FPS oder die Bildwiederholfrequenz zu machen. Ein Taktgeber bzw. Zeitgeber kann man wunderbar als Funktion umsetzen und das ganze ist sogar schon in C++ mit dabei mit der Funktion clock().

 

[TheInterceptor]

Eben sag ich ja. Es ist technisch einfach misst das über die FPS oder die Bildwiederholfrequenz zu machen. Ein Taktgeber bzw. Zeitgeber kann man wunderbar als Funktion umsetzen und das ganze ist sogar schon in C++ mit dabei mit der Funktion clock().

Das ist schön, hat aber mit deiner Aussage letztendlich nichts zu tun. Der eine Satz hat aber mindestens einen Wortfehler. Allerdings macht das in beiden Interpretationsvarianten keinen Unterschied.
Der einzige Unterschied bei einer Umsetzung über variable Simulationsgeschwindigkeiten ist die erforderliche Multiplikation aller Komponenten.
Historisch war das wohl nicht vertretbar, weil diese Operationen Fließkommaoperationen sein hätten müssen, was sich allerdings extrem auf die Performance auswirkt (zumindest damals).

 

[Jesterfox]

Jepp, schlussendlich muss man das ganze ja wieder mit den FPS synchronisieren damit das angezeigte Bild passt. Diesen sync Aufwand spart man sich wenn man es direkt an die FPS koppelt, was auf den Konsolen dank der gelockten FPS halt auch recht gut funktioniert...

 

[romeon]

Outrun Coast2Coast war auch so. Auf CRT mit 100Hz extreeeeeem flott, auf TFT mit vorgesehenen 60Hz wesentlich einfacher ...

 

[s3bish]

Was hat jetzt die FPS mit der Bildschirmfrequenz zu tun?

Vertikale Synchronsation = Feste 60 oder 120 FPS

 

[sikkness]

@MR2007

Das ist zwar richtig, aber nicht relevant für Fighting Games wie Killer Instinct, Mortal Kombat, Street Fighter etc.
Die laufen seit jeher mit 60fps, und daran gebundenen Animationen.

[...]

Killer Instinct Fehler ist, dass es nicht auf 60 FPS gelockt ist - unabhängig von der Wiederholrate. Das ist alles. Wenn du auf 60Hz mit 60 FPS spielst läuft es einwandfrei.

Wenigstens einer der die Thematik hier versteht, danke.
SF 5 läuft aus gleichem Grund mit verringter Geschwindigkeit bei <60 FPS und wird asynchron im Multiplayer.

Bei den endlosen Kommentaren über Konsolenports, Turbotasten, Bethesda-Vergleiche und weiss der Himmel was sonst pack ich mir echt nur an den Kopf.

Ja, es ist blöd trotz der Investition in einen feinen Screen nicht auf 144hz zocken zu können, und das kann ich vollends nachvollziehen, aber das ist nunmal so bei Fightern. Gameplay basiert auf Frames, und da müssen die Spielbedingungen für alle gleich sein.
Dürfte mittlerweile jedem bekannt sein, der das Genre spielt. Ziemlich offensichtlich wer in den Comments dies tut, und wer 'n einfaches Entwicklerbashing bei dem Thema gerochen hat.

Das Problem ist -wie yii- sagte nicht, dass das Spiel >60 FPS zu schnell läuft, sondern dass es überhaupt >60 fps zulässt.

 

[Nai]

Das wäre Frameabhängige Bewegung. Entkoppelt wäre es, wenn noch ein Faktor dazu kommt, der von der Zeitdauer des Schleifendurchlaufs abhängt. D.h. dauert es lange eine Schleife zu berechnen (FPS sinkt) erhöht sich dieser Faktor (da in einem bestimmten Zeitraum, die Bewegungsberechnung seltener ausgeführt wird, und deshalb der Betrag der Bewegung größer sein muss), läuft sie schnell durch (FPS steigt), wird dieser Faktor folglich klein.

Bei dieser Vorgehensweise ist jedoch problematisch, dass die Simulationsgenauigkeit im Endeffekt von der Geschwindigkeit des Computers abhängig ist. Läuft der Computer zu schnell bzw zu langsam können deshalb "unvorhergesehene" Effekte bzw. nur schwer zu vermeidende Fehler auftreten. Nich umsonst existiert in der Informatik ein Paradigma, dass ein Programm unabhängig von der Rechengeschwindigkeit immer korrekt arbeiten sollte.

Deshalb bevorzuge ich persönlich Mainloops wo DT konstant ist, die CPU am Ende jeden schleifendurchlauf wartet, wenn sie zu schnell war, und es zudem zu einem Slowdown kommt, wenn der Rechner nicht mehr mithalten kann.

 

[dermatu]

fand ich schon bei fallout peinlich ...

Ergänzung (31. März 2016)

Ja, es ist blöd trotz der Investition in einen feinen Screen nicht auf 144hz zocken zu können, und das kann ich vollends nachvollziehen, aber das ist nunmal so bei Fightern. Gameplay basiert auf Frames, und da müssen die Spielbedingungen für alle gleich sein. Dürfte mittlerweile jedem bekannt sein, der das Genre spielt. Ziemlich offensichtlich wer in den Comments dies tut, und wer 'n einfaches Entwicklerbashing bei dem Thema gerochen hat.

eigentlich muss nur der netcode die gleiche anzahl an informationen pro sekunde austauschen. mit wie vielen bildern pro sekunde der client die information umsetzt und dann etwas rendert sollte man davon unabhängig hinbekommen...