Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Discussion / Load image - what takes up all the RAM?

Author
Message
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 10th Jun 2010 13:41
During a debug of Lightning Limbs I opened Windows task manager and was quite staggered by the 60Mb Ram usage, given that I only had around 8-10Mb of bitmap images loaded and four low-poly objects. After a few tests, I got some interesting results but I don't understand them:




DBC uses at least 20,292 Kb, just to function. Remove the remstart/remend block to produce a 1024x768 image and the memory usage increases to 23,376 KB, so the image is therefore 3084kB in size. Unfortunately, when you save the image as an uncompressed bitmap, the image is 2305KB. Where's the extra 779kB come from?

I have a theory that DBC holds all internal images in Ram as 32-bit images, which would account for the third again increase in memory - but is that actually what's happening?


I also wanted to ask about the optional "Load/Get Image" parameter, "Texture Mode". Setting it to 1 loads the image directly into video memory instead of having the system do it later - but what does this mean? According to Windows task manager, it seems to load the image twice and I don't see any increase in program performance - so is it worth doing?

"I wish I was a spaceman, the fastest guy alive. I'd fly you round the universe, in Fireball XL5..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 10th Jun 2010 22:20 Edited at: 12th Jun 2010 20:50
Since you are using window mode in DBC, the bit depth is going to be what your windows desktop bitdepth is. That's also going to change some of your memory results because resouces are going to be allocated to maintain the COM components of windows for DBC.

Quote: "I have a theory that DBC holds all internal images in Ram as 32-bit images, which would account for the third again increase in memory "

No, again, in your example, you are using window mode so the bitdepth becomes your desktop depth. DBC creates Direct Draw Surfaces which are sized based on the display mode you set - including bit depth.

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 which means different levels of detail - actually multiple images - and a little larger of a memory signature. This may be automatic and only actually available when you use MIPMAP MODE and the appropriate texture setting for a matrix or object.

Quote: "I also wanted to ask about the optional "Load/Get Image" parameter, "Texture Mode". Setting it to 1 loads the image directly into video memory instead of having the system do it later - but what does this mean?"

When you get image or load image, initially it is loaded into system memory. Depending on it's use, the image will be copied to video memory by DBC later. If you use it as a texture on an object, it'll most likely get coiped to video memory before the object is textured. It also depends on the EMULATION mode. If you have software emulation enabled, the images will probably remain in system memory unless you directly load them into video memory.

The cross from video memory to system memory is very slow, but video to video is very fast, as well as system to system. So it may be advantageous to load your images into video memory from the get go if you are not using emulation.

Quote: "According to Windows task manager, it seems to load the image twice and I don't see any increase in program performance - so is it worth doing?"

When the image makes it's way to video memory (the twice thing probably happens automatically as well) there is an index for use with 2d (through COM) and an index that is used for texture space. If you texture an object and delete the image, the object will still retain the texture - however, this isn't a smart thing to do because I think some memory corruption occurs and it's just a matter of time before crashes and missing references start to happen (I've been down this road).

Is it worth it to use it? The real test would be with masses of image loads/gets and uses as textures and so forth. Try running some sprite tests and see if there is a difference.

But, I'm guessing at most of this from observation and some reading. I don't know how the internals of DB are programmed.

Enjoy your day.
Robert The Robot
17
Years of Service
User Offline
Joined: 8th Jan 2007
Location: Fireball XL5
Posted: 12th Jun 2010 13:00
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.



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..."
Latch
17
Years of Service
User Offline
Joined: 23rd Jul 2006
Location:
Posted: 12th Jun 2010 21:07
Quote: "the only problem is that the image now exists twice, once in system and once in video memory."

This may be necessary, sort of. Reading from video memory is very slow if you want to do things like make a memblock from an image. The memblock is in system memory and in order to make a quick copy of the image, it makes sense to have a version in system memory so it can be swapped quickly to a memblock.

Enjoy your day.

Login to post a reply

Server time is: 2024-03-28 18:54:22
Your offset time is: 2024-03-28 18:54:22