60 FPS ein must have?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • 60 FPS ein must have?

      Bei meinem aktuellen Projekt überlege ich von 60 auf sagen wir mal 44 FPS als Roomspeed einzustellen. Es läuft zwar fast gänzlich flüssig, also geht nur mal kurz um 2-3 FPS runter aber es ollte auch auf älteren PCs oder Laptops laufen. Und da ich Programmiertechnisch schon ziemlich viel ausgereizt hab, was die Performance erhöht dachte ich mir ich gehe mit dem Roomspeed runter.

      Aber jetzt die Frage. Wie uncool ist es wenn dass SPiel mit weniger als 60 Frames läuft? 30 sind mirt auch zu wenig, da ich zeitlupenartige Bewegungen drin hab und die sonst ruckelig ausehen würden. Also dachte ich mir ich mach 44 Fps. 24 Bilder pro Sekunden ergeben ein flüssiges Bild. Ich hätte dann 2 mal fast 24 Bilder pro Sekunde. Oder sollte ich mich zwischen 30 und 60 FPS entscheiden? Ich weiß da gibt es keine Regeln aber wie würdet ihr das machen?
    • Ich würde sagen, dass 30fps für ein nicht 3D Spiel vollkommen ausreichen.

      @blubberkopp ich finde schon, dass man einen Unterschied erkennt. Aber ob man es braucht ist eben die Frage. Auf z.b. Android würde ich 30 fps bevorzugen, da alles drüber das Handy/tablet unnötig aufheizt

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von HIM666 ()

    • Die Wahl zwischen 30 und 60 macht dahingehend Sinn, dass die meisten Bildschirme 60hz haben, es also weniger Tearing gibt.
      144hz Monitore haben diesen Wert, weil es ein Vielfaches von 24 ist und somit die ganzen Kinofilme Stotterfrei drauf laufen können.

      Und das heute immer noch behauptet wird, dass Auge könne nicht mehr als 24bilder pro Sekunde wahrnehmen... Zu 24fps bei Kinofilmen ist es nicht gekommen, weil das Auge nicht mehr wahrnimmt, sondern weil das Auge bei den meisten erst ab da anfängt Bewegungen als solche zu interpretieren. Mehr hat man nicht genommen, weil die Filmrollen teuer waren. Selbst zwischen 60fps und 120fps nimmt man einen deutlichen Unterschied wahr. Aber wirklich notwendig werden höhere FPS nur bei schnellerem Gameplay bzw. sich schnell bewegenden Elementen auf dem Bild, wie der Ball bei Pong.
    • Ich habe bei meinem letzten Spiel X-Bloxx auch lange mit "nur" 40 FPS (room_speed) gearbeitet. Habe mir gedacht das reicht vollkommen und lief super.

      Dann hatte ich beim Aufnehmen einiger Spielszenen Probleme beim rendern der Videos. Da das Spiel in 40FPS lief und ich entweder 30FPS Video wollte oder 60FPS. Aber das ging dann nicht so recht.
      Dann hab ich mein Spiel auf 60FPS umgestellt und mir ist dann schon ein gewaltiger Unterschied aufgefallen.

      Auch bei 3D Spielen fällt der Unterscheid meiner Meinung schon sehr auf. 60 FPS sind heutzutage schon ein musthave in meinen Augen :)
    • Es gibt einen einfachen Grund warum Filme meistens nur 24 FPS haben. Das Geheimniss liegt bei Motion Blur. Auf der Netzhaut des Auges, brennt sich das Bild für ca. 50 ms ein. Deswegen verschmelzen alle Bilder in dieser Zeitspanne zu einem Bild. Das gleiche passiert beim Filmen auf dem Sensor. Nun können wir nicht unterscheiden, ob dieser Effekt in unserem Auge entsteht oder dieser simuliert wurde, deswegen reicht diese Framezahl bei Filmen föllig aus. Anders ist es bei Videospielen. Hier ist die Belichtungszeit Null, also eine perfekte Momentaufnahme. Das nehmen wir dann als ruckeln war. Wenn sich ein Objekt schnell bewegt, fehlen die Informationen für das Auge für die Zeit dazwischen und das Objekt scheint sich zu teleportieren (Was in Wirklichkeit auch wirklich passiert), was wir dann als Ruckeln wahrnehmen. Deswegen lohnen sich hier so viele Frames, weil dieser wichtige Effekt dadurch in unserem Auge simuliert wird. Wir könnten hier also noch bei 200 FPS einen Unterschied erkennen. Man kann dem mit Motionblur entgegenwirken, wodurch dieser Effekt wieder vorsimuliert wird. Im 2D Berreich ist es sogar etwas einfacher, als bei 3D. Wichtig ist die korrekte Anwendung, weil sonst diese Simulation eher Kopfschmerzen macht, als dass sie Hilft.

      Mit etwas Zeit könnte ich gerne ein Tutorial zu Motion Blur machen, mithilfe von Shadern. Habe schon ganz nette Ergebnisse erzielt.

    • Also gerade bei Spielen, ist Motion Blur so eine Sache. Es gibt Leute, denen wird zb schlecht dabei, wenn sie sich schnell bewegen mit eingeschaltetem Motion Blur Effekt. Ich persönlich mache ihn auch immer aus. Finde ihn einfach in vielen Spielen... nicht angebracht. Fühlt / sieht sich komisch an / aus :)
    • ??? sicher das roomspeed was mit den FPS zu tun hat? Ich meine das ist doch bloß ne art Tick für Objekte - Ich meine das deshalb weil ich einen FPS Zähler hatte und dieser trotz roomspeed Änderung konstant blieb im Bereich bis 60, ich benutze im übrigen gerne nen Roomspeed von 30 und hatte bisher keinerlei Probleme!
    • domis4 schrieb:

      FPS unabhängig und Geschwindigkeiten von Delta abhängig. CSGO Quasi. Aber aufjedenfall >60


      @ domis4: Dass würde ich gerne ausprobieren. Weil dann darf es schon mal FPS-Einbrüche geben aber der SPieler bekommt es nicht mit. Ich weiß allerdings nicht wie man delta_time richtig anwendet. Habe im Netz das gefunden:
      gmc.yoyogames.com/index.php?showtopic=556480
      Hatte das so schon mal in einem Spiel eingebaut doch dann hatte ich Probleme mit den Collisionen wenn die FPS schwankten. WIe muss man da vorgehen? Kannst du das erklären domis4?
    • GML-Quellcode

      1. delta = 60/1000000*delta_time;

      Here is the fun part, it is actually a pretty simple calculation; since delta time is measured in microseconds (1.000.000th of a second),
      we divide our desired standard speed (60fps) by a million, and multiply
      it by the microseconds that have passed since the last frame, for
      example, lets say that 25000Ms have passed since the last step:

      delta = 60/1000000*25000
      delta = 0,00006*25000
      delta = 1.5


      du errechnest am Ende des Step-Events die Deltazeit und rechnest diese auf diverse Spielegeschwindigkeiten drauf:

      GML-Quellcode

      1. speed = 2*delta
      i think, therefore 私 は.
    • @Morpheus ich finde schon, dass man als Spieler auch mit deltaTime die fps-Einbrüche bemerkt, wenn man weiß wie deltaTime funktioniert. Deltatime ist auch viel mehr dafür, dass der zeitliche Spielablauf bei unterschiedlichen fps gleich bleibt.
      Wenn eine Charakter sich mit in 10 Sekunden sagen wir mal 100 Pixel bewegen soll, dann braucht er mit deltaTime auch immer genau 10 Sekunden. Bei niedrigeren fps werden dafür aber weniger zwischenschritte gemacht und bei hohen fps mehr. Somit wirken mehr fps noch immer flussiger.
    • Das Problem bei der verwendung von deltatime ist dass die Spiellogik inkonsistent werden kann.
      Vor allem Kollissionsabfragen, timer als auch die Spielphysik selbst wird dadurch negativ beeinträchtigt.
      (z.B: wenn man jedesmall beim logikupdate prüft ob der Spieler 2 pixel weiter rechts mit einer wand kollidiert. Falls nicht, verschiebt man den spieler 2 pixel weiter. Bei einer lagspike kann aufgrund der delta value der wert auf einmal 20 pixel sein und man überspringt so potenziell ein solides objekt.)

      Bei Spielen wo konsistenz im Spielablauf gefordert ist (u.a. competetive games, CS GO, Trackmania, etc... aber auch Rennspiele im allgemeinem) wird daher (zumindest wenn es um die Physik geht) eine fixierte updaterate verwendet, wobei jegliche Logik die framerateunabhängig arbeiten kann (z.B: das rendering) eben frameunabhängig ausgeführt wird.

      Es gibt da auch einen sehr guten Blogpost auf den (bei solchen fragen) oftmals verwiesen wird:
      Fix your timestep!

      Bei Celaria verwende ich eben dieses genannte verfahren. Die Spiellogik läuft auf einer fixierten updaterate von 60 FPS (ohne delta) während das rendering nicht an die updaterate gebunden ist.
      Falls eine lagspike auftritt, so merkt dies die Spielengine und versucht sozusagen so schnell wie nur möglich die fehlenden logikcyclen bis zum kommenden gerenderten Frame wieder aufzuholen.
      Falls also ruckler auftreten (sei es dass die GPU kurz ausgelastet wird) bricht zwar die framerate ein, die Spielgeschwindichkeit wird aber nicht beeinträchtigt. (Ausser man hat wirklich einen immensen CPU bottleneck.)

      /Edit:
      Um es auch mal in der Praxis zu veranschaulichen: Bei Rennspielen laufen die Physiksimulationen oftmals (augrund der hohen geschwindichkeit der Fahrzeuge und der dafür benötigten Präzision der kalkulation) auf höheren FPS als die eigentliche Framerate. Ich kann mich errinnern eine liste gesehen zu haben die nach einer entwicklerumfrage erstellt wurde wo die Refreshrate der Physikkalkulationen von verschiedensten Rennspielen eingetragen war.
      Die Physik bei Test Drive Unlimited 2 lief auf 60 FPS während die Physik bei Gran Turismo 4 (oder war es Gran Turismo 5?) auf ca. 200 FPS lief. (Forza hatte auch ähnlich hohe Updateraten) Und das natürlich ohne deltatime.

      /Edit2:
      Bei fixer Updaterate ist aber das Problem dass man bei einem CPU bottleneck (vor allem wenn dieser konsistent ist und auch eine lange laufzeit hat) dennoch die Spielgeschwindickeit vermindert falls solche Performanceprobleme zur laufzeit auftreten sollen. (Ihr könnt das Phänomen auch selbst beobachten. Versucht mal ein modernes spiel auf einem alten PC auszuführen der eine alte CPU besitzt. z.B: einem Pentium 4.
      Wenn die FPS in den einstelligen Bereich fällt (aufgrund eines CPU bottlenecks) werdet ihr oftmals auch bemerken können wie die Spielgeschwindichkeit auch runtergeht.

      Aus diesem grund sollte man beim Logikcode schauen dass dieser weitgehend so optimiert ist dass dieser auf durchschnittlichen CPUs problemlos lauffähig ist. (Bei der entwicklung von Spielen für Konsolen ist das kein Problem, da man ja schon weiss mit welcher Hardware man arbeitet.)

      GPU bottlenecks sind generell die mit denen man öfters zu kämpfen hat (und welche im gegensatz zur CPU wesentlich variabler sein können.). Gegen diese Arten von Bottlenecks kann man aber mit dem oben gennanten verfahren vorgehen.

      Dieser Beitrag wurde bereits 10 mal editiert, zuletzt von LEWA ()