Quote: "So, does anybody know how internal mipmapping affects the RAM size of a texture?"
You can do a test with the code above, just add ,1 at the end of the load image sentence.
Quote: "I ran the memory test and can load well over 11,000 .png images without mipmapping"
The same happens here, but the execution doesn't ends like it should.
It shouldn't throw that 506 error. Instead, it should open a dialog (exit prompt sentence) telling how many images were loaded. This works this way (fine) when using mipmapped textures.
This reveals that in the long run there is a problem with non-mipmapped textures.
Quote: " The amount of available memory the test shows (using SYSTEM SMEM AVAILABLE) only begins to decrease somewhere around 450-500 images loaded."
Are you running a laptop or a system with shared video memory?
Here (desktop PC) memory starts to consume at the very start.
Initially it shows the free RAM, and it goes down as the images load. When consumed (around 800 images loaded), it starts to 'rebound' around 6-7Mb, showing that the memory paging has started, then the amount of images loaded goes up to those 1400 images loaded.
So, our systems are not behaving the same. It seems that yours load into VRAM directly, while here it begins to load directly into RAM.
I recall someone said that DBPro is CPU oriented, maybe I shouldn't get the textures directly loaded into RAM. After all, my card has 1Gb dedicated (GTX 295) but it doesn't seem to do any difference with my previous (512Mb) card.
Of course it is obvious that texture loading must be treated programatically (don't try to load 500 textures at once).
Nevertheless, textures should be always loaded 1st into VRAM, this behaviour may be a bug