WineD3D state management

[H. Verbeet]

On 27/11/06, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> Am Montag 27 November 2006 13:04 schrieb H. Verbeet:
> > I had a very brief look at the code, pertially because a tarred up
> > directory isn't the most convenient way to spot what has changed and
> > what is still the same.
> I can of course send you my 45 patches too, but they are pretty messy because
> I changed things regularily and committed stuff that shouldn't be committed /
> forgot to commit, ... For sending the things in I have to break them up in
> smaller patches.
Sure. I do understand the reasons, just noting that I probably didn't
spot everything that has changed.

> >   - Why are the state_* functions WINAPI?
> Doh - everything is winapi, but this is changeable of course. Any pros/cons?
Just that they're not actually part of any public Windows API, and I
see no particular reason to change the default calling convention.

> > I'm still a bit uncertain about having all states together in a single
> > array. And I think a construction like:
> > DWORD stage = (state - STATE_TEXTURESTAGE(0, 0)) /
> > WINED3D_HIGHEST_TEXTURE_STATE;
> > in tex_colorop is quite ugly.
> Well, as I said the idea is to be able to group different kinds of states(e.g.
> LIGHTING and vertex declaration and vertex shaders). Well, that isn't as
> strong as I thought it would be at first, a lot of grouping is done in a
> more "soft" way. For example, misc_vdecl calls misc_streamsrc, and
> misc_streamsrc checks if STATE_VDECL is scheduled for updating before doing
> anything. The idea behind this is that the vertex declaration affects the
> resulting stream sources, but the stream sources don't affect the vdecl.
>
> Beauty is in the eye of the beholder :-) At the end its up to AJ to decide
> what way to go. I personally think a single state array, and a single dirty
> list looks nicer :-)
>
> Well, what I am a bit concerned about regarding AJ are the STATE_* macros in
> wined3d_private.h :-|
>
I'm not directly opposed to the current setup, it's more that I'm
wondering if going for separate tables for related states would
perhaps result in cleaner / more flexible code. It would of course
allow you to get rid of those macros :-)