Beim Implementieren des *.obj-Datei-Format wollte ich wie gewohnt die Texturen, deren Strings ich zuvor aus einer dazugehörigen Materialdatei ausgelesen habe, laden. Wie gewohnt deswegen, weil es bei allen anderen Dateiformaten(*.x,*.p5m(eigenes Format),*.3ds)
auch funktioniert hat.
Diesmal jedoch werden die Texturen nicht geladen, auch ein Test mit einem ifstream-Objekt, ob die Datei überhaupt besteht, schlägt fehl.
Die Texturen liegen aber zu 100% am richtigen Ort.
Hier der Code(den Test habe ich auskommentiert, da er auch immer falsch ergab):
Code: Alles auswählen
for(DWORD i = 0; i < anz_Tex; i++)
{
ifstream test;
char filename2[512];
sprintf_s(filename2,512,"%s",texNames[i].c_str() );
//test.open(filename2);
//if(test.is_open() == TRUE)
//{
if( (D3DXCreateTextureFromFile( g_graphdevice, filename2,
&textures[i])) < 0)
{
textures[i] = NULL;
sprintf_s(acDebug, 256, "Textur konnte nicht geladen werden! Datei: %s",filename2);
anz_Tex--;
goto e_exit;
}
//}
/*else
{
textures[i] = NULL;
anz_Tex--;
sprintf_s(acDebug, 256, "Texturname konnte nicht gefunden werden!<br>Arbeitspfad: %s Datei: %s",curWD,filename2);
goto e_exit;
}*/
}
In texNames sind alle Strings ordnungsgemäß gespeichert, das habe ich auch schon beim debuggen überprüft.
Das Device g_graphdevice ist auch initialisiert.
Der Speicher für die Texturen auch allokiert.
Der Versuch als Dateiname in die Funktion gleich den c_str() einzusetzen schlug ebenfalls fehl.
Lange Vorrede kurze Frage: Hat jemand eine Ahnung, ob DirektX in dem Zusammenhang den char[512] ablehnt? Wäre WCHAR besser?
Oder sieht jemand vllt. einen ganz anderen Fehler.
Danke im voraus.
Mfg Droven
