• Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!

News Killer Instinct: Spielgeschwindigkeit auf dem PC an FPS gekoppelt

Gorby schrieb:
Machen leider noch einige. Die Creation Engine (TES:Oblivion, TES: Skyrim, Fallout 3/NV/4) hat da auch ne Macke weg. Ist aber wirklich veraltete Konsolenmethodik. Die billge Porterei geht in die nächste Runde...

Die, die es kaufen, haben selber schuld.
 
Cool Master schrieb:
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.

Viele... leider!
Injustice, Mortal Kombat und einige unbekannte Kampfspiele.

Einfach nur ein Zeichen für mich, dass die Entwickler es nur halbherzig machen oder es denen einfach egal ist.
Eines von einigen Gründen für mich, warum Konsolen die Entwicklung nur bremsen oder ein paar Entwickler sich lieber auf Konsolen konzentrieren, weil man da weniger programmieren muss.
 
Zuletzt bearbeitet:
Handysurfer schrieb:
Eines von einigen Gründen für mich, warum Konsolen die Entwicklung nur bremsen oder ein paar Entwickler sich lieber auf Konsolen konzentrieren, weil man da weniger programmieren muss.

Die Konzentration auf die Konsolen war bisher weniger durch den Aufwand bedingt, sondern durch die Verkaufszahlen. Der Aufwand Spiele mühsam erst auf die Hardware optimieren zu müssen ist bei den Konsolen weit höher als bei den PCs wo man einfach die Anforderungen fast beliebig steigern kann.

Gute Verkaufszahlen auf dem PC Markt konnte man erst in letzer Zeit vorweisen "dank" Steam, Onlinezwang, DLCs Multiplayer und Denuvo.

Beschert hat uns der Mist eine kriechend langsame Entwicklung bei den Spielen und verkrüppelte Konsolenoptimierte UIs.
 
MR2007 schrieb:
Ein Frame wird in einer Schleife gerechnet. Wie oft diese Schleife in einer Sekunde ausgeführt wird, ist dann die FPS.
Code:
while (Spiel_laeuft)
{
    // Irgendwo in einer weit entfernten Gala... Funktion:
    Object->Position->X++;

    // Rendern
}

Das Problem lässt sich aber sehr einfach lösen.

Code:
while (Spiel_laeuft)
{
    // GetTimeDelta gibt die vergangenen sekunden seit dem letzten frame als float/double zurück
    timeDelta = GetTimeDelta();

    // Irgendwo in einer weit entfernten Gala... Funktion:
    Object->Update(timeDelta);
 
    // Rendern
}

Die Update funktion macht dann das:

Code:
Position->X += 1.0f * timeDelta;

Nun ist es egal wie viele frames wir haben. Er wird sich in einer Sekunde eine Einheit bewegen.
Wenn man das von Anfang an in seinem Spiel bedenkt ist das extrem easy.
 
Es wurde doch schon mehrmals erklärt das es bei Kampfspielen normal ist mit frames zu rechnen und nicht mit Zeiten :rolleyes:
Das Problem liegt nicht am Spiel (buuhh Konsolenport! Buuuuh!) sondern am App-Charakter. Dort werden die Optionen nämlich zusammengestrichen und (wie hier) Fehler gemacht.
Ich verstehe nicht wie man bei einem Vorbild wie Steam so etwas nicht auf die Reihe bekommt. Aber Origin und uPlay hängen ja auch noch hinterher. Einfach "was kann steam ? Wie kommt es an ? Das brauchen wir auch."
 
Nun ist es egal wie viele frames wir haben. Er wird sich in einer Sekunde eine Einheit bewegen.
Wenn man das von Anfang an in seinem Spiel bedenkt ist das extrem easy.
Im einfachsten Fall der linearen Bewegung gilt das ja. Aber bereits bei einer Bewegung mit einer konstanten Beschleunigung treten dort Probleme auf; z.B. :
Position->X += 1.f * timeDelta + 0.5 * timeDelta*timeDelta
Je nachdem wie die Engine nun timedelta wählt befindet sich das Objekt nach einer Sekunde an einem anderen Ort. Dieses und ähnliche Probleme pflanzen sich dann überall durch die Spiellogik bei einer variablen Zeitschrittweite fort.
 
Muahahaha :evillol: ...ja ne is klar, MS versteht die Spieler.
Tja, da fallen die Consoleros eiskalt auf die Schnauze, wenn sie in die harte PC-Realität entlassen werden.
Erschreckend das es solch altbekannten Technikkrücken ins neue Jahrtausend geschafft haben.

Lasst die überteuerten Hardwaredongle aka Konsolen mMn einfach verrecken, das hat keine sinnvolle Zukunft.
 
Crass Spektakel schrieb:
Lol ist ja wie auf dem C64, da liefen Programme auf NTSC-Rechnern auch 20% schneller als auf PAL...

Selbst auf dem Amiga hat es sowas nicht mehr gegeben.

ntsc-rechner lol
ntsc und pal waren fernseh-standards
 
Wie schon angemerkt wurde, ist ein FPS-Lock bei Fighting-Games Standard.
 
@Mr.smith: da scheint sich jemand nicht mit alten Computern und Konsolen auszukennen... damals nutzte man TVs als Ausgabegerät und deshalb gab es PAL und NTSC Modelle, die bei manchen Geräten unterschiedlich schnelle CPUs hatten, da der Ausgabetakt des Grafikchips an den Systemtakt gekoppelt war
 
In der Tat beim N64 gab es auch PAL und NTSC Spiele.
 
Nai schrieb:
Bei dieser Vorgehensweise ist jedoch problematisch, dass die Simulationsgenauigkeit im Endeffekt von der Geschwindigkeit des Computers abhängig ist[..]Deshalb bevorzuge ich persönlich Mainloops wo DT konstant ist
Eben, deshalb eben der Ausgleich über einen Korrekturterm wie z.b. El_Sheepy es beschrieben hat. Damit ist das kein Problem und das Spiel kann auch mit 2 oder 9999 FPS laufen, die Spielgeschwindigkeit bleibt gleich. Eine erzwungene konstante Schleifenlaufzeit mag zwei bei hoher Laufrate Sinn machen, aber sobald es zu lange dauert, macht sichs auch bemerkbar.

Das mit der beschleunigten Bewegung sehe ich nicht als Problem, physikalisch ist daran ja nichts falsch. Hatte da noch nie Probleme damit. Natürlich gibt es auch einen Fehler, der dadurch entsteht, dass die Korrektur immer nur den vorherigen Frame ausgleicht, das tritt aber auch schon bei linearen Bewegungen auf. Aber da im seltensten Fall überhaupt eine höhere Ordnung als 2 auftritt, sollte sich da nichts fortpflanzen, vorallem wenn man bedenkt, in welcher zeitlichen Größenordnung wir uns eigentlich befinden. Als Spieler unspürbar, und selbst für Netzwerksynchronität sollte, wenn nicht gerade über einen längeren Zeitraum die FPS sehr stark fluktuiert, das völlig ausreichend sein.

Aber ich kann man hier auch vorstellen, dass man durch Multithreading hier eleganter und genauer arbeiten könnte, aber wie schon erwähnt, up-to-date bin ich da leider nicht. Aber führt wohl hier auch zu weit :freaky:

yii schrieb:
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.
Danke für die Erklärung, mit dem Genre bin ich nicht vertraut. Das mit den Animationen macht Sinn - dann sollte aber auch die Korrektur kein hoher Aufwand sein. Dann müssen nur die Darstellungsfunktionen zeitabhängig korrigiert werden, denn "nicht revelant" ist es auch hier nicht. Das ursprüngliche Prinzip bleibt ja das gleiche, es wird dann nur der Framezähler der Animationen pro Schleifendurchlauf um den Wert 1 erhöht anstatt z.B. einer Translation eines Objektes. Hier könnte man einen analogen Ansatz nehmen und die Korrektur auf den Zähler draufsatteln und für den Frame zur Darstellung einfach die Nachkommastellen abschneiden. So wäre ich zumindest mal ganz naiv vorgegangen.

Aber da ich mal vermute, dass diese Art von Spielen nicht so anspruchsvoll sind, dass sie jemals in den < 60 FPS Bereich kommen, tut es wohl wirklich auch ein einfacher FPS Lock. Wobei ich ich mir dann aber die Frage stelle, wie man sowas veröffentlichen kann, ohne dass dies beim testen auffällt.:rolleyes:
 
Zuletzt bearbeitet:
Cool Master schrieb:
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.

Naja, zumindest hat man was zum schmunzeln, und im Vergleich zu leftpad-Desaster ist das hier noch harmlos ;)
 
Nai schrieb:
Aber bereits bei einer Bewegung mit einer konstanten Beschleunigung treten dort Probleme auf
Wobei man das konkrete Problem auch noch lösen kann, indem man die entsprechenden Integrale einfach mal ausrechnet. Witzig wird es erst, wenn sich irgendeine Größe sehr häufig auf nicht-stetige Art und Weise ändert.

Axxid schrieb:
Es wurde doch schon mehrmals erklärt dass es bei Kampfspielen normal ist mit frames zu rechnen und nicht mit Zeiten
Es wurde erklärt, dass es so ist, aber nicht, warum es in dem Genre so sein muss. Und um ehrlich zu sein, fehlt mir dafür auch das Verständnis. Ich meine, das ist ja nicht das einzige Genre mit Spiellogik, Timing und Physik...
 
Gibt es wirklich Leute, die diesen UWP App Mist kaufen? Gefesselt, gebunden, abhängig, alternativlos, personalisiert ohne Chance auf Entkopllung oder anonyme Bezahlmethoden. :kotz:

Ich habe irgendwo die Vermutung, dass dieses Phänomen bei einigen Konsolenspielen gang und gebe ist. Schliesslich ist es einfach umzusetzen und es haben ja alle die gleiche Hardware, also auch fps.
 
It's not a bug, it's a feature - wähle mit der spielgeschwindigkeit den schwierigkeitsgrad ;)
 
Zurück
Oben