So, I know absolutely nothing about memory management. I have avoided it since I learned what it was. But I've run across a problem: I need LOTS of images loaded simultaneously, more then can fit into 512 MB of VRAM. As such, I would like to have them loaded into both VRAM and RAM, but I'll need to move them around as required.

Having NO clue.... can I get some suggestions? I have limited experience with pointers and such...

Thanks,
~Shunter

I think the best way to handle that would be to build an asset library which always stores all of the loaded images in RAM. The asset manager can then create and delete OpenGL textures as required.
That does still leave the question of how the asset manger knows which textures can safely be deleted. I think that would depend on context, but I'd suggest either tracking usage and deleting the ones that haven't been used recently, or building a sort of retain/release system.
I'm afraid you may have to brush up on those pointers. What language are you wanting to work in? I use Objective-C for asset management stuff, because the retain/release system is already there, and the NSArray and NSDictionary classes are very useful.

VRAM is virtualized just like RAM. The system automatically pages on demand.

arekkusu Wrote:VRAM is virtualized just like RAM. The system automatically pages on demand.

Okay, that's a good start, but how about in BlitzMax, which is what I'm using? I was told there that I could only load as many images using the LoadImage() command as my VRAM could hold. To prove the point, I loaded until crash. Or is this a question better asked on their forums?

Thanks

You would definitely be better off asking in the BlitzMax forums rather than here. However, I will say this: I don't think it's possible for you to accomplish what you are asking about. You will have to find another solution.

Of course, I could be wrong.

Shunter Wrote:To prove the point, I loaded until crash.

If you try to load an infinite amount of resources, eventually your app will exhaust the address space (2 gigs for a 32 bit app on Mac OS X.) When this happens, malloc() returns zero, and apps typically crash very soon after that because they don't check for malloc() failing.

Hmm, I guess that makes sense. I'm not sure how much I was loading, but I suppose it might have been on the order of 2 Gigs.

On that note, what's the most size-efficient/reasonable loss image format to use?

That depends on the image. The usual suspects would be PNG if you have few colours or need transparency (compare 8 and 24 bit PNGs too) and JPEG if you don't. JPEG2000 is more advanced than JPEG if you can load those. Drag the quality slider down until the image starts to look bad.
It also depends on the settings you use and to some extent, even the software. For instance Image Ready tends to optimise files better than Photoshop (the save for web and normal save options also give markedly different results).