At least in OpenGL you can use glGet() to get the number of bits in any of the buffers. Note that even if you do not ask for a Depth buffer you might be given one anyway. It depends on how the graphics card allocates and uses memory. Normally a pixel in the depth buffer will be 24-bit or 32-bit. If you ask for a stencil buffer it often will share some space with the depth buffer, so the stencil will be 8-bit and the depth will be 24-bit, otherwise most likely the depth is either 16-bit or 32-bit, in most cases.
If you do not ask for an alpha buffer it's possible that you will get a 24-bit color mode with no alpha channel if your gfx card supports it, something to consider - it's one less byte per pixel.
Also you need to consider what is the internal format of textures which you've uploaded. Usually if you upload an RGBA8888 texture it'll be 4 bytes per texel, but for example you can have a 16-bit backbuffer and yet GL might store your textures as 32-bit. Or it may give you a 32-bit back backbuffer on a 16-bit desktop and scale the colors down when you do a Flip (and maybe dither it).
Note it is also possible to not ask for a back buffer - if you set the driver default to not include backbuffer you may get a single-buffered screen (front buffer only), which means you are using less vram. And another thing to bear in mind is that not all systems use only one backbuffer, some systems allocate multiple backbuffers and then cycles through them each time you Flip, to allow you to render at high hz rates without (ie Flip 0) without a vertical blank sync. These extra backbuffers will take up extra ram just like a single backbuffer will and you cannot easily tell through BlitzMax whether this is happening - except perhaps if you experience `mouse lag`.
If you use more advanced features like display lists or vertex buffers etc that stuff has to be stored in vram also.
From my experience OpenGL will try to use as much vram as is available to store textures but if there is not enough it will start to dynamically spool texture data off to main memory by itself, based on the prioritization of individual textures that you define. In an ideal situation this won't happen but if you run out of ram then the amount of video ram being used will remain mostly `full` but the actual amount of graphics that it's handling is more than that.
It's also possible in OpenGL to create `proxy` textures which are basically empty textures or textures with no image, and you can return the error messages generated when there is not enough ram for them, to possibly detect how much video ram is available. I haven't tried it though.
Also bear in mind some systems have ram embedded within the graphics bus, inbetween main memory and video ram, as a kind of cache.
Also other OpenGL state data might reside in video ram so it's hard to tell. I *really* wish they would've implemented a `video ram avaliable` function as part of the library - but I suppose that would have to mean other o/s apps could be using some of the vram outside of OpenGL and it wouldn't be able to tell without dipping into platform-specific code. But hey, if you have to write the driver for GL on a specific platform anyway you'd hope they would at least let you wire-in a memory test.
If you do not ask for an alpha buffer it's possible that you will get a 24-bit color mode with no alpha channel if your gfx card supports it, something to consider - it's one less byte per pixel.
Also you need to consider what is the internal format of textures which you've uploaded. Usually if you upload an RGBA8888 texture it'll be 4 bytes per texel, but for example you can have a 16-bit backbuffer and yet GL might store your textures as 32-bit. Or it may give you a 32-bit back backbuffer on a 16-bit desktop and scale the colors down when you do a Flip (and maybe dither it).
Note it is also possible to not ask for a back buffer - if you set the driver default to not include backbuffer you may get a single-buffered screen (front buffer only), which means you are using less vram. And another thing to bear in mind is that not all systems use only one backbuffer, some systems allocate multiple backbuffers and then cycles through them each time you Flip, to allow you to render at high hz rates without (ie Flip 0) without a vertical blank sync. These extra backbuffers will take up extra ram just like a single backbuffer will and you cannot easily tell through BlitzMax whether this is happening - except perhaps if you experience `mouse lag`.
If you use more advanced features like display lists or vertex buffers etc that stuff has to be stored in vram also.
From my experience OpenGL will try to use as much vram as is available to store textures but if there is not enough it will start to dynamically spool texture data off to main memory by itself, based on the prioritization of individual textures that you define. In an ideal situation this won't happen but if you run out of ram then the amount of video ram being used will remain mostly `full` but the actual amount of graphics that it's handling is more than that.
It's also possible in OpenGL to create `proxy` textures which are basically empty textures or textures with no image, and you can return the error messages generated when there is not enough ram for them, to possibly detect how much video ram is available. I haven't tried it though.
Also bear in mind some systems have ram embedded within the graphics bus, inbetween main memory and video ram, as a kind of cache.
Also other OpenGL state data might reside in video ram so it's hard to tell. I *really* wish they would've implemented a `video ram avaliable` function as part of the library - but I suppose that would have to mean other o/s apps could be using some of the vram outside of OpenGL and it wouldn't be able to tell without dipping into platform-specific code. But hey, if you have to write the driver for GL on a specific platform anyway you'd hope they would at least let you wire-in a memory test.