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

[Phil Costin]

Stefan Dösinger wrote:

> Am Donnerstag 12 April 2007 19:49 schrieb Fabian Bieler:
>> Remove the usesFog flag and replace it with a 'method' as suggested by
>> Ivan Gyurdiev.
> So I'm ready to start yet another design flamewar here :-)
> 
> Honestly I do not really agree with getter methods like this inside
> WineD3D. Yes, they do hide the implementation details, namely how the flag
> is stored. Yes, they do encapsulate data, like the Object Oriented
> Programming model says. But honestly, how much use is it to do a function
> call just to read a value inside wined3d?
> 
> I don't argue that we should make wined3d internals visible to outside
> wined3d. But inside wined3d, my personal preference is to just access the
> implementation structure directly. How much abstraction does such a
> function give us at the cost of performance? In both cases the state
> management code has to know an internal of the shader code, wether the
> shader writes to the fog coordinate. This is something only the shader
> should need to know, no matter how it is accessed. Why do we need it?
> Because the way fog works with shaders requires that either the shader
> sets fog params or the code setting fog params has to know about the
> shader. We can't change that. There are many more examples like surface
> sizes in the viewport and SetRenderTarget code, ...
> 
> -------------
> 
> In case of the foggy shader thing, I think we can get rid of that by just
> setting up the fog start and fog end when a shader is used and fog is on,
> no matter if the shader actually uses the fog. May even be faster in the
> end. Other than that, I think that the shader fog code is not quite right
> either, since if we need the foggy shader setup depends on the
> fogtablemode setting. But other simmilar cases still remain.


I have to say I'm inclined to agree with Stefan here. Unless we're going to
be doing any processing, being called directly from outside the wined3d
library, or requires parameter checking - there's no real benefit in using
a getter.

I will probably send a small patch soon to surface.c to provide some
encapsulation there. But in my defense, it's encapsulation to remove
repetition :-D

If a getter is neither usefully maximizing encapsulation, nor minimizing
coupling, it's probably not required.

Regards,
Phil