Does D3DXLoadMeshFromX() (or any other function) return an error code? You're not using the FAILED() macro in your snippet - you really should use it or something similar [smile]

D3DX is pretty good at giving a reason as to why a function fails - if its a unicode error then chances are it'll report back an invalid filename. It should also quote the filename it received - so you can manually check if its the intended file.

Quote:In the debug window i have the notation "D3DX: Unicode support: 1", so it's certainly means my mesh name don't respect the unicode form. it's curious !!!

I dont think you're interpretting that output correctly - that message should mean that unicode IS supported and that D3DX is operating in unicode mode. Older D3DX and/or older OS's (e.g. some Win9x's) didn't always run in unicode.

hth
Jack

DX and UNICODE don't play well together. Althought they have different W/A version of some of the D3DX functions, the texture file name stored in the .x file material template is defined as char*. And in your case, the file name is already in char* format? So why not just stick the A on the end and use the non-UNICODE version: D3DXLoadMeshFromXA(....)? Then when loading the textures, you don't have to convert the file names to UNICODE and can call D3DXCreateTextureFromFileA to load them.

If on the other hand, your file names are coming from an OpenFile dialog or you want to change/add the path for the texture file names, working in UNICODE and converting the texture file names from the material might be easier.

I gave up on UNICODE and DirectX when I saw that they don't completely support it in all of their interfaces. How would a Chinese developer save a texture file in his language and use it in a .x file, since the material only supports a char*? He would have to ensure that the UNICODE filename could be converted to and from the multibyte format, or he would never find the file after converting it from multibyte to UNICODE. Not all UNICODE characters map to multibyte ones.