Textures not really freed?
Blitz3D Forums/Blitz3D Programming/Textures not really freed?
| ||
| I think textures in Blitz3D are not really freed when you do a FreeTexture, or when you FreeEntity an entity with a particular texture. The reason I think this is because I am trying to reload and re-apply textures with the same filename, and nothing happens. What I'm trying to do is create a simply 3D viewer program to view my texture maps on an entity. I want to modify the texture file, then click a button on the 3D viewer to reload the same texture with the updated image, but nothing happens. It seems like Blitz3D thinks "I already have a texture with that filename in memory, so just use it instead of actually reloading it again." Has anybody figured out how to get around this? |
| ||
| You could always load a dummy file first, and then the updated version. |
| ||
| Tried that, doesn't matter if I free it, load a different texture, free that, then load the first texture again. The first texture stays the same, even if the file has been updated. |
| ||
| Assuming the texture is not applied to any active entities ( which will keep the texture in video ram ) you can just renderworld ( and possibly flip - can't remember ) and it will be flushed from video memory as Blitz then seems to detect that it's no longer required. |
| ||
| The space that was used for the texture is no longer locked. The texture data is still there and even the handle still may be used, although it will be removed or overwritten when blitz performs the next garbage collection. I don't know exactly when it's gonna do that, every Renderworld() as Sybixsus said, or only from time to time, or when new memory is allocated. Fact is a texture that was freed is no longer accessable _securely_ cause it's RAM will be recycled soonish. Therefore I'd reccomend if you remove a texture, always set its handle to zero at the same time, this way you will always be able to check if a texture exists or not. |
| ||
| I think you may have the same problem I had: I wanted to change a named texture on a model, as I was editing it, to see the differences. It seemed as if the graphics card was saying 'No, I've already got that (named) texture in memory, I won't actually reload it.' - but no error in Blitz. The only answer was: a) To load a texture of a different name (obviously), or b) Erase the model, and reload using the newly changed (but same name texture). I wrote my own model viewer, and had to end up using method b) - it was the only way to be sure. |
| ||
| (now I realize I misunderstood your question before. Sorry, I should read more carefully :) ) You are referring to memory usage optimation that is perfomed automaticly. When you load a texture twice with the same settings and everything, blitz thinks it's better to reuse the one it already loaded before. Blitz doens't recognize if the texture file was edited. BTW there are further ways to solve this: Situation A: You are loading a texture several times and write, say, a teamplayer number onto each texturebuffer, then assign the texture to one of the teams players. You'll notice that in the end each team player has all numbers on his texture. Solution: Load the basic texture, then create each player texture using the CreateTexture Command, then CopyRect the basic texture to the players individual textures and then draw their numbers on their textures. Situation B: You have loaded and assigned a Texture to a model, then you overwrite the texture file with a new texture. When you try to reload it, Blitz thinks it does not have to reload it since it's already loaded, and Blitz tries to utilize this (usually very smart) optimation based on recycling (or more exact:instancing). Solution: Load the texture, create a blank texture of the same size, CopyRect the texture to the created Buffer and then use that buffer, finally Free the original Texture, so when you instruct Blitz the next time to load it, it actually WILL reload it since the texture officially doesn't exist in memory. |
   |