GRAKA0815 schrieb:
Das Carmack das gemacht hat (es dürfte wohl eine "rühmliche" Ausnahme gewesen sein) mag man ihm ja anrechnen, ist aber definitiv nicht standard. Um wieviel wäre dann die FX-Reihe in dem Spiel abgekackt ohne den FX-Pfad? Bei wievielen Spielen finden wir denn einen expliziten FX-Pfad? Carmack konnte es sich doch gar nicht leisten "ohne" NV Optimierung, denn immerhin war Nvidia Sponsor / Finanzgeber etc.
Ein Konsolen Spiel hat sicherlich nicht viel weniger Entwicklungszeit als ein PC-Spiel.
Nur, wenn heute jemand beginnt ein Spiel für bsw. die XBox2 zu programmieren, dann hat er seine
feste linke und rechte Grenze was die Ressourcen angeht. Ein PC-Spieleprogrammierer aber nicht! Das grobe Klotz an PC-Spielen ist doch, dass die Ressorcen verschwendet werden ^3. Das ist aber bei einem Konsolenspiel eben nicht möglich. Hier
muss einfach das Optimum an Leistung
und Bildqualität programmiert werden. Dies ist ja auch einfacher, weil ich nur eine einzige Grafikkarte zu bedienen brauche.
Nimm doch einmal Doom3 als bsp. Was für eine Hardwarevoraussetzung muß ich mitbringen, um dieses Spiel in der bestmöglichen Auflösung und unter allen umständen flüssig zu zocken? Ein Konsolenspiel habe ich noch nie ruckeln gesehn, aber schon viele PC-Spiele.
Wie hatte es den am Anfang mit Far Cry ausgesehen? Schau Dir doch einmal die unzähligen Thread hier im Forum an, weil trotz guter Hardware das Spiel teilweise unspielbar gewesen ist.
Ein PC-Spiel ist immer ein Balanceakt zwischen Intel / AMD / Nvidia / ATI und auch noch den anderen gegenüber. Da mag es phasenweise Optimierungen geben, aber die können aus kompatibilitätsgründen nie so stark sein wie bei einem Konsolenspiel.
Wie gesagt die Unmengen an Texturdaten die bei PC-Spielen anfallen sind enorm im Vergleich zu dem was auf einer Konsole verarbeitet wird, das ist ja auch nicht verkehrt, weil der Konsolenmarkt nichts anderes erwartet.
wichtigster Satz dieses Beitrags:
Schau dir mal an auf welchen Grafikkarten du Doom3 noch mit minimaler Texturqualität, aber eingeschaltetem Normal-Mapping spielen kannst, denn wie von Geisterhand passen bei der X-Box-Fassung keine Texturen in deren Viodeospeicher die gröszer als der Videospeicher der X-Box sind (die X-Box hat nur 64 MB Hauptspeicher, da wird der Videospeicher ja kaum gröszer sein), also können auch nicht die auf dem PC üblichen Texturen berechnet werden, technisch unmöglich sozusagen.
Konsolenspieler haben einfach keinen Blick für Levelgrafik, Sichtweite, Texturqualität und solchen Krempel und deshalb wird einiges auch überbewertet. Dass man auf dem PC für die gleichen Dinge eine doppelt so schnelle CPU braucht ist eine andere Sache und wenn man bedenkt, dass immernoch eine ganze Menge allein bei der Grafikengine von Spielen durch die CPU muss und Schatten und sowas bei den meisten Spielen (auch bei Doom3) trotz Nvidias "Ultra-Shadow" immernoch von der CPU berechnet werden, dann dürfte auch deutlich werden, warum zB. Schatten auf der Low-Tech einer Konsole so performant sind.
Meist sind durch die Standards die Chipentwickler freiwillig bereit für Standard-Rasterizer+Shader-x.x zu optimieren, gröszere Unterschiede entstehen nur wie zB. beim GeforceFX, wenn ein Chipentwickler einen zukünftigen, noch nicht vorhandenen Standard falsch erwartet, Nvidia glaubte tatsächlich mit dem FX später Shader 3.0 kompatibel zu sein, der Griff in die Zukunft ging halt deutlich daneben, der wichtigste Unterschied der FX-Shaderarchitektur gegenüber 2.0 ist aber der gleiche wie der von 3.0, man kann die gleichen Sachen deutlich performanter berechnen und braucht deswegen für gleiche Geschwindigkeit weniger "Rohleistung" oder auch weniger Shadereinheiten, was letztlich beim NV30 auch vorliegt, er hat weniger Shadereinheiten als seine Konkurrenz. Unterschiede in der Architektur die in unterschiedlicher Performance resultieren sind nur unterschiedliche Ansätze den gleichen Code besser verarbeiten zu wollen. Der Hardwarehersteller versucht den Code, der durch dei Standards festgelegt ist, optimal zu berechnen, wenn alles so läuft wie es vorgesehen ist braucht der Spieleentwickler eben auch nichts optimieren.
Ist quasi wie mit Webbrowsern und dem Rendern von Webseiten, Gecko (Mozilla) rendert auch nicht perfekt, hat aber auch andere Ansätze eine absolut standardkonforme Webseite effektiv, korrekt und möglichst schnell zu rendern als Opera, Gecko und Opera unterscheiden sich schon stark, mit einer 100% W3C konformen Webseite erziehlt man aber kaum schlechtere Performance, als wenn man irgendwas "optimieren" würde. (den IE mal nicht berücksichtigt)
Für verschiedene CPU-Architekturen optimieren ist auch nicht so schwer, ich habe damit zwar noch keine extrem spürbaren Resultate erzielen können, man kann aber sicher seinen Systemkernel auf das was man im Rechner hat einstellen, bei mir wäre das "K7" und dann die Software dafür kompilieren, fertig ists. Der Spielehersteller könnte gleich mehrere Binarys in den wichtigsten Architekturen anbieten. Aber wie gesagt ich spüre da kaum Unterschiede. In der Regel erkennt gröszere, aktuelle Software (zB. Videoprogramme oder 3D-Anwendungen) die CPU-Architektur sowieso automatisch und stellt sich darauf ein, sodass ein Binary des Programms, welches an ein bestimmtes System angepasst ist auch nur die Zeit spart, die das Programm sonst damit verbringen würde die CPU-Architektur zu erkennen.
Das Anbieten von mehreren Binaries ist übrigens bei Spielen nicht wirklich tragisch, meine Morrowind.exe hat zB. nur 3,78 MB, während das Spiel insgesamt eine CD fast randvoll füllt und ich sogar noch zwei AddOns installiert habe. Aber wie gesagt ist das mit mehreren Binaries nicht notwendig, weil das Spiel beim Programmstart darauf einstellt, es stellt sich auf das ein was das System sagt.
Eigentlich sind nur Befehlssätze wirklich bedeutsam die man beim Programmieren berücksichtigen müsste, aber wenn man da als Spieleentwickler SSE2 nimmt ist man aktuell bei allen x86-CPUs gern gesehen, wenn man will kann man darüberhinaus auch noch was für 3DNow+ und SSE3 schreiben, wäre eine spezielle "Anpassung", das muss man aber nicht und macht auch kaum jemand.
Der Mac steht eben nicht besser da als x86-Systeme nur weil er eine einzige CPU-Architektur hat (aktuell G5), sondern weil sein Erweiterter Befehlssatz einiges ganz gut beschleunigen kann, wenn er genutzt wird. Inwiefern
RISC mit seiner Performance etwas zu tun hat weisz ich nicht, die grosze Befehlssatzerweiterung hat jedenfalls mit
RISC nicht viel zu tun.
ps.
Puhh, für Wochentag und Uhrzeit war das jetzt ganz schön anstrengend.
