I don't like how the number of things staying "as they are right now" is
growing, while the number of things being changed remains confined to
render states. To have a proof-of-concept state management system, it
would be best to take things that are as different as possible, and
manage to get them successfully updated via the new state manager.
Otherwise you won't find out whether the design is flawed or not until
much later.
Agreed, in theory. But I also think that we shouldn't try to put different
things in one model by force. If some things work differently, why shouldn't
we handle them seperately?
Because that creates confusion and disorder - the idea is to move from
chaos (gl code in drawprim, shaders, device.c) to order (gl code in one
place, following a uniform pattern, with the ability to do locking
and/or switch the gl backend).
Shader constants are different from fixed function things in two ways: There
is a dynamic number of them,
That's only a problem, because you keep trying to force everything into
a constant array :)
and there are no dependencies between 2 shader
constants. So there is no use for a table like the fixed function elements,
Sure there is... it creates a uniform structure for applying states,
bringing some benefits as described above.
Dirty-tracking is only one of the goals, and the stateblock already does
some of that..
