Quote: "DBC creates Direct Draw Surfaces which are sized based on the display mode you set - including bit depth"
Ah, makes sense - just been trying it out, a 32-bit 1024x768 image is 3073kb, pretty much as expected.
Quote: "A couple of things to keep in mind, when you GET IMAGE, most likely it's converted to a DDS object (direct draw surface). In this process, a mip map is probably created "
I've run a few more tests based on my example code (using one image, 1024x768), and I think that what happens with the memory is confusing, although there is a sort of logic to it. Calling "get image" loads the image into system memory, using an image of the same bit depth as the desktop (in windowed mode).
If we ignore the texture mode flag for now:
If I call "Texture object", I believe that the image gets copied over into (video?) memory at this point, and is then prepared as a mipmap (takes up 4Mb instead of 3Mb of memory). "Set Object texture" selects whether these mipmaps make it to the screen, but they still exist (speeds up activation of mipmaps later, I suppose).
If I call "Paste image", then the same process occurs (we get the same 4mb rise in memory). Interestingly, I also tried sprites - the image gets copied (to video memory?) but without any mipmap data.
Strangely, calling both "Paste image" and "Texture Object" seem to result in two mip-mapped versions appearing in memory, on top of the source image. Based on what you said, I suppose DBC (or DirectX) can't risk an object texture disappearing from memory on "delete image" so the texture must be made independant.
Sprites are an unusual case though - if the sprite exists and the image is deleted, then the sprite will still clog up memory (memory which I can't seem to find a way of freeing, even with delete sprite).
If the texture mode flag is set to one:
As far as I can tell, the only difference is that on loading the image is copied directly into video memory and it speeds up object texturing quite considerably - the only problem is that the image now exists twice, once in system and once in video memory.
Create Bitmap 1, 1024, 768
CLS RGB(255, 0, 0)
Get image 1, 0, 0, 1024, 768
Delete Bitmap 1
rem I get 20ms without the flag, 0ms with the flag
For T = 1 to 500 : make Object Cube T, 5 : Next T
One = timer()
For T = 1 to 500
Texture Object T, 1
Next T
Two = Timer()
Break Str$(Two - One)
Deleting the image only frees up system memory, while the copy in video memory remains - the hidden command "Flush video memory" (am I remembering that one right?) now makes sense to me, because when you want to load new textures you'll have to clear out all these old ones that are just cluttering up RAM doing nothing exept slow down the program!
"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."