Will EndGraphics free all images?
BlitzPlus Forums/BlitzPlus Programming/Will EndGraphics free all images?
| ||
| I need to free all the images in my game at certain points, and I reckon it would be easier to just clear all the graphics using a single command rather than writing FreeImage for every single image I've loaded. Would EndGraphics work, or is there another command, or some code that would let me select each graphic in turn and free it, eg. in a For-Next loop? I'm using Blitz Basic 2D. Thanks in advance! |
| ||
| Yes, EndGraphics will do it. It won't free sound effects though. The downside is that the resolution change will look very untidy. You'll get better results if you keep track of what's loaded and free it all manually. |
| ||
| Also, while this will free all graphics in Blitz Basic (2d) and Blitz3D, it won't work for all images in BlitzPlus. this is because you can load some images to video mem and some to system mem in Blitz+, and only the video memory ones get cleaned out on a graphics mode change. Of course, that may be irrelevant to you dependent on what version of Blitz you're using now - although you might want to keep your code future-proofed in case you do upgrade. |
| ||
| Is there an alternative? For example, would I be able to select each image in a For-Next loop and delete them from there? |
| ||
| You could create a function called MyLoadImage, which as well as loading the image and returning it from the function creates an instance of a type that also references that image. Then you could loop through all instances of that type and free the images when you need to clear everything out. However, as GFK implied, you'd be far better off keeping track of what you have and haven't got loaded, freeing it as soon as you can and doing everything manually. It sounds like a lot of work, but if you start out doing this, your app will be better for it (in the least it will use the minimum of memory). |
| ||
Is there a reason why you don't put all the images to be freed in a functionfunction FreeSpecificImages() freeimage firstimage freeimage secondimage end function and call it when necessary? |
| ||
| I could, but I have a lot of images to free, which means a lot of typing by me. I also need to free a lot of images all at once, as all of them are called up before each level, depending on whether I need them for that level or not. I don't want to load and delete them in the middle of the level. |
| ||
| For those who haven't learned the hard way, remember to free images correctly... Call: gfx_image=Func_SafeFreeImage(gfx_image) Function: Function Func_SafeFreeImage(image) If image<>0 Then FreeImage image Return 0 End Function |
| ||
| What do you mean 'learn the hard way'? I obviously haven't encountered the incendent that allows me to learn, but could you enlighten me as to what it is, before I do anything damaging? |
| ||
| Presumably freeing an image that's already been freed. |
| ||
What he means is that when you free an image, the image handle is still retained in the variable, so:image% = LoadImage("myimage.jpg")
Print image%
FreeImage image
Print image%
WaitKey
EndWould show 248563942 etc... 248563942 |
| ||
| btw doesnt BB include Garbage Collection??? |
| ||
| Right... but is EndGraphics SAFE? I don't want to mess up my sytem/program/graphics/whatever, and I get the feeling that Ghoula was saying that EndGraphics is prone to doing this. |
| ||
| What do you mean 'learn the hard way'? Exactly what Gfk said. Simply calling freeimage by itself will not free the image handle, you should zero that manually. I learned the hard way because i was not doing this when i first started with blitz. After my program ran for awahile images started becoming corrupt and bizarre looking. So i had to go through a ton of code to correct my error, pain in the arse it was :) As for using EndGraphics() i personally have never had a need to use it. But i did do a test: I Loaded up an image into gfx_image then called EndGraphics() then printed gfx_image... the image handle was still being retained. Given the above i don't think EndGraphics() will do exactly what you are looking for. You would still need to set all your image handles to zero/null manually to be sure no weirdness happens after the prgram runs awhile. |
| ||
| Function Func_SafeFreeImage(image) If image<>0 Then FreeImage image Return 0 End Function This would return 0 regardless with the freeimage was successful. Is this right? |
| ||
| Function Func_SafeFreeImage(image) If image<>0 Then FreeImage image Return 0 End Function This would return 0 regardless with the freeimage was successful. Is this right? Yes, it will always return zero because the safefreeimage WILL ALWAYS be successful. Either the image exists and is freed or the the image doesn't exist(and is thereby already freed). |
| ||
| btw the handle would be retained because it the handle just points to the data, i.e. the handle could still be <>0 but the image could be freed |
| ||
| Does this hold true with FreeEntity(), FreeTexture(), etc. as well? |
| ||
| Right. That's okay. I was worried that I might do something wrong. Thanks for the details. |
| ||
| Does this hold true with FreeEntity(), FreeTexture(), etc. as well? Yes it does. When you free a handle be it an image or sound it frees the memory that was allocated to it, but the handle is still pointing to that specific area in memory where it was stored. To avoid problems, that alone is not good enough. You should manaully 'zero/null' the handle you are trying to free as a safe gaurd, like in the small function above. I personally use basically the same function for a the similiar things like: images/textures/sounds/entities etc... I have like a SafeFreeEeenity(), SafeFreeImage(), SafeFreeSound() and so on. This is good programming practice and could save you a heap o' grief down the road, especially if you have a large prog that does a lot of loading and unloading of images/textures and what-nots. Cheers! |
   |