Star Citizen Alpha 2.0 im Technik-Test mit Benchmarks

Ach daher kommen diese lustigen Tricks, die sagen "nimm im Taskamanger bei den Zuweisenungen für SC einen Kern weg, und dann füge ihn wieder hinzu"... Vielleicht hilft das auch bei Dir.
Eventuell liegts an 4 vs. 8 Kernen ...
 
Ach daher kommen diese lustigen Tricks, die sagen "nimm im Taskamanger bei den Zuweisenungen für SC einen Kern weg, und dann füge ihn wieder hinzu"... Vielleicht hilft das auch bei Dir.
Eventuell liegts an 4 vs. 8 Kernen ...
Hab's auch schon mit HT abgeschaltet probiert, es ist im Universe immer das selbe Spiel, dass min. ein Kern 100% durchgehend läuft und das schon im Main-Menü, sieht dann immer so aus:
https://v.theverse.space/bh9uxcjhmpggx/source.jpg
 
hab ich bei SC (außer beim Lade-Screen) noch nie gesehen, und ich schau auch gerne genau hin :-)
Haste das mit der Kern-Zuweisung über den Taskmanager denn schon mal ausprobiert?
 
Naja selbst mit angeschaltetem VSync liegen bei mir die Bildraten bei 25 oder 30-40 FPS (ohne VSync ca. 10 FPS höher). Keine Ahnung warum trotz VSync solche krummen Bildraten rauskommen :ka:

Nennt sich Triple Buffering und ist seit gefühlten 100 Jahren Standard. Guten Morgen. :ugly:

Die festgelegten 60 ODER 30 FPS (ohne zwischenschritte) hat man bei aktivem Vsync nur, wenn Double Buffering aktiv ist.
Beim Triple Buffering ist man natürlich weiterhin auf Frametimes von 30 oder 60 FPS begrenzt (also 16,66 ms oder 33,33 ms) aber um eine bestimmte Framerate zu erreichen, wechselt man einfach die Frametimes schnell zwischen 16,66 ms und 33,33 ms, damit im schnitt dann das rauskommt, was eben geliefert wird.

Und dass man mit Vsync weniger FPS hat, als ohne ist mir neu (bis auf z.B. das 60 FPS cap bei nem 60 Hz Monitor) eigentlich sollte die Framerate identisch bleiben.
 
Falls es jemand noch nicht weiß, man kann auch den Launcher schließen. Der braucht relativ viel Cpu Leistung.

Bei mir läuft es online eigentlich immer relativ flüssig (280x auf hoch), bzw. die niedriegen fps stören mich jetzt nicht direkt. Nur wenn es dann mal kurz einfriert (so 1 sek..) ist bisschen nervig.
 
Laut dem Technical Director von CIG soll man wohl spürbare Vorteile haben wenn man mindestens einen i7 mit Hyperthreading oder einen 6-8 Kern Prozessor nutzt gegenüber einem i5.
Zumindest habe ich das so verstanden laut dem Video hier wo er über die CPU Auslastung auf der Server- und Clientseite spricht.

Twitch

Und hier spricht er über die prozedurale Generierung von Planeten, falls es jemand interressiert.
Im Allgemeinen ist alles was er sagt ziemlich interressant.

Twitch
 
Danke @Phil für diesen fast schon göttlichen Technik-Test! :hail:
Aufnahmen der Benchszene und eine Screenshot-Galerie noch obendrauf, dann hätte es ein wirkliches göttlich gegeben! :D
 
Und dass man mit Vsync weniger FPS hat, als ohne ist mir neu (bis auf z.B. das 60 FPS cap bei nem 60 Hz Monitor) eigentlich sollte die Framerate identisch bleiben.

Beim Rest deines Beitrages stimme ich dir voll zu, aber den zitierten Teil verstehe ich nicht. Nehmen wir mal den Fall eines 60-Hz-Monitors. Und nehmen wir mal an, das Spiel liefert konstant 50 FPS, ohne Schwankungen. Ohne VSync habe ich dann offensichtlich genau 50 FPS. Wenn ich nun VSync einschalte, sind es nur noch 30 FPS.

VSync funktioniert ja intern recht einfach: Wenn ein Bild fertig gezeichnet wurde, wird es erst genau dann angezeigt (bei DirectX realisiert durch D3DDevice->Present() ), wenn der Bildschirm sich das nächste mal in den vertikalen Strahlrücklauf begibt. Während der Wartezeit bis zu diesem Zustand wartet das Spiel darauf. Erst wenn das Warten abgeschlossen ist, und das Bild angezeigt wurde, läuft das Spiel weiter, und beginnt mit der Berechnung des nächsten Frames. Kann man sehr schön mit einem kleinen Direct3D-Testprogramm mal testen, das braucht nicht viele Zeilen Code dafür zu haben :)
 
ich glaube der Kollege hat Double mit Tripple-Buffer verwechselt.
Double-Buffer.
Die Graka hat einen Buffer für das Bild das Ausgegeben wird, und in einem zweiten Buffer wird ein neues Bild berechnet.
Wenn das Bild fertig gerechnet ist wird bei v-sync genau so lange mit dem Umschalten zwischen den Buffern gewartet, bis die Austast-Lücke erreicht wird. Wenn das Bild fertig ist, bevor die Lücke erreicht ist, wartet der Rechner, die Framerate droppt.

Beim Tripple Buffer wird mit drei Buffern gearbeitet (daher auch der Name). Die Graka wartet mit dem Swap von Front und Backbuffer nicht auf die Austastlücke, sondern beginnt sofort den Backbuffer neu zu berechnen. Dadurch fallen die FPS nicht ab. Das Bild aus dem "alten" Backbuffer wird ausgegeben sobald die Austastlücke erreicht wird.

https://de.wikipedia.org/wiki/Dreifachpufferung

Tripple-Buffer wird übrigens von Nvidia seit G80 im Treiber FORCIERT in DX. (Wie lange ist das her? GTX8800?)
D.h. wenn im Spiel keine Möglichkeit vorhanden ist es zu schalten, dann ist es automatisch AKTIV.
Die Einstellmöglichkeit im Treiber ist übrigens nur für OGL. D.h. es hat in Windows praktisch keine Auswirkungen.
Nur falls sich jemand fragt, was da im Treiber für ein Punkt vorhanden ist, und warum nix passiert wenn man daran rumstellt. Gibt nicht so viele OGL-Games.
 
Ja, nach der Demo hat mich die Sim auch überzeugt. Ich hoffe, dass sie in der Kampagne auch faszinierende Phänomene des Universums thematisieren. Glühende Sonnen, Sterngeburten, sterbende Sterne, Schwarze Löcher, Magnetare, kosmische Kollisionen oder den Urknall könnte man ja in die Story verweben, um den Spieler die Wunder des Universums aus nächster Nähe erleben zu lassen. Aber wahrscheinlich wirds das Übliche. Thematisch wird sich nur mit menschlichen Problemen beschäftigt, die am Ende wieder mal mit Gewalt gelöst werden müssen. -.-
 
Beim Rest deines Beitrages stimme ich dir voll zu, aber den zitierten Teil verstehe ich nicht. Nehmen wir mal den Fall eines 60-Hz-Monitors. Und nehmen wir mal an, das Spiel liefert konstant 50 FPS, ohne Schwankungen. Ohne VSync habe ich dann offensichtlich genau 50 FPS. Wenn ich nun VSync einschalte, sind es nur noch 30 FPS.

VSync funktioniert ja intern recht einfach: Wenn ein Bild fertig gezeichnet wurde, wird es erst genau dann angezeigt (bei DirectX realisiert durch D3DDevice->Present() ), wenn der Bildschirm sich das nächste mal in den vertikalen Strahlrücklauf begibt. Während der Wartezeit bis zu diesem Zustand wartet das Spiel darauf. Erst wenn das Warten abgeschlossen ist, und das Bild angezeigt wurde, läuft das Spiel weiter, und beginnt mit der Berechnung des nächsten Frames. Kann man sehr schön mit einem kleinen Direct3D-Testprogramm mal testen, das braucht nicht viele Zeilen Code dafür zu haben :)

Wieso stimmst du mir zu, wen du dann wieder genau das gegenteil (mit dem 30 FPS) schreibst?
Wie das im Detail funktioniert, kann ich nicht sagen. Fakt ist aber, dass sich bei mir die Frameraten nicht verringern, wenn ich Vsync aktiviere, da die GPU mit Triple Buffering nicht mehr auf den Monitor warten muss. Wenn ich ohne Vsync z.B. 50 FPS erreiche, dann erreiche ich die auch mit Vsync. Ich kenne kein Spiel, bei dem das anders ist. :huh:

https://www.youtube.com/watch?v=yqLMQBNmijg
Hier mal ein Beispiel, wie die Frametimes aussehen, wenn man Vsync mit Triple Buffeirng aktiviert. Vieleicht kannst du es dir dann besser vorstellen. Sobald man weniger als 60 FPS erreicht, wechselt die Framtime sehr schnell zwischen 16,66 ms und 33,33 ms. Technisch gesehen hat man also immernoch diesen Einbruch auf 30 FPS, wie vom Double Buffering bekannt, da ein Monitor eben nunmal nur alle 16,66 ms oder wenn die ausgabe zu langsam war, alle 33,33 ms ein neues bild anzeigen kann. Man umgeht das problem aber einfach, indem man Frames mal schneller und mal langsamer ausgibt, um dann innerhalb einer Sekunde im schnitt trotzdem z.B. 45 oder 50 FPS auszugeben. Der dritte Framepuffer ermöglicht genau das.



Ich bin mal so frei und zitiere Wikipedia
https://de.wikipedia.org/wiki/Dreifachpufferung
Durch einen weiteren Backbuffer kann die Bildrate des Monitors von der GPU entkoppelt werden. Wenn ein Bild fertiggestellt ist, muss die GPU nun nicht mehr warten, bis der Swap-Befehl ausgeführt wird, sondern kann direkt im anderen Backbuffer weiterarbeiten. Beim Auftreten des Swap-Befehls werden also die beiden Backbuffer vertauscht, während beim Auftreten von VSync der Frontbuffer und der (letzte) fertig berechnete Backbuffer vertauscht werden. Es kommt also zu keinem Leistungsverlust gegenüber dem ungepufferten Fall.

Vorteile
optimale Bildqualität, da kein Tearing auftritt (grafisches Artefakt, wenn während der Bildausgabe mehrere aufeinander folgende Bilder benutzt werden)
kein Performanceverlust

Nachteile
Der Framebuffer ist um bis zu 50 % größer als bei Doppelpufferung.
geringfügig (maximal um 1 Frame/Sekunde) steigende Latenz
 
Aktuell technisch gesehen grausam und verdirbt einen die Pracht, welche man in den wenigen Sekunden sehen kann. Das mit der CPU Last von 100% auf einem Kern existiert bei mir auch, inklusive der hier beschriebenen Abstürze und Disconnects nach wenigen Minuten. Mal sehen, was sich dann bis Februar des kommenden Jahres so getan hat, da der Launcher mindestens genauso nervig ist und die Internetverbindung quasi lahmlegt (selbst mit config-Änderung hats nichts gebracht; und egal mit welcher Einstellung, er lädt immer die gesamten 30GB runter :wall:). Fehlerreport is scho raus
 
Laut Twitter kommt morgen 2.1 für alle! :O

Mini ptu mit 17 Missionen und dem gesamten stanton System

Das die Dateien nicht ergänzt werden können liegt an der cryengine bzw den packeges, cig will die Archive nicht offen legen und somit muss man jedes geänderte Paket runterladen.
 
Zurück