WineD3D: Sample from the correct source when using older pixel
ivg231 at gmail.com
Sun Aug 27 08:47:19 CDT 2006
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:
>> 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).
More information about the wine-devel