Re: [AD] OpenGL state

[Dennis-Busch@xxxxxxxxxx]

Just a thought, since querying the hardware with glGet is probably
slow. Maybe we could track state in software and instruct users to
use our wrappers for glEnable/glDisable/etc instead if they want
seemless combination of custom gl code and Allegro render functions.

e.g.:
al_glEnable(GL_TEXTURE_2D); // public wrapper for user code
would set an internal software bool in some state structure to
memorize that the user wants this enabled in his code and expects it 
to stay that way across Allegro drawing function calls.

al_glEnable(int cap)
{
  some_state_bools[cap] = true;
  glEnable(cap);
}

now an Allegro drawing function might be disabling it internally...
glDisable(GL_TEXTURE_2D);
...but at the end of the function it could set it back to the
state the user intended to have from the already stored state in the
internal user-desired-state-structure *without* querying the hardware
via glGet at any point.

Dennis Busch
d_busch@xxxxxxxxxx


On 16 Jul 2012 at 9:22, alleg-developers@xxxxxxxxxx wrote:
> > In a GIT commit comment, SiegeLord said:
> > Make ogl_flush_vertex_cache disable GL_TEXTURE_2D state.
> > 
> > Even though we don't necessarily care about what OpenGL state we
> > leave after Allegro function calls, some Allegro functions
> > nevertheless expect a particular state to be set. E.g. al_draw_pixel
> > and the primitives addon expect GL_TEXTURE_2D to be disabled, which
> > was the case in 5.0. In the future we probably want a concrete
> > policy of how OpenGL state should be handled internally, as right
> > now it's a hodge-podge of each function cleaning up some state, but
> > leaving other state in an undefined state which can cause bugs to
> > appear when those functions are used together.
> 
> Not having a unified policy of handling the OpenGL state also causes
> confusion and hard to find issues for users (like me) who want to use
> Allegro functions alongside directly accessing OpenGL because of
> implicit state changes made by Allegro (and possibly also by gl state
> changes made by the user when Allegro functions expect a different
> state without setting it explicitly).
> 
> Might be worth investigating whether the following is feasible when it
> comes to performance:
>   Everytime an Allegro function calls a glEnable/glDisable, it calls
>   glGet  first to determine the current (user)state of that cap and
>   then at the end of the function sets it back to that state.
> 
> If that's not possible, maybe there needs to be a table showing 
> if/how each Allegro function call affects the gl state, so user gl
> code can be tailored to revert those changes manually.
> 
> (Unless of course it is a generally accepted common sense law in the
> gl world that you should always explicitly set the state you need and
> never assume a certain state.)
> 
> Dennis Busch
> d_busch@xxxxxxxxxx