Jump to content

  • Log In with Google      Sign In   
  • Create Account


Managed pool residual memory?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 CulDeVu   Members   -  Reputation: 580

Like
0Likes
Like

Posted 30 March 2013 - 01:30 PM

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!


I'm sorry about any spelling or grammar mistakes or any undue brevity, as I'm most likely typing on my phone :P

Sponsor:

#2 Juliean   GDNet+   -  Reputation: 2438

Like
0Likes
Like

Posted 30 March 2013 - 02:03 PM

Does this problem persist if you restart the PC?



#3 irreversible   Crossbones+   -  Reputation: 1307

Like
0Likes
Like

Posted 30 March 2013 - 09:49 PM

Could be related to this - restarting as The King suggested is a good place to start.



#4 mhagain   Crossbones+   -  Reputation: 7833

Like
0Likes
Like

Posted 31 March 2013 - 10:26 AM

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.


Edited by mhagain, 31 March 2013 - 10:27 AM.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#5 CulDeVu   Members   -  Reputation: 580

Like
0Likes
Like

Posted 01 April 2013 - 08:50 AM

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 smile.png

Edited by CulDeVu, 01 April 2013 - 10:28 AM.

I'm sorry about any spelling or grammar mistakes or any undue brevity, as I'm most likely typing on my phone :P




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS