Image not freed?

I'm busy learning BlitzMax (Mark, damn, it rules!) and I was wondering where all the commands like FreeImage are gone. I guess "release" does the same? If so, why is the handle to the image released, and not the actual memory it uses?

Please try the example below. (I have blitzMax on M:\ so you have to change it in C:\ or something else)

Strict
Graphics 800,600,0

Type Oink

     Field x%
	Field y%
	Field image

	
	Function Create:Oink(a$)
		' The constructor refers to object Oink (After the ':") and asks for a string as argument.
		' A function does not know anything about where it is, unlike the method, so we must do this.
		Print "At start, mem: "+MemAlloced()
		Local o:Oink = New Oink
		Local x, y, image
		o.x = x
		o.y = y
		o.x = 100
		o.y = 200
		o.image = image
		o.image = LoadImage ("M:\Blitzmax\samples\birdie\games\platformgame\media\tiles\block1.PNG")
		Print "Object created, image loaded, mem: "+MemAlloced()
		Return o
	End Function

	Method Destroy ()
		' Be gone, thou evil object!
		Release image
		FlushMem
		Print "Object removed, mem: "+MemAlloced()
		
	End Method
	
End Type

' ---------------------------------------------------------------------------------------------

Local o:Oink = Oink.Create("HAHA!")
o.Destroy()
End

Note to Mark: a lot of commands can use some additional descriptions. In Blitz you used to 1. explain what it does (like now), 2. give a more human description of what it does "chit-chat", and 3. an example. Well, I miss (2) for some commands :-)

At start, mem: 84241
Object created, image loaded, mem: 7241544
Object removed, mem: 7241712

Euh, thanks Perturbatio. I wasn't clear enough with my question:

Why is the memory not back at 84241, or close to that value?

at a guess, it's because you are testing the free mem before the type has been instantiated as well, but when you show mem after the image is removed, the type itself still exists.

Hmmm okay, I wanted to delete the object
From the method Destroy, but ofcourse that is not possible. I would need a function (I don't know if that is possible as well, I guess so).

Correct code, which ends up with even less (?) memory than at start:

Strict
Graphics 800,600,0


' methods werken alleen met bestaande objecten
' je kan Method New gebruiken om object met b:blah = new blah() aan te maken,
' maar een constructor is uitgebreider, omdat je argumenten kunt gebruiken.
' je maakt dan een object aan met o:blah = blah.MaakAan("BLAH")

Type Oink

     Field x%
	Field y%
	Field image

	
	Function Create:Oink(a$)
		' The constructor refers to object Oink (After the ':") and asks for a string as argument.
		' A function does not know anything about where it is, unlike the method, so we must do this.
		Local o:Oink = New Oink
		Local x, y, image
		o.x = x
		o.y = y
		o.x = 100
		o.y = 200
		o.image = image
		o.image = LoadImage ("M:\Blitzmax\samples\birdie\games\platformgame\media\tiles\block1.PNG")
		Return o
	End Function

	Method DestroyMedia ()
		' Be gone, thou evil object!
		Release image	
	End Method
	
End Type

' ---------------------------------------------------------------------------------------------

Print "At start, mem: "+MemAlloced()
Local o:Oink = Oink.Create("HAHA!")
o.DestroyMedia()
Release o
FlushMem
Print "Object removed, mem: "+MemAlloced()

End

yeah, I just did a test similar to that and got the same results. It's a little perplexing.

What does concern me is that when you do MemAlloced() at the start, I get 84241, once the image is loaded, it returns 7241651 which is two digits longer than before.

not a solution to the memory issues, but a Destroy function:

strict
Graphics 800,600,0


' methods werken alleen met bestaande objecten
' je kan Method New gebruiken om object met b:blah = new blah() aan te maken,
' maar een constructor is uitgebreider, omdat je argumenten kunt gebruiken.
' je maakt dan een object aan met o:blah = blah.MaakAan("BLAH")

Type Oink

	Field x%
	Field y%
	Field image

	
	Function Create:Oink(a$)
		' The constructor refers to object Oink (After the ':") and asks for a string as argument.
		' A function does not know anything about where it is, unlike the method, so we must do this.
		Local o:Oink = New Oink
		Local x, y, image
		o.x = x
		o.y = y
		o.x = 100
		o.y = 200
		o.image = image
		o.image = LoadImage ("M:\Blitzmax\samples\birdie\games\platformgame\media\tiles\block1.PNG")
		Return o
	End Function

	Method DestroyMedia ()
		' Be gone, thou evil object!
		Release image	
	End Method
	
	Function Destroy(t:Oink)
		t.DestroyMedia()
		Release t
		FlushMem
	End Function
	
End Type

' ---------------------------------------------------------------------------------------------

Print "At start, mem: "+MemAlloced()
Local o:Oink = Oink.Create("HAHA!")
o.Destroy(o)
'Release o

Print "Object removed, mem: "+MemAlloced()

End

Perhaps Blitzmax uses some memory to build up some stuff, to initialize stuff that can be removed safely with FlushMem?
Dunno, just an idea :)

Now, I want to be able to free my object with the "constructor" principle (I'd better call it "destructor" then). How can I remove the image and the object itself using a function inside an object?

Thanks,

Jeroen

 ^
/|\
 |
 |

Heh, heh I didn't see that codebox before!

Thank you.

They are pointless now.

No. Release is a command that specifies that you're done with an integer reference to an object. FlushMem is the command that actually frees up memory. Witness:

Strict
Print "At start, mem: "+MemAlloced()
Graphics 800,600,0

Type Oink

	Field image:TImage

	Function Create:Oink(a$)
		' The constructor refers to object Oink (After the ':") and asks for a string as argument.
		' A function does not know anything about where it is, unlike the method, so we must do this.
		Local o:Oink = New Oink
		o.image = LoadImage ("D:\Dev\BlitzmaxBeta101\samples\birdie\games\platformgame\media\tiles\block1.PNG")
		Return o
	End Function
	
End Type

' ---------------------------------------------------------------------------------------------
' This demonstrates object scope!
If True
	'The variable o will only exist inside this if block
	Local o:Oink = Oink.Create("HAHA!")
	Print "Object created, image loaded, mem: "+MemAlloced()
EndIf

'invoke the garbage collector
FlushMem
Print "Object dereferenced, as it's now out of scope, mem: "+MemAlloced()

'Create a collector for our object(s)
Local myList:Tlist = New Tlist

'Add an Oink to the list (we don't need variables to track them!)
myList.addFirst(Oink.Create("Witness the greatness of a garbage collector"))
Print "Object created, and added to list, mem: "+MemAlloced()

'Remove the first (and in this case only) Oink from the list. 
myList.removeFirst()

'invoke the garbage collector
FlushMem
Print "Object removed from list, and destroyed by garbage collector, mem: "+MemAlloced()
End

So the answer to the question "How do you free images in BlitzMAX?" is "You don't, BlitzMAX and it's pseudo garbage collector does it for you!".

Hmmmmm, I'm very B3D oriented, so some things are confusing to me. I have some questions on your code snippet, FlameDuck:

Field image:TImage

What is TImage exactly, why not just 'image'?

And secondly, does the garbage collector only work when I use A "Tlist"?

Hi,

'TImage' is a Type - its returned by LoadImage and used by DrawImage etc.

Basically, this means there are 2 ways to refer to images. The classic way...

Local image=LoadImage( "Blah" ) 'nice 'n' friendly...

...and the 'new' way...

Local image:TImage=LoadImage( "Blah" ) 'bit more verbose...

If you use the classic way, you must later release the image using 'Release'...

Release image

...and you can think of Release as the equivalent of FreeImage, FreeSound, FreeWhatever.

If you use the new way, it's (almost) all handled for you: the image will be deleted the next time 'FlushMem' is called and it's no longer in use.

And all this has nothing to do with lists!

Thanks!

....But, still not entirely clear to me.

I understand the "classic way". Release is the equivalent of all "free" commands. Handy.

But, the "new way" seems unclear to me; how does the garbage collector know something is used or not? In your example, you make a "Blah" image, and then later on you say "flushMem". But, if I don't delete anything manually, how can the garbage collector know what is obsolete or not?

As you say, "the image will be deleted the next time 'FlushMem' is called". But why does it do that? I never told Blitz that the object is obsolete. Is the garbage collector looking at which objects are in a Tlist and not?

Hmmm, I hope you understand what I'm trying to tell :)

Because it counts how many types you've made. Once you don't have anything left that references the data in question (and thus no way to access it) the garbage collector releases it's resources.

It can't know when you're done using it (what I assume you mean when you say obsolete). But what it can tell is when you couldn't possibly use it anymore, even if you wanted to, at least as long as you're using types, and not the "classic way".

You don't have to. It counts how many objects you have in play, and when that count reaches zero, it goes "poof".

Because BlitzMAXs types all (?) use "Hungarian Notation". Now hungarian notation is a discipline where by you prefix (typically) a letter to the actual variable name or reference. For instance a float that stores the X position of something could be called fXPosition. In Blitz3D the hungarian notation for this would be XPosition# (if you used it religiously).

Hungarian Notation is a mnemonic technique used to indentify what kind of references you're currently working with, and provides a way to distinguish myPlayer - the object, from myPlayer - the number.

No. The TList is just collector type (note the leading T), that makes juggling objects around much easier. They function similarilly to the way Types used to work in the "Classic way", except now you can have more of them for each type (you could have a list of aliens for each level, and so on, allowing much more advanced object hierarchies than what was possible using Blitz3D), the downside being you have to add them all manually.

Thanks Mikkel.

Please tell if I'm right with my conclusion,
based on Mark's and Mikkel's answers:

------------------------------------------------------
OLD WAY:
When I load a JPG or whatever media like this:

Local image=LoadImage( "Blah.jpg" )

... The *object* TIimage is *not* returned, just a reference
to the image. This is why you will need to release the image
manually and the garbage collector doesn't know anything
'bout it.

------------------------------------------------------
NEW WAY:

In order to do this, I will need to load stuff like this:

Local image:TImage=LoadImage( "Blah.jpg" )

...Where TIimage is the type/object that LoadImage returns.
This is how the garbage collector can keep track of it's
existance as an object.

When I 'release object', I release the reference. When
FlushMem is reached, Blitz sees there is no reference to
the image anymore, and deletes everything in the object:
variables, references to media like textures...everything
what may exist in the object, or type.

Sounds about right to me...

Pretty much. The only gotcha I've come across is when working with streams, which still have to be closed manually.

Not exactly.

A reference to the object TImage is returned. That TImage's internal count is incremented because it realises there is an integer reference to it lose in the system and to reduce that count in order for that TImage to be destroyed you must call Release so it can reduce the count.