[2/2] wined3d: Remove usesFog flag from IWineD3DVertexShaderImpl
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
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
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
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