[2/2] wined3d: Remove usesFog flag from IWineD3DVertexShaderImpl

Stefan Dösinger stefandoesinger at gmx.at
Fri Apr 13 09:07:16 CDT 2007


> Well, your use of a redundant top-level flag does kind of remove the
> need for a getter - I only brought it up, since I've moved the reg_maps
> structure around one too many times, and that's where the first flag is
> stored.
I agree that the top level flag was bad. It was just a redundant copy of the 
reg_maps content in the same form.

> The more complex and interconnected the codebase, the more it makes
> sense to encapsulate things. I think abstraction also benefits the less
> experienced developer. You make a good point that this level of detail
> should be internal to the shader to begin with, regardless of how it's
> accessed.
I think for this special case its the best to see if the state management 
really has to know about this flag and remove it if appropiate.

Your point that we should use encapsulation to make things easier is good, but 
I do not think that encapsulation always makes does that. Like in the fog 
thing, I guess the main question for someone who does not know the code will 
be why the state management has to know wether the shader writes out fog. The 
way the state management gets the flag is not that important. But that 
example is not of much use anyway.

A place where we desperately need more encapsulation is the surface code. The 
dirtification, downloading and uploading could use some cleanup to replace 
all the mad flag setting and clearing.

A place where I think encapsulation wouldn't be useful is accessing the device 
and stateblocks. A lot of things depend on the stateblock, like Vertex Buffer 
loading, Shader compilation and (a bit) resource management. But in all those 
places the stateblock is only read(except in Resource::Release, which should 
actually go) and IMHO just accessing the stateblock to compare the pointers 
is easier to read than a Get*(), compare, check against NULL, release.

> > How much abstraction does such a function
> > give us at the cost of performance?
>
> You can always make the function inline (although that's also rather ugly).
Nah, and it is not reliable either.
-------------- 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/20070413/04983e5c/attachment.pgp


More information about the wine-devel mailing list