LoadImage and LoadSound consume memory that...

can't be freed with GC Collect. It seems to be the same basic amount (536 bytes) no matter how many images you load or if you load sounds AND images.

See this code:

DisplayMem("Start")
test()
DisplayMem("End")

Function Test()
	'try commenting these out
	Local i:TImage = LoadImage("logo.png")
	Local j:TImage = LoadImage("logo.png")
	Local s:TSound = LoadSound("testsound.wav")
End Function

Function DisplayMem(label$="")
	GCCollect()
	Print GCMemAlloced() + "  " + label
End Function

If you load nothing, start and end are the same. If you load something (or everything) doesn't matter what, the end value is higher than the start value. Must be some BMax filehandling code that creates some globals that aren't freed up.

Worth bearing in mind if you are writing apps to test
freeing memory (like I am).

***BIG FAT EDIT***
Only occurs in Debug mode.

It produces the same value on my system.
<edit>
11196 Start
11196 End

Does it produce the same results when using the GCCollect outside the DisplayMem function? (I can't give it a try now) but it used to be different when flushmem was needed in earlier versons of BlitzMax

yep this produces the same value. If you comment out the loading lines, it returns to the start value.

GCCollect()
Print GCMemAlloced()
test()
GCCollect()
Print GCMemAlloced()

Function Test()
	'try commenting these out
	Local i:TImage = LoadImage("logo.png")
	Local j:TImage = LoadImage("logo.png")
	Local s:TSound = LoadSound("testsound.wav")
End Function

I get:

Debug Mode:
12316  Start
12316  End

Release Mode:
11500  Start
11500  End

So it works fine here.

All examples produce the same 'start' and 'end' values on my system.
<edit>
11196 Start
11196 End

feck. sorry everyone false alarm. Debug Mode produces the 536 byte difference (why I've no idea?) and Release mode is fine. Well that too is worth knowing I suppose. Run all memory tests with debug off.