Bei heutigen Compilern kann nahezu jede Optimierung auf Maschinenebene entfallen (Assembler), da es bereits im Quellcode der Hochsprachen möglich ist, einen Algorithmus so zu formulieren, daß eine Optimierung durch den Compiler nicht mehr durch Assembler-Codierung zu verbessern wäre. Genauso wie es Freeggel.Doe erläuterte.
Und wer es nicht lassen kann, der optimiert dann meistens für ein paar Prozent Geschwindigkeitszuwachs an einer Stelle (sei es nur deshalb, um Zeit für Parameterübergaben zu sparen), wo man an anderer Stelle durch eine Konzeptionsänderung und deren Implementation in einer Hochsprache wie C/C++ locker mal eben 50% Performance gewinnen könnte. Der Aufwand für maschinennahe Programmierung lohnt sich daher in der Regel nicht im Programm oder den dazugehörigen Modulen.
Assemblerprogrammierung beschränkt sich heute vorwiegend auf die Entwicklung von Betriebssystem API's und Treiber für Hardware und Softwareschnittstellen.
Für die Programmierung von Grafik gibt es für Betriebssysteme optimierte Schnittstellen, wie zum Beispiel OPEN GL (für viele Betriebssysteme verfügbar) oder DIRECT X speziell für windows-basierte Betriebssysteme und mittlerweile auch für Linux. Diese haben Schnittstellen zu Hochsprachen und sprechen Ihrerseits wieder die Treiber für die Hardware-Grafik an, an denen sich bereits Experten für die Grafikchips die Zähne dafür ausgebissen haben. Allein auch aus Kompatibilitätsgründen macht es keinen Sinn, hier in Assembler irgendetwas reinzupfuschen. Solche Treiber auf unterster Ebene sind zum Beispiel die Detonator-(Allround)Treiber für Karten der nVidia-Serie.
Es gibt für verschiedene Grafikkarten trotzdem die Möglichkeit, hardwarenahen optimierten Code zur Laufzeit auf die Karte zu laden. Das ist dann aber eine spezielle Codesprache für den Prozessortypen der Grafikkarte. Dieser Code ersetzt dann ggf. fest verdrahtete Routinen auf der Karte. Nur müßte man dann für alle Grafikkarten verschiedener Chipfamilien gesonderten Code entwickeln und testen. Grausam für Entwickler und Kunden zugleich.
Ich vermute mal, Egosoft wird einen Teufel tun und irgendwas in Assembler programmieren, wenn es nicht unbedingt sein muß. So ein Game wie X² ist auch so schon äußerst komplex und will auch noch gewartet werden. Der nächste Patch kommt nach dem ersten Release ganz bestimmt und könnte dazu führen, das einige Programmteile neu geschrieben werden müssten. Wehe, da waren dann auch noch "handverlesene" Assemblercodes drin und halten den ganzen Laden auf... Dann gibt's aber von Cheffe was auf die Rübe wenn nur deswegen der Patch
1. lange auf sich warten ließe
2. oder verbuggter ist, als das Release zuvor
Und das habt Ihr doch wohl bei Egosoft noch nie erlebt - oder?
Gruß
-Octavius-
Less is sometimes more - but sometimes.