spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »"nix da"«

Besseres Filtermanagement,

Ich habe keine Probleme mit D3DXCreateTextureFromFileEx und/oder Setzen des Filters mittels SetSamplerState

Zitat

höherer Lernpegel,

Wenn man Langeweile hat, ja . Wenn nein kann es Sinn machen sich die Zeit völlig zu sparen und was anderes zu machen oder aber nur ein Texturformat zu implementieren z.B. PCX oder TGA. D3DX unterstützt jedoch eine Menge Formate (selbst wenn ich DDS als ein Format rechne), ich finde sechs davon wichtig: .bmp, .dds, .jpg, .png, .ppm, and .tga

Zitat

keine Zusatzlibs, kleinere Dateien,

Mit der Installation der DLLs gibt es mehrere Möglichkeiten. Und je nach dem halte ich kleinere Dateien für ein Gerücht. ich kann mir nicht vortstellen dass eine exe in der Du einen Texturlader implementiert hast kleiner ist als eine die dazu eine DLL aufruft.

Zitat

flexibler,

Ich denke mal in 80% der Fälle reicht die Texturleseroutine von D3DX.

Zitat

erweiterbarer

,

Wenn ich keine Anforderungen jetzt oder in Zukunft in meinem Fall sehe, die D3DXCreateTextureFromFileEx nicht erfüllt, dann werde ich mir keine weiteren Gedanken um Erweiterbarkeit machen. Wenn ich wirklich etwas übersehen haben sollte oder sich eine Anforderung unvorhersehbarerweise ändert, dann schmeiß ich halt die zwei Minuten weg, die ich für die D3DXCreateTextureFromFileEx Lösung gebraucht habe und schreib es mit den neuen Anforderungen im Kopf neu.

Als Hobbyprogrammierer kann man es sich leisten anstatt der besten Lösung eine zu wählen, bei der man sich auf die Brust klopfen kann. Als professioneller Programmierer sollte man ergebnissorientiert arbeiten, d.h. das machen was für die Kunden jetzt und in Zukunft am besten ist und am wenigsten Resourcen (Zeit, Geld) braucht. Und dazu gehört eben auch - und immer mehr übrigens - die Verwendung von Zeit sparenden Bibliotheken.

Apropos, ich habe neulich eine Multi-1000 $ Bibliothek getestet und das mitgelieferte Beispiel was ich mir angesehen habe hat D3DX genommen und das finde ich auch gut so. Und Spiele wie BF2 benutzen es ja auch.

Aber ohne DX wird der Code doch länger.
Ach ja kennt hier jemand ein gutes Buch/Tutorial, das eben genau das Thema behandelt: Weg von DX?

Zitat von »"Fred"«

Ach ja kennt hier jemand ein gutes Buch/Tutorial, das eben genau das Thema behandelt: Weg von DX?

www.opengl.org
weit weg genug?

Soll ich statt D3DX OpenGL verwenden?

Aber mal eine Frage: Schreibt ihr, die ihr nicht mit D3DX programmiert, euch lauter Klassen(praktisch eine eigene Engine), die eben nicht D3DX benutzt?

soviel D3DX benutzt man ja eh nich, nur für Texturen und Effekte, und beides kann man vermeiden

Ja aber der Code wird dann doch einiges länger. Und wenn man eh eine Engine benutzt kann man doch gleich D3DX ausmerzen

So schlecht ist D3DX nicht, meist sind es sogar optimierte Funktionen von Grakaherstellern. Man sollte manche Basics trotzdem beherschen, ob man dann D3DX oder das eigene benutzt ist dann auch wurst.

Im Normalfaall sieht es so aus:

Spiel -> Engine -> Graphikschnittstelle

Die Engine abstrahiert von der Graphikschnittstelle, ob das nun DirectX, OGL oder sonstwas ist (z.B. wäre auch hier WinAPI mgl, aber sehr langsam). Genau das ist Aufgabe einer Engine, zu abstrahieren und sicherzustellen das das Spiel immer die Resourcen hat die es braucht (Alt+Tab). Ich will mich beim Spiel nicht mehr um irgendwelche LoadFile Dinger Kümmern sondern die Resourcen sollen von der Engine verwaltet werden.