State management in D3D... is currently kind of a mess. Stefan D. posted a message about this some time ago, but I can't find it right now...
- some states are applied immediately (via Set* calls) - some are applied at draw time (like shaders, textures, transforms, ...) - some are recorded into a stateblock structure, and applied when the app says apply(). - the GL code is all over the place, tightly coupled to the d3d code.
=============================== There's a number of projects going on at the moment, from what I understand:
- Roderick is working on making wined3d -> wgl - Stefan D. has expressed concern about multithreaded d3d (where the D3D device state is shared, but not necessarily the GL one - or can GL contexts be shared between multiple threads?) - I'm trying to get FBOs to work, where the FBO needs to be bound once both the render and stencil target have been assigned (that's 2 calls from the app in any order) - i.e I need those states to be applied in a delayed fashion, before draw - Henri Verbeet wants multiple render target support added to that (meaning the FBO needs to be bound once *all* render targets are assigned in addition to the depth/stencil one). ================================ All of the above have a common theme - better state management is needed, with more encapsulation, and better separation between D3D and GL. So, let's come up with a plan, and try to implement it. How about we redesign the stateblock object like this:
- remove deltas. I.E. if a SetLightEnable() command is sent, fetch the light, enable it, then save the light back - store only state, and no deltas. This should make the recording stateblock (updateStateBlock) the same as the initial device stateblock, which stores states
- provide a uniform internal interface for accessing states inside the stateblock - like: SetState(stateblock, ID_XYZ, (void*) state_data); GetState(stateblock, ID_XYZ, (void**) state_data); CaptureState(stateblock, ID_XYZ); ApplyState(stateblock, ID_XYZ);
ID_XYZ could be an individual state, or a "trigger" keyword, which will refer to a whole group of states. Those would be private functions in addition to the standard interface.
- provide a fn pointer table inside the stateblock [ which can be directed to OGL or WGL or AGL ], which, for each ID_XYZ, maps a get and set function using the same interface
- move all device.c GL code into those functions
- now all device.c Get* and Set* requests will do is: - error checking - recording into updateStateBlock - or writing to stateBlock (which may be applied later, at our discretion).
- apply() would just loop through all the IDs and call the corresponding function pointer if the states are marked dirty (we'll keep the 'dirty' field)
- capture() would do the same in the get* direction.
- new object can be instantiated per device, or per device per thread to address multithreading. It could have an associated glContext, and can be locked as necessary.
- it would use ideas from the d3d9 test framework for stateblock, except of course more competently written, and cleaner :)