Freeing video memory  

👉 BlitzCoder will be building a new platform and other plans to preserve and continue the Blitz legacy.

To be able to achieve this goal, we need your support by becoming a Patreon Paid Member 👈



Is there a way to free up video memory that's been taken up by textures?

I did some testing on this last week, and I'm currently looking into it on the old forum, but... it seems like one of those longstanding, 'never been solved' kind of problems. Why is it you can so easily recover memory from images and video your program's done with, but textures always seem to take up permanent residence til you quit? No, nevermind why, I just want to know how I can free them, if possible. As a side note, I've noticed there's some kind of system memory takeover that occurs when the video cards memory's all used up, but I'd rather not have to rely on that happening on all computers.

Anyway, like I said, I AM trying to solve this myself, but if someone beats me to it, I won't complain :)

RemiD commented:

there is no reason to do that. Windows OS takes care of managing that.

but if you don't need to read / write on a texture, once you have applied it on a mesh / surface, you can use freetexture( texture ), same thing with images freeimage( image )...

markcwm commented:

Isn't this because your image or video memory uses RAM but your texture memory uses VRAM so is managed differently, less flexibly. I think there's not much you can do except to set your game's minimum VRAM higher.

  fox95871 commented:

I found the solution through testing, and by searching the Nz archive.

4 4096 textures decreases my Vram from 512 to 100. Adding a 5th causes the System ram to take over, however, the Cpu use stays at about 50, and the System ram and Ifps only decrease slightly, just as before, during the initial application of 4096s 1 through 4.

PASSED that point however, continued adding of textures eventually makes the Cpu use 100, and the Ifps 10. So if your game has a zillion textures, don't try to restore Vram exclusively by freeing them when not in use. Instead, delete meshes AND textures, then make new meshes with new textures, midgame. For whatever reason, that seems to be the only way to recover Vram lost to textures. No complaints though, now I can have near ∞ text, music, cutscenes, AND worldmap areas :)

I hope this is helpful to others as well.

fox95871 commented:

I had this wrong. I'll post my corrections soon, but til then don't do what I said to ...good advice in general? XD

I also just want to say, I'm kind of astonished my post here 2 weeks ago was the most recent one in the Blitz3d sections. What's going on here? It's easy to use, Playstation 1 to 2 quality, and in my opinion, games haven't exactly improved with technology, so I don't see why this forum isn't in creative chaos - the good kind - like my computer usually is :)

Anyway no complaints, I'm just surprised. What ELSE would one do but make Blitz3d games?

RemiD commented:

So if your game has a zillion textures, don't try to restore Vram exclusively by freeing them when not in use. Instead, delete meshes AND textures, then make new meshes with new textures, midgame.

this is not a bug, this is totally normal, if you apply a texture on a mesh / surface, and you 'free' the texture, as long as the mesh / surface exists, the texture will stay in the sram (and in the vram if it must be considered for rendering)...

however he meshes / textures are stored in the sram and go in the vram only when considered for rendering (in the camera fov ?). unless you set a texture to stay in the vram by using the flag 256 (when loading one or creating one).
this is useful if you plan to read / write on the texture often.

but there is plenty of sram and vram on recent computers, to not have to think too much about that...

fox95871 commented:

I made a mistake, deleting the texture AND the mesh is unnecessary. It's true I had Vram buildup, but it wasn't because 'textures are stored permanently' or whatever. It's interesting that others have come to the same conclusion though, so for the benefit of anyone else with this problem...

the code notes explain everything. I DO still consider this solved, just don't use what I THOUGHT was the solution in a previous post :)

Reply To Topic (minimum 10 characters)

Please log in to reply