_FREEIMAGE Behavior

[TerryRitchie]

I just ran across something that I did not either realize or should not be happening.

When an image is freed using _FREEIMAGE the associated variable is not reset to zero but instead retains the negative value of the image assigned. Is this normal behavior?

Code: (Select All)

image1 = _NEWIMAGE(100, 100, 32)
image2 = _COPYIMAGE(image1)

PRINT image1, image2
_FREEIMAGE image2
PRINT image1, image2
_FREEIMAGE image1
PRINT image1, image2

The code above shows that when images are freed the associated variable retains the image value. I would expect the variable to be reset to zero along with the image being removed from memory.

Is this correct?

[MasterGy]

it's a bit like that, maybe it's a bad example, but I could compare it to this. I will give you a note on which is written what to bring from the store (index note). Once you have brought the goods from the store, the paper is irrelevant from then on. no one will cross the line. It stays. The advantage is that it remains in case you want to look at what you had to buy later. why should the note be crossed out?

[SMcNeill]

It's normal behavior, and it's always been that way for us.

I believe the main issue one might run into would be with something like the following:

_FreeImage Foo
_PutImage ,Foo

Now, with the above, you're going to get an error message saying, "You're a dummy!  You just freed that image!!"

If the value was set to 0, then that's basically saying, "Put the Image(0) to...."

And, as we all know, Image(0) tends to default to the current _DISPLAY or the _DEST, in most cases...  Which probably isn't what you actually want to happen here. 

[TerryRitchie]

it's a bit like that, maybe it's a bad example, but I could compare it to this. I will give you a note on which is written what to bring from the store (index note). Once you have brought the goods from the store, the paper is irrelevant from then on. no one will cross the line. It stays. The advantage is that it remains in case you want to look at what you had to buy later. why should the note be crossed out?

I understand what you are saying. However, I can't think of an example of why I would need to later reference the value of an image that has been removed from memory. The assigning of values to images is handled by QB64 under the hood so you're not guaranteed to ever use the same value again for any subsequent images.

I easily overcame this with a quick little subroutine:

Code: (Select All)

SUB RemoveImage (Image AS LONG)

    IF Image < -1 THEN '   does an image exist?
        _FREEIMAGE Image ' yes, remove the image from RAM
        Image = 0 '        reset the associated image variable
    END IF

END SUB

I'm creating image manipulation routines that pass an image in (InImg) and send an image out (OutImg). The problem arose with OutImg, for example:

SUB FlipImage(Direction AS INTEGER, InImg AS LONG, OutImg AS LONG)
    IF OutImg THEN _FREEIMAGE OutImg ' remove any leftover image
    ...
    ...
END SUB

Even though OutImg was freed the value remained. Later in the code when more images get created one of them will be assigned to the value that OutImg still contains. This was causing all kinds of freaky things to happen until I figured out what the heck was going on, LOL.

[TerryRitchie]

It's normal behavior, and it's always been that way for us.

I believe the main issue one might run into would be with something like the following:

_FreeImage Foo
_PutImage ,Foo

Now, with the above, you're going to get an error message saying, "You're a dummy!  You just freed that image!!"

If the value was set to 0, then that's basically saying, "Put the Image(0) to...."

And, as we all know, Image(0) tends to default to the current _DISPLAY or the _DEST, in most cases...  Which probably isn't what you actually want to happen here. 

Yep, that makes perfect sense as to why the variable is not reset. I can't believe I have not noticed this behavior until now. Maybe an additional line in the _FREEIMAGE Wiki to mention that the associated variable will not get reset to 0 could be added.

[SMcNeill]

It's normal behavior, and it's always been that way for us.

I believe the main issue one might run into would be with something like the following:

_FreeImage Foo
_PutImage ,Foo

Now, with the above, you're going to get an error message saying, "You're a dummy!  You just freed that image!!"

If the value was set to 0, then that's basically saying, "Put the Image(0) to...."

And, as we all know, Image(0) tends to default to the current _DISPLAY or the _DEST, in most cases...  Which probably isn't what you actually want to happen here. 

Yep, that makes perfect sense as to why the variable is not reset. I can't believe I have not noticed this behavior until now. Maybe an additional line in the _FREEIMAGE Wiki to mention that the associated variable will not get reset to 0 could be added.

https://qb64phoenix.com/qb64wiki/index.php/FREEIMAGE <-- How's that look?

[SMcNeill]

And knowing that, you might want to change your code to:

Code: (Select All)

SUB RemoveImage (Image AS LONG)

    IF Image < -1 THEN '   does an image exist?
        _FREEIMAGE Image ' yes, remove the image from RAM
        Image = -1 '       reset the associated image variable, but don't use 0 as it's a valid handle in many cases
    END IF

END SUB

[TerryRitchie]

And knowing that, you might want to change your code to:

Code: (Select All)

SUB RemoveImage (Image AS LONG)

    IF Image < -1 THEN '   does an image exist?
        _FREEIMAGE Image ' yes, remove the image from RAM
        Image = -1 '       reset the associated image variable, but don't use 0 as it's a valid handle in many cases
    END IF

END SUB

Good point!

---

https://qb64phoenix.com/qb64wiki/index.php/FREEIMAGE <-- How's that look?

Yep, perfect.