spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Johannes Schneider«

In dem Buch welches ich lese wird Assembler als "Allheilmittel in Sachen Geschwindigkeitsoptimierung" angepriesen - Kein Vergleich zu Win32 Anwendungen...

Dann solltest du das Buch besser wegwerfen, das ist nämlich absoluter Schwachsinn (abgesehen davon dass man Win32 Anwendungen in allen möglichen Sprachen, Assembler inklusive, schreiben kann).

Zum Thema Geschwindigkeit:
Wenn man sich auskennt kann man schon mit Assembler deutlich höhere Geschwindigkeiten erzielen. Das bezieht sich aber zum großen Teil aber auf den Einsatz von MMX und SSE, und macht auch nur Sinn wenn man Funktionen hat, die sehr oft aufgerufen werden, und die auf mehreren Daten gleichzeitig arbeiten. Bild- und Videobearbeitung sind da Paradebeispiele für. Aber auch bei Spielen wird es eingesetzt, z.B. bei Matrixoperationen.

Zum Thema Unter schied x86 / AMD64:
Vom Befehlssatz her sind die Unterschiede zwischen 32 und 64 Bit schon recht gering. Aber manchmal sorgen kleine Änderungen wie Registerzahl und Größe für ein anderes Vorgehen. Bei vielen Registern macht es z.B. deutlich weniger Sinn Funktionsparameter über den Stack zu übergeben, da viel öfter alle Parameter in Register passen. Altes Wissen wird dadurch aber nicht unbrauchbar, man muss nur bei manchen Konventionen aufpassen, ob diese noch gelten.

Das mit den deutlich höheren Geschwindigkeiten kann man so pauschal absolut nicht sagen. Und für SSE verwendet man besser einfach Intrinsics. Das funktioniert dann auch mit x64 und zwingt den Compiler nicht dazu den Optimizer abzuschalten.

Zitat von »dot«

Und für SSE verwendet man besser einfach Intrinsics. Das funktioniert dann auch mit x64 und zwingt den Compiler nicht dazu den Optimizer abzuschalten.

Oh, ich wusste gar nicht das damit sämtliche Befehle abgedeckt werden, und vor allem nicht das der gcc das auch kann

Dann fällt mir aus Geschwindigkeitsgründen nix mehr für Assembler ein, wo es wirklich etwas ausmachen würde. Wenn der Compiler nicht gerade totalen Mist baut (was eher selten vorkommt) ist die Lösung auch oftmals besser als eine Handgeschriebene.

Moderne C++ Compiler sollten sogar nicht nur oft sondern eigentlich fast immer besser oder zumindest praktisch gleich gut wie eine in asm handgecodete Lösung sein, außer vielleicht wenn ein absoluter asm Guru dran war und natürlich unter der Voraussetzung dass der C++ Code gut ist. Selbst der Guru kann nicht von Haus aus was rausholen wo es nichts zu holen gibt. Asm zur Optimierung macht dann Sinn wenn es erstens mal wirklich ein Performanceproblem gibt, zweitens anderwertig nichtsmehr rauszuholen ist und man drittens entsprechend viel Ahnung hat.

Um vielleicht nochmal zum Thema Assembler-IDE zu kommen. Die Inventor-IDE (geschrieben in Java) habe ich letzten Sommer entdeckt. Der Autor hat außerdem einige Videotutorials auf ShowMeDo zum Thema Assembler.

Danke übrigens für die Antwort wegen DX 10/11 und nochmal ne kleine Frage:

Lohnt es sich, wenn man auf DX 11 umsteigen will (von DX 9) extra ein Buch zu kaufen?
Ist mit Fixed Function Pipeline eigentlich die Transformationspipeline gemeint? Wenn ja, kenne ich mich damit aus!

MFG Harry222

Ob es sich lohnt ein Buch zu kaufen, weiß ich nicht. Aber ich bin auch dabei von DirectX 9 auf 11 umgestiegen und hab mir auch kein Buch gekauft. Du kannst dir mal die Doku von DirectX 11 durchlesen, im aktuellen SDK sind auch ein paar Tutorials dabei, dann siehst du schon was anders so DirectX 9 ist. Ich glaube so Zeit gibt es auch noch kein gutes Buch für DirectX 11.
Die Fixed Function Pipeline macht mehr, als die Verteizes zu transformieren. Lichtberechnungen werden ausgeführt, wie die Pixel von Texturen auf die Vertizes kommen.

Doku*
Und es kommen keine Pixel von Texturen auf Vertices Es kommen Texel aus Texturen auf Pixel im Buffer. Und natürlich macht die FFP noch mehr als das... Z-Buffering, Transparenzen, etc, etc.