H. Verbeet wrote:
There are a couple of instructions that have to sample from a texture, right now most of them duplicate that code, and hardcode the texture type.
Changelog:
- Create a separate function for sampling a texture
You should continue to use "add_param" or "get_register_name". There should be a single point in the code where register names are constructed, adding another one is a bad idea. This function is specifically tasked with naming registers, and taking into account things like relative addressing, so that when samplers support relative addressing in the future, changing the naming scheme would be trivial.
On 27/11/06, Ivan Gyurdiev ivg231@gmail.com wrote:
H. Verbeet wrote:
There are a couple of instructions that have to sample from a texture, right now most of them duplicate that code, and hardcode the texture type.
Changelog:
- Create a separate function for sampling a texture
You should continue to use "add_param" or "get_register_name". There should be a single point in the code where register names are constructed, adding another one is a bad idea. This function is specifically tasked with naming registers, and taking into account things like relative addressing, so that when samplers support relative addressing in the future, changing the naming scheme would be trivial.
Except that that's not going to work. Some instructions, like texm3x3tex, only give you an index of the sampler to work with.
H. Verbeet wrote:
On 27/11/06, Ivan Gyurdiev ivg231@gmail.com wrote:
H. Verbeet wrote:
There are a couple of instructions that have to sample from a texture, right now most of them duplicate that code, and hardcode the texture type.
Changelog:
- Create a separate function for sampling a texture
You should continue to use "add_param" or "get_register_name". There should be a single point in the code where register names are constructed, adding another one is a bad idea. This function is specifically tasked with naming registers, and taking into account things like relative addressing, so that when samplers support relative addressing in the future, changing the naming scheme would be trivial.
Except that that's not going to work. Some instructions, like texm3x3tex, only give you an index of the sampler to work with.
That's because they're shaders v1 instructions, which are being phased out [ not applicable to glsl backend at all ]. Old things should be layered on new infrastructure, so those should be handled by making a fake sampler. I think there's already code in baseshader that does that.
On 28/11/06, Ivan Gyurdiev ivg231@gmail.com wrote:
H. Verbeet wrote: That's because they're shaders v1 instructions, which are being phased out [ not applicable to glsl backend at all ].
But of course we still have to support them.
Old things should be layered on new infrastructure, so those should be handled by making a fake sampler. I think there's already code in baseshader that does that.
I'm actually not too happy with the way add_param works. I think it depends too much on the binary format for d3d shaders.
-
H. Verbeet -
Ivan Gyurdiev