libobs/graphics: Add support for param assign with type constructor

[exeldro]

Description

Add support for:
uniform float4 test = float4(1,0,0,1);
next to the existing:
uniform float4 test = {1,0,0,1};

Motivation and Context

Support more shader stuff. This helps converting glsl shaders more easily.

How Has This Been Tested?

On windows 11 by having a shader with the new param assignment

Types of changes

• Tweak (non-breaking change to improve existing functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[PatTheMav]

Can you post an example shader to test this with? I need to ensure this doesn't break Metal shader transpilation.

[exeldro]

for example in

obs-studio/libobs/data/solid.effect

Line 2 in 2b613f4

uniform float4 color = {1.0, 1.0, 1.0, 1.0};

replace {1.0, 1.0, 1.0, 1.0} with float4(1.0, 1.0, 1.0, 1.0)

[PatTheMav]

EDIT: My comment here is "wrong" insofar as the PR adds support precisely for what I'm advocating here, but I misread the code change and thought it did the opposite.

I'll keep that comment here for posterity, but it doesn't apply to this change.

---

My main issue with adding this feature is that it relies on implicit type conversions, which are not under the control of the developer and thus can lead to unexpected behaviour, particularly between the 3 shader languages we have to transpile into.

So when given the choice between expressiveness (the code spells out what is intended to happen) and correctness (using a "wrong" conversion results in an explicit error), and saving a bit of time writing shaders, we should always prefer the former.

Functionally most shader languages will just do an implicit conversion here, with all the caveats and issues that implicit conversions have to begin with:

• Which conversion actually takes place under the hood is opaque to the developer
• Because of that the code can exhibit strange, unexpected behaviour
• Implicit conversions usually compile fine if they are non-narrowing (e.g. half to float)
• Implicit conversions can compile fine even if they are narrowing if the constant itself can be fully represented in the target type
• However they will fail once the compiler cannot ensure this (either the constant is too large for the target type or a runtime value, e.g. an int)

And because we don't precompile shaders (even though it would be better if we did), those issues might only occur at runtime when people run the app, so our transpiler should be more strict about these things (to reduce the potential runtime shader compilation errors) not less.

[exeldro]

Where do you see the implicit type conversions? The change only works when the type is exactly the same, checked by strref_cmp(&ep->cfp.cur_token->str, param->type) == 0, which would result in no type conversions.

[PatTheMav]

Where do you see the implicit type conversions? The change only works when the type is exactly the same, checked by strref_cmp(&ep->cfp.cur_token->str, param->type) == 0, which would result in no type conversions.

Sorry, disregard my prior comments, I wholly misunderstood the changes of this PR.