spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hi Leute,

ich lese zwar überall,dass die D3Dx9 Routinen so langsam sind, ich finde aber nirgends einen Ansatz zu der "schnelleren" Variante.

LPDIRECT3DTEXTURE9 ist ja denke ich bei beiden gleich.
Aber was macht die "schnelle" Variante besser?
Die Lese/schreibzugriffe werden doch so oder so quasi über den selber C++ code erledigt...
Was soll den Performance bringen? Das ich die Header überspringe, da ich ja schon weiß wie die Dateien aufgebaut sind und ich direkt anfangen kann die Daten zu laden? Gibts sonst noch n Vorteil?
Wenn ich eine 256 Bitmap laden will, mach ich das dann mit nem 256x256x3Word großen Array, bei dem ich bei bmps den Header überspringe und die Zeilen vom Array von hinten nach vorne adressiere?

Und vor allem:
Mit welchem Befehl kopiere ich die Daten in den Texturespeicher?

Sorry Leute für so ein Ge'Noob'e, aber ich steh im Mom. wirklich etwas auf dem Schlauch.

Ich suche halt die Stelle, an der man beschleunigen kann...
Sinn und Zweck: Mir einen Optimierungsdeckel machen, wenn nachher Speed fehlt und ich die andere Variante rausschmeißen will. Das Langsamste sind halt immer noch die Festplattenzugriffe (und auch das was sich Performancemäßig am wenigsten über die Jahre verändert hat).
Da mein Spielekonzept eine großes "Level" vorsieht, also keine Zwischenladescreens werd ich natürlich versuchen möglich viel bei Programmstart in den RAM zu laden und in ruhigen Zeiten per Thread Chunkweise mögliche Zukünftige Bereiche bereits vorzuladen, damit nachher nur aus dem RAM in die Karte geschoben werden muß, aber kritisch wird da jeder Ladekram wahrscheinlich immer noch werden.

Lösungsansätze:
Also wenn man die Dateiendung mit dem Fileformat koppelt, dann würde mir spontan einfallen, was ich da machen könnte:

filename.XYZ

Buchstabe X wird ersetzt durch Bezeichner für 16er Potenz der Auflösung
A = 16, B= 32, C=64, D=128, E=256, F=512....
Und Y stellt die Bitrate da
A = 16 mit 5.6.5, B= A1.5.5.5 etc...

So kann ich mir einladen und auswerten des Headers zur Laufzeit sparen, damit das Laden des Header auch und die Bilddatei als PlainData speichern, da der Header vorher rausgenommen werden kann. Im Vergleich zur Bitmap kann ich auch im Vorfeld die Daten schon drehen, da ne BMP ja upside down gespeichert wird und damit die eingelesenen Daten direkt verarbeiten ohne vorher drehen zu müssen. Damit wären alle Formatfragen schon beim aufrufen der Funktion/Member geklärt, da außer einem Len und dem Angeben von
loadtexture(filename, filename[len -3], filename[len -2]) und einem Switch in der Funktion nix gerechnet werden muß (der Rest besteht dann aus reinen Lade- und Zuweisungsoperationen.

Es mit InlineASM auf die Spitze zu treiben hatte ich allerdings nicht vor