I used to work on an iBook G3 300Mhz, which had only a software OpenGL driver (no hardware acceleration). It did some of these same things.
The implementation of OpenGL may or may not support full screen displays. My ibook reported that OpenGL was supported in windowed mode but not in fullscreen. As soon as I tried to open fullscreen it would bomb out and it didn't seem like I could stop it without putting the SetGraphics() into a Try/Catch block and taking action from there.
I also heard that at least on the Mac you must have a certain amount of video ram, e.g. 8mb+ in order for the o/s to support and use QuartzExtreme, which supports fullscreen OpenGL. My ibook only has 2mb graphics ram so it barely even has enough memory for one screen yet alone a whole opengl context with various buffers, and yet alone textures on top of that.
In my case when it ran out of graphics memory in windowed mode (ie was working but just not enough vram for textures) it would start to spool textures to main ram. That's a normal feature of OpenGL. Interesting thing is, that without hardware acceleration, textures in `vram` are just the same speed to draw as pixmaps, because they're all in main memory and software driven.
It may be that your particular OpenGL driver perhaps doesn't support fullscreen GL, or maybe has a limit on how much texture ram it recognizes, or maybe it doesn't spool excess graphics to main memory and then just bombs. There also might be other issues `out there` that none of us knows about yet until it happens.
Another thing you must consider is this: If you ask to open an OpenGL display and you request certain buffers, if those buffers are not supported in that particular display mode, the context will fail. It might not necessarily bomb out OR give an error message or an exception, but you just wont see anything on-screen. I implemented a test to draw a pixel and read it back - if it comes back the right color value then I know the display is working. If you get nothing back the context is broken. You get all sorts of different buffer support based on a) the bit depth of the colors requested, b) the way that the card manufacturer distributes pixels across bytes, and c) what particular buffers you ask for - sometimes you ask for a given buffer and it automatically means you get given another buffer as well - typically depth and stencil buffers come together. There is no alpha in 16-bit mode and sometimes you'll get a depth buffer for 16-bit with no stencil, then you ask for a stencil you might get an 8-bit stencil with 24-bit depth buffer. It's not very predictable. In my game I'm just going with a requirement of 32-bit color with alpha channel, and probably must have a stencil buffer.
And no there still isn't decent code (or any) to check vram availability. Ideally you'd want to get that from OpenGL itself but it doesn't have that feature. There should be o/s calls you can tap into that can try to tell you the vram total/usage, but who knows if that is accurate.
The implementation of OpenGL may or may not support full screen displays. My ibook reported that OpenGL was supported in windowed mode but not in fullscreen. As soon as I tried to open fullscreen it would bomb out and it didn't seem like I could stop it without putting the SetGraphics() into a Try/Catch block and taking action from there.
I also heard that at least on the Mac you must have a certain amount of video ram, e.g. 8mb+ in order for the o/s to support and use QuartzExtreme, which supports fullscreen OpenGL. My ibook only has 2mb graphics ram so it barely even has enough memory for one screen yet alone a whole opengl context with various buffers, and yet alone textures on top of that.
In my case when it ran out of graphics memory in windowed mode (ie was working but just not enough vram for textures) it would start to spool textures to main ram. That's a normal feature of OpenGL. Interesting thing is, that without hardware acceleration, textures in `vram` are just the same speed to draw as pixmaps, because they're all in main memory and software driven.
It may be that your particular OpenGL driver perhaps doesn't support fullscreen GL, or maybe has a limit on how much texture ram it recognizes, or maybe it doesn't spool excess graphics to main memory and then just bombs. There also might be other issues `out there` that none of us knows about yet until it happens.
Another thing you must consider is this: If you ask to open an OpenGL display and you request certain buffers, if those buffers are not supported in that particular display mode, the context will fail. It might not necessarily bomb out OR give an error message or an exception, but you just wont see anything on-screen. I implemented a test to draw a pixel and read it back - if it comes back the right color value then I know the display is working. If you get nothing back the context is broken. You get all sorts of different buffer support based on a) the bit depth of the colors requested, b) the way that the card manufacturer distributes pixels across bytes, and c) what particular buffers you ask for - sometimes you ask for a given buffer and it automatically means you get given another buffer as well - typically depth and stencil buffers come together. There is no alpha in 16-bit mode and sometimes you'll get a depth buffer for 16-bit with no stencil, then you ask for a stencil you might get an 8-bit stencil with 24-bit depth buffer. It's not very predictable. In my game I'm just going with a requirement of 32-bit color with alpha channel, and probably must have a stencil buffer.
And no there still isn't decent code (or any) to check vram availability. Ideally you'd want to get that from OpenGL itself but it doesn't have that feature. There should be o/s calls you can tap into that can try to tell you the vram total/usage, but who knows if that is accurate.