-2

I'm having trouble creating a texture which is in my DLL project's directory.

I'm doing

D3DXCreateTextureFromFile(Device, "Sprites/ExpandBlack.png", &BlackTexture);

but that doesn't seem to work. However if I do the whole path like:

D3DXCreateTextureFromFile(Device, "C:\\Users\\Home\\Documents\Visual Studio 2017\\Projects\\NO\\NO\\Sprites\\ExpandBlack.png", &BlackTexture);

it does work.

I also tried doing ../Sprites/ExpandBlack.png, ..\\Sprites\\ExpandBlack.png etc.

Any kind of help is appreciated.

This is where Sprites is located and it has to be "compiled" with the dll.

Image

datboi
  • 198
  • 2
  • 2
  • 9

2 Answers2

1

../Sprites/ExpandBlack.png, ..\\Sprites\\ExpandBlack.png and Sprites/ExpandBlack.png all refer to the same relative path.

Relative paths append to the process's working directory. DLLs use the same working directory.

To get a DLLs path see Get DLL path at runtime

  • Yeah well I am using ManualMapping as injection so I don't think that it's gonna work, however though I got it working by using a `$(SolutionDir)` macro. – datboi Dec 16 '18 at 01:43
1

Relative paths are relative to the current directory of the process. If it works when using a full path but doesn't work when using a relative path then obviously your relative path is not leading to where it should be leading. Most likely because the current directory of the process that's supposed to access that file is not what it should be.

Since we're talking about a DLL here, I suppose the problem is that when running the program that's actually using the DLL, that program is launched from a different location than the one the DLL project file is in. Most likely, because the project is located in a different directory than the DLL project. Visual Studio will by default use the directory in which the project file is located as the working directory for the process. You can change the working directory that Visual Studio will use in the project properties under "Debugging". Most likely, you will want your sprites located relative to the application that's using them rather than some DLL that the application is using. If these sprites are actually tied to the library and required by the library to function, on the other hand, then you may want to consider embedding the files into the library, e.g., as resources, or at least place these files relative to the library and access them based on the location of the DLL and not the current directory of the process that's using the DLL. To get the path of your DLL, see the answer linked in user2176127's answer…

Michael Kenzel
  • 15,508
  • 2
  • 30
  • 39