WineD3D: Sample from the correct source when using older pixel shaders

[Ivan Gyurdiev]

Stefan Dösinger wrote:
> Am Sonntag 27 August 2006 04:29 schrieb Ivan Gyurdiev:
>   
>> Stefan Dösinger wrote:
>>     
>>> Pre 2.0 pixel shaders do not contain a tag for the texture type to sample
>>> from. Wine had 2D textures hardcoded, this patch checks the bound texture
>>> type to decide from which texture to sample from. For >= 2.0 shaders the
>>> shader tag is still used.
>>>       
>> Why can't this be done in a much cleaner way where the sampler is
>> initialized (2nd pass, baseshader, get_registers_used)? Then you don't
>> have to copy and paste the same thing in many places - there's 10
>> texture instructions or something like that for pixel shaders alone.
>>     
> Well, I'm pretty new to the shader code, seems like I didn't find the right 
> place for this :-)
>
> If I understand you correctly I should check the texture type from the 
> stateblock around line 300 in baseshader.c:
>   
Yes.
>> Also, maybe the stateblock should be passed as an argument to all
>> functions that use its states. I don't like walking up the tree to find
>> what you need (this->wineD3Ddevice) - it's a hidden dependency on device
>> state, which isn't even all the time - that's why you had to move the
>> point where the shader is compiled [ this needs better documentation ].
>>     
> Do you mean adding a pointer to the stateblock in baseShader or copying the 
> entire stateblock?
Well, clearly copying the entire stateblock is a bad idea, and unnecessary.

I guess what I was thinking is that the reg_maps structure, which 
currently stores a sampler DWORD, would instead store a sample 
structure, and the generation code wouldn't know or care where the data 
came from originally - wouldn't know anything about the stateblock. The 
stype would be filled out according to the texture, or the sampler code 
for post-2.0 shaders, and there would be a projected flag.
Then the stateblock could be an argument to the initialization function 
to make it clear that we're reading data from the stateblock [ so the 
stateblock better be able to provide that data at that point ].

... on second thought it's probably fine the way you have it - but the 
stype field should be initialized in one place, and the projected too 
(should be a boolean flag).