WineD3D state management

[Stefan Dösinger]

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.

(I have uploaded the tared patches to 
http://stud4.tuwien.ac.at/~e0526822/statepatches.tar.bz2) The 0001 patch 
doesn't really belong there though.


> A few things I noticed:
>   - markDirty() should probably either be a proper method of the
> device, or have a prefix
>   - "States" is a pretty generic name, probably want to prefix that as
> well with something
Agreed
>   - Why are the state_* functions WINAPI?
Doh - everything is winapi, but this is changeable of course. Any pros/cons?
>   - "apply" is probably a better name than "func" in StateEntry wrt
> making clear what it is supposed to do.
Yeah. Those things are easilly changeable

> 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 :-|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20061127/85b627a1/attachment.pgp