[4/6] WineD3D: Attempt to clean up fbos only if a gl surface is destroyed

[Stefan Dösinger]

Am Donnerstag, 19. Juli 2007 09:10 schrieb H. Verbeet:
> I think the flag is fine. Executing that part of the code or not
> doesn't really depend on the surface type. GDI surfaces would never be
> attached to an FBO anyway, it's the GL_LIMITS(buffers) that would
> cause problems here. Making sure the limit is 0 if GL isn't available
> would probably work as well.
Exactly, the GL_LIMITS is the problem. The gl info structure is stored in the 
adapter, and the adapter is found via a pointer in the device. If there is no 
gl there is no d3d adapter, ergo the pointer is NULL.

Making sure that GL_LIMITS does not crash but just returns 0 sounds tempting, 
but I am afraid that this provokes more nasty issues. We should just watch 
out not to call it without gl, and crashing if we do is a nice way to show us 
that something is wrong.