Thanks for the replies. Yep, this is just for a tool / my own education, so I don't mind the extra processing step.
@MJP - Yea that's what I thought too, but the channels are switched. So I'll need to switch them.
So from doing some reading and testing, looks like the best option is read the data from the file into a buffer, create my texture, lock the rect and then switch the channels as needed. I can't seem to find anything here or on Google that suggests a better way.
It produces the correct texture data and it's not too slow. Is there a better way?
When I say non standard I mean that it's not in the D3DFORMAT enum, so I can create a texture in that format and then memcpy the data in.
So for example one of the formats the game stores it's files in is ABGR8888. In the D3DFORMAT enum there is D3DFMT_A8R8G8B8.
So would the best way to read this texture in be to create a D3DFMT_A8R8G8B8 texture, lock the texture and manually copy in each pixel of data? Or is there a better / faster way to go from one format to another?
Hope that makes it easier to understand my question.
You can do it however you want, using whatever library you want. GDI+ can do it very easily, or you can use ImageMagick, or you can use D3DX helper functions. You can use D3DXCreateTextureFromFileEx and specify the thumbnail size and it will scale it down for you, or you can use D3DXLoadSurfaceFromSurface to scale down an existing texture. Or if you generated mipmaps for your texture, you can just grab the surface from a lower mip level and use D3DXSaveSurfaceToFile.
Thanks, I'll check those functions out and see if I can get something working.
Update: Both methods worked perfectly. I went with D3DXLoadSurfaceFromSurface in the end. Thanks again for the help.