Hello, all.

It's been a while since I posted. I've mostly been lurking around on the forums, but this problem is really unusual. I've searched around and it seems no one else seems to have ever had this problem.

So here it is:

I'm using D3DXCreateTextureFromFile to load textures into my program. I was working on the art assets, having been just using simplistic placeholder art until I could get a code base content up running. So I updated the character I was working on and fired up the game, but the character was unchanged. From there, I tried everything: renaming, recompiling, replacing. The character never changed.

I know this much:

- The image is being changed, as I can see it in the windows explorer window

- The image I'm modifying is the one being accessed, because when I remove it, D3DXCreateTextureFromFile failes

- It isn't just this one image, it's the same with all my art assets

- It's not a problem of over-writing, because when I 'Save As' a new name, the image is still an old copy of the image

- It's not a problem with layers: the image is a .png

What else could it be? The only problem I can think of is that it's an issue with residual memory in the Managed Pool. Could I not be freeing the textures correctly before I exit the program, with DirectX9 grabbing them when I run my program again a few minutes later? Or is it a known problem with Windows 8? I haven't gotten a chance to fiddle with it on Windows 7 yet, but hopefully I'll get the chance to in a few days.

Thanks in advance for your help!

99% of the time when someone thinks they have found an API bug it's actually a problem in their own code. I've never seen the managed pool behave like this, and nor is it a documented behaviour, so the extremely strong probability is that your own code is still loading the wrong texture; I'd encourage you to review this part of it again and confirm that your D3DXCreateTexture call is using the right file, that you're not picking up the wrong one from a bad path somewhere (e.g. the default exe path if running a debug build), and possibly even copying off your exe and assets to another machine to be extra certain (the CreateTexture call should fail if it's trying to load from a file that doesn't exist).

On the other hand, if you do have a driver bug, see here for one possible approach: http://msdn.microsoft.com/en-us/library/windows/desktop/ee418784%28v=vs.85%29.aspx#driver-managed_resources - it may be worth setting D3DCREATE_DISABLE_DRIVER_MANAGEMENT in your CreateDevice call to sidestep this behaviour if your driver exposes this cap.

Thanks for all of your help, but I think I found the issue.

I've never seen the managed pool behave like this, and nor is it a documented behaviour, so the extremely strong probability is that your own code is still loading the wrong texture

Restarting wasn't the problem, nor was a error of mine or my video driver. I believe it's an issue with D3DXCreateTextureFromFile getting along with Paint.net.

What I think is going on here is that Paint.net's eraser tool only writes over the transparency bit, but doesn't clear the color bits.This was the effect that I was seeing when I erased part of the .png but it still showed up in my program. I might be wrong, but I don't believe D3DXCreateTextureFromFile supports partial transparency, so when it saw the old color bits but with full transparency the function interpreted it as partial transparency, and loaded in a totally opaque pixel where I had just erased it.

My lesson learned: always store my palette on a separate layer.

Thanks for the help again! Much appreciated, as always