Systemvoraussetzungen

[Alrik Alrikson]

Hallo zusammen,

ich habe anhand der Themenüberschriften nichts Passendes finden können, daher wurde meine Frage hoffentlich nicht schon an anderer Stelle behandelt.

Gibt es denn schon Aussagen bezüglich der Minimalvoraussetzungen des PCs für die Schicksalsklinge HD?
Ich selbst habe nie einen "High-End"-PC besessen und auch jetzt nur einen mit Onboardgrafikkarte zur Verfügung und hoffe daher, dass man zur Not die Grafik etc. soweit runterregeln kann, dass das Spiel flüssig spielbar bleibt.

Wenn ich da an die Original-Schicksalsklinge denke und den damals vorhandenen PC, dann war es schon recht nervig wenn z.B. in der Stadt erst nach 1-2 Sek. das nächste Bild "umgeklappt" wurde oder im Kampf die gleiche Zeit verstrich, bis der Angriff dann erfolgte (allerdings hatte ich so genügend Zeit, die farbigen Sternchen mit dem gezeigten Text zu vergleichen ).

Danke und Gruß
Alrik

[Alrik Alrikson]

So, für diejenigen, die es interessiert: hier die minimalen Systemvoraussetzungen laut offizieller Facebooksite.

Zitat:

"Windows XP, Vista, 7 oder 8, Intel Core2Duo /AMD X2 CPU oder besser, min. 2.4 GHZ, 2GB RAM, Geforce
240GT / AMD 3700 oder besser, min. 256MB VRAM, Maus,Tastatur, Sound"

[Ahlon]

Da bin ich gespannt wie es auf meinem Laptop läuft. Bei der Grafikkarte wird es wohl eng. Es ist glaube ich eine gtx9600m. Die CPU hat auch genau 2,4 GHz. RAM ist dafür 4 gb vorhanden.

[Alpha Zen]

Unterstützt das Spiel auch tatsächlich Multicore-Prozessoren? Oder ist es wie bei Drakensang, dass nur einer genutzt wird und man den zweiten haben sollte, damit die Hintergrundprozesse auf den anderen Kern ausweichen können? ^^

[chrisfirefox]

Letzteres. Unity grundsätzlich ist Singlecore, und ich habe ehrlichgesagt keine brauchbare Verwendung für den zweiten Kern gefunden, die KampfKI ist nicht so komplex, als dass sie nicht in ein paar Millisekunden fertig wäre

[Crystal]

Letzteres. Unity grundsätzlich ist Singlecore,

Da fragt man sich als Laie allen Ernstes, für was 4-, 6- und 8-Kerner für Otto Normal gut sein sollen, wenn manche Grafik-Engines den Hardware-Trends immer noch hinterher hinken.
Ich hoffe, dass Unity seine Prozesse auf die GPU auslagert, denn die CPU hat im Hintergrund mit Windows wohl genug zu tun.

[Schamchusai]

Eigentlich sind solche CPUs für Spieler übertrieben, aber wenn man neu kauft, kann man schon zulangen, je nachdem was das Budget hergibt.
Aber einmal nen vernünftiges Board und CPU und man kann dann doch lange nachrüsten.

Ich war auch total überrascht, als ich mir die Tage eine GTX 670 gekauft habe
Ich habe erstmal im Netz gewuselt, ob mein Board und mein mehr als 2 Jahre alter CPU für die Grafikkarte noch ausreichend sind.
Zur Info:

Asus P8P67 Rev. 3.1 / 8GB DDR3 1600 RAM und nen Intel i5 2500k...

Was glaubst du, wie überrascht ich war als das aktuelle Gegenstück von Intel, i5 3570k ist es glaube ich, nur magere 5-7% schneller war, bei ansonsten ähnlicher Systemspezifikation

D.h. im Umkehrschluss für mich, dass meine CPU noch einige Jahre laufen wird und wenn es mal enger wird, dann gehts ans Overclocking, was bei den ix YYYYk-Prozessoren einfach geht, ohne großen Aufwand und das stable!

Das einzige was noch fehlt ist meine Traum SSD, dann ist mein PC perfekt

Gruß

Schamchusai

[Obi-Wahn]

Ja, von der Benutzung von Multicore-Systemen bei Spielen bin ich auch etwas enttäuscht. Eine Frage an die Entwickler: Ist so kompliziert dafür zu programmieren?
Ich möchte Multicore-CPUs nämlich nicht mehr missen. Audio- und Videobearbeitung und Kompilieren geht dadurch deutlich fixer!

[chrisfirefox]

Sagen wirs mal so: Gameengines bzw. Grafikengines sind naturgemäß "nahe an der Hardware". Das hat sich durch die Abstraktion mit DirectX und OpenGL zwar etwas geändert, die richtigen "Experten" auf dem Gebiet, also diejenigen Coder, die das letzte aus einer Engine herausholen, kommen halt sehr oft aus der (nach wie vor existenten ) Demo-Szene, bzw. kommen dann zu einer bereits lange Jahre etablierten Engine dazu, die damals von so jemandem gemacht wurde. Das Multithreading (das man für mehrere CPUs halt braucht) macht nur bei tatsächlich parallelisierbaren oder halt "im Hintergrund laufenden" Tasks überhaupt Sinn, zB wenn man einen Teil der Physik auslagert oder die KI im Hintergrund ablaufen lässt.

Aber nachdem es in der Spieleentwicklung nach wie vor üblich ist, in einem Updateloop zu laufen, weil so neumodisches Zeug wie "Ereignisorientierte Programmierung" (Anm. der Red: wurde in etwa um Windows 3.0 in den frühen 90ern eingeführt) einfach viel zu viel Verwaltung und Performance kostet, ist es halt auch schwer, Aufgaben zu finden, die wirklich parallel ablaufen. Deine Beispiele Obi-Wahn zeigen genau das Problem, die Beschleunigung in der Audio- und Videobearbeitung kommt daher, dass die Aufgaben für die Berechnung "einfach" zu parallelisieren sind, ein Video kannst du problemlos in Keyframes unterteilen, bei Audio (zB bei MP3) gibt es Chunks, die jeweils keine Daten von davor und danach benötigen, und somit "als atomare (im sinne von ungeteilt) Einheit" abgearbeitet werden können. Da machen 8 Kerne natürlich Spaß. Kompilieren ebenso, sobald du einen Abhängigkeitsbaum hast, können die einzelnen Branches natürlich parallel durchgegangen werden, ohne sich "gegenseitig zu behindern".

In den allermeisten Spielen hast du innerhalb des Update-Loops gegenseitige Abhängigkeiten, sodass die Daten aufeinander aufbauen, was Gift für die Parallelisierung ist. Und selbst wenn du Sachen gleichzeitig machen könntest, ist das Debugging paralleler Abläufe von der Komplexität eines Spiels gelinde gesagt *der Horror*. Vielleicht sagt dir der Ausdruck "Race Condition" etwas - ein Fehler tritt auf, wenn Aufgabe A VOR Aufgabe B läuft, nicht jedoch, wenn Aufgabe A NACH Aufgabe B läuft. Sowas zu finden ist ein absoluter Alptraum, weil es die klassischen "Manchmal funktionierts halt nicht"-Fehler sind. Und nachdem Spiele ohnehin schon komplex genug sind und *immer* unter Zeitdruck entstehen, meiden Spieleentwickler das Multithreading wie der Teufel das Weihwasser .

[tommy]

Ja, von der Benutzung von Multicore-Systemen bei Spielen bin ich auch etwas enttäuscht. Eine Frage an die Entwickler: Ist so kompliziert dafür zu programmieren?

nein eigentlich nicht, das problem ist du must 2 eigenständige Prozesse haben, die möglichst unabhängig voneinander agieren können. In den meisten Spielen gibt es kaum Prozesse die so aufwändig sind das die Nutzung eines zweiten Kerns gerechtfertigt ist.
Das einzige was mir dazu einfällt sind große offene Welten mit vielen Creaturen oder shooter mit vielen Teilnehmern, da liese sich die Gegner KI bzw. die Kollisionserkennung in einen eigenen prozess auslagern.

Ich möchte Multicore-CPUs nämlich nicht mehr missen. Audio- und Videobearbeitung und Kompilieren geht dadurch deutlich fixer!

oh ja multicore ist sehr nett für Programmierer und auch für leute die gerne mehrere Programme offen haben unverzichtbar


Übrigens mein intel core i7 (4-kerne und jeder kann 2 threads gleichzeitig bearbeiten) hat einen eingebauten turbomodus, der kann bei bedarf einige der Kerne andersweitig nutzen um die Leistung auch bei normalen Prozessen zu erhöhen.

[cathal]

Also generell ist es mit modernen Entwicklungssystemen (z.B. c# & Dot Net 4.5) sehr einfach mehrere Kerne anzusprechen.

Man muss allerdings auch eine Aufgabe haben die sich parallelisieren lässt.

Bei spielen bieten sich da in der Regel komplexe KI oder Physikberechnungen an.
Manchmal noch komplexes Postprocessing von Bildern.
Bei umfangreichen multiplayer Titeln bietet es sich an die ganze Netzwerkkommunikation von einem extra Kern machen zu lassen um die Latenzen zu minimieren.

Das alles kommt in der Schicksalsklinge aber nicht vor.

Die Grafik berechnet eh die GPU, die CPU schickt hier vereinfacht gesagt nur die Anweisungen was die GPU berechnen soll ab. Der Aufwand dafür hält sich meist in grenzen.

Der Mehraufwand der auch mit modernen Systemen bleibt ist das alles wieder zu synchronisieren.
Wenn man im Singeltread Code einfach x y und z nacheinander berechnet macht man das bei multicore parallel und muss dann aber bevor man dem Spieler eine wie auch immer geartete rückmeldung gibt drauf warten das auch alle fertig sind. Es bringt dem Spieler ja wenig wenn z.B. die GPU das monster schon gezeichnet hat, die Physik dann aber nachher sagt, "nix da, da liegt doch jetzt der dicke Felsen..."

Die von dir genannten Beispiele (ganz besonders die Videobearbeitung) ist für Mehrkern CPUs ideal.
Da muss man ja eh tausende von Einzelbilder berechnen/komprimieren. Das kann man wunderbar parallelisieren indem man jedem Kern ein einzelnes Bild (oder einen Teil davon) gibt und ihn machen lässt. sobald alle Kerne was zu tun haben wartet man bis der erste fertig ist und der bekommt dann das nächste.

Beim Compile ist es auch so, da werden ja in der Regel eine Vielzahl von Dateien und Projektteilen gleichzeitig erstellt und das kann man auch prima verteilen.

[Schamchusai]

Der Turbomodus bei den Intels ist was feines tommy, da hast du recht.
Generell finde ich die i5-Prozessoren (aber nur die Quadcores, nicht Dualcores) recht ergiebig in Sachen Preis/Leistung
Meiner läuft "stock" auf 3,3Ghz und im Turbo auf 3,7Ghz.
Im "Asus optimized modus" sogar auf 3,42Ghz normal und 4,2Ghz im Turbomodus

[cathal]

Reicht eigentlich Intel HD 4000 Grafik?
Ich habe zwar auch ein fettes Gamingnotebook mit Nvidia Karte aber das kleine Ultrabook das ich immer dabei habe hat nur eine Intel HD4000 (Skyrim kann man darauf zumindest mit niedrigen Details spielen)
Der Rest vom Ultrabook (Core i5 Quad 3,2Ghz, 16GB Ram, SSD) sollte ja locker reichen.

[chrisfirefox]

Wenn du dich im Betatest angemeldet hast, kannst du es selber probieren, wir haben da keine Testhardware dafür, wären aber natürlich für jeden Tester, der uns sowas beantworten kann, sehr dankbar. Prinzipiell "gehen" sollte es auf jeden Fall, ob es "läuft" wäre zu probieren .

[Thorium]

Ja, von der Benutzung von Multicore-Systemen bei Spielen bin ich auch etwas enttäuscht. Eine Frage an die Entwickler: Ist so kompliziert dafür zu programmieren?

nein eigentlich nicht, das problem ist du must 2 eigenständige Prozesse haben, die möglichst unabhängig voneinander agieren können.

chrisfirefox hat das schon ganz gut beschrieben. Bei Multicore treten die gleichen Probleme wie bei SIMD auf. Viele aufgaben müssen seriell laufen und lassen sich nicht paralellisieren. Andere können paralell laufen aber der Overhead der Syncronisation macht den Geschwindigkeitsvorteil zunichte. Paralellisierung kann sehr einfach oder sehr komplex sein, das kommt ganz drauf an was man paralelisieren möchte. Bei Spielen lässt sich vorallem die Grafikberechnung paralellisieren. Das kann man aber über die GPU mit ihren unzähligen "Cores" aber viel besser machen. Deswegen wird da nicht die CPU genutzt.

[tommy]

chrisfirefox hat das schon ganz gut beschrieben.

jep das hat er, ich hatte es nur kurz angerissen und als ich fertig war mit schreiben hatte er schon gepostet. ich war da etwas zu langsam^^

[cathal]

Wenn du dich im Betatest angemeldet hast, kannst du es selber probieren, wir haben da keine Testhardware dafür, wären aber natürlich für jeden Tester, der uns sowas beantworten kann, sehr dankbar. Prinzipiell "gehen" sollte es auf jeden Fall, ob es "läuft" wäre zu probieren .

Die Anmeldung hab ich verpasst, aber wenn es noch geht würde ich gerne mitmachen, ich habe jedenfalls einen recht umfangreichen Rechner / Laptop / Tablett Park auf dem ich das testen kann.
Da ich selber Software Architekt bin kann ich denke ich auch Qualifizierte Fehlermeldungen verfassen.