Some StitchUp updates

No problem at all "Tim Jones".

That was fast. Well now thats two jaw-drops in a row.

I’ve modified the parser to include support for initial values. Excellent! That perhaps was the only thing that was missing from straight hlsl.

If the fragment doesn’t include a vertex shader, then auto-generate one. Ok, I see the point in that and the nice shortcut that it offers. A shader material that needs 2 UV channels? no problem, just use them! Thanks for clearing this up. Good to know the available paths.

You can create a fragment with only a [headercode] block. See DirectionalLight.fragment in the demo project for an example. I think this is the most elegant solution. Seconded. Saw the light struct and how it ends up in the stitched file. There are still some minor issues though, declaring a method will appear correctly in the stitched file, however using it (i.e. in the phong fragment) will result in a compile error at the compile ps2_0 ps() line (at least that's what it says). The same happens for normal variables like i.e "float3 defaultDirection" [params] fields can't be made static or const, however they can in the [headercode] since they are inside an __hlsl_ body and are handled automatically. This behaviour makes perfect sense, since fragment [params] shouldn't intend to be static (although they could?).

• Comments worked perfectly. No more issues there.

So far I have only added support for the .fragment extension, but it would be nice to add support for StitchUp keywords, such as export, import and output.

NShader is working as expected. I was looking through the fork source code, perhaps its only a matter of creating a new map file with the added keywords, load it through the map.load method and done. I hope Alexander Mutel (NShader) manages to pull off autocompletion. The round trip would be complete!.

• I see that you build all .fragment files and add them to the content folder along with the final stitched file. Is there a reason behind this? like custom stitching at runtime depending on machine specs?. On general purpose I will likely be interested in the final file only. however they are tiny files and don't pose a problem at all. Just curious.

• Clickable file: perhaps what would you want is to copy the resulting .fx file to the same folder path the .stitchedeffect sits (not included in the content project, or included with the compile flag disabled). That way it has easy access to open it and watch it, and perhaps see it through an easy disassembler to see how the final driver compiles the .fx file (this way you can see how many registers, preshaders, etc are being used). Like Renaud Bédard Disassembler app http://theinstructionlimit.com/?p=34

Again, awesome work man. Code generation tools are indeed a very very powerful arsenal.

And another one that might be a Bug:

Global variables can't be chained, say I had a Position.fragment that exports a variable:

fragment Position;

[vertex] float4 Position : POSITION;

[vs 20] __hlsl_ void main(INPUT input, inout OUTPUT output) { export(float4, InputPosition, input.Position); } hlsl

and I had a PositionTransform.fragment that did some manipulations but doesn't output the result, instead it export the result to be used by later passes:

fragment PositionTransform;

[parameters] matrix World : WORLD; matrix ViewProjection : VIEWPROJECTION;

[vs 20] __hlsl_ void main(INPUT input, inout OUTPUT output) { float4 position; import(InputPosition, position = InputPosition);

position = mul(position, World);
export(float4, PositionWorld, position);

position = mul(position, ViewProjection);
export(float4, InputPosition, position);

} hlsl

But the generated .fx code is:

void PositionTransform2_vs(PositionTransform2_VERTEXINPUT input, inout VERTEXOUTPUT output) { float4 position; // metafunction: import(InputPosition, position = InputPosition); position = Position0_export_InputPosition; position = PositionTransform2_export_InputPosition;

position = mul(position, PositionTransform2_World);
// metafunction: export(float4, PositionWorld, position);
PositionTransform2_export_PositionWorld = position;

position = mul(position, PositionTransform2_ViewProjection);
// metafunction: export(float4, InputPosition, position);
PositionTransform2_export_InputPosition = position;

}

And this line is where the bug is:

position = PositionTransform2_export_InputPosition;

Hope you can fix it :-)

Hey Tim - amazing tool! I can't thank you enough for not only making this but releasing the code. I'v been playing with it for the last 2 days and here are some comments:

• like other posted, there needs to be at least support for float3x3 and float 4x3. And the chained exports is a great idea.

• texture states is a big requirement for things like shadowmaps and heightmaps etc. I modified your code to allow an initial value on texture variable declarations. The initial value becomes the sampler state such as:

texture2D shadowmap : shadowmap = { MinFilter = Point; MagFilter = Point; }

turns into

texture2D BasicShader0_shadowmap : shadowmap ; sampler BasicShader0_shadowmap _sampler = sampler_state { Texture = ; MinFilter=Linear;MagFilter=Linear;};

• I also added support for Texture3D and TextureCube

• My render engine relies on Pass annotations to setup the GraphicsDevice. It would be great to expand .stitchedeffect to contain technique/pass definitions so I can add annotations. This would also allow multiple techniques. Something like:

technique A { pass A { fragments...
} }; technique B { pass A { fragments...
} };

• pixel output should be able to be defined with multiple COLORs to suport MRT.

And some nitpicky comments:

• I'm not a big fan of the hlsl delimiters. Shawn's original code didnt have them :)
• Not a big fan of the output() behaviour but I see the need for it (so far!). Also its inconsistant when output.position doesnt use output().

Thanks for the feedback - it's great to hear that this might be useful to somebody (and maybe even somebodies).

Yufei andMadoxLabs

I have added support for matrix data types and arrays.

`Yufei - The chained export / import bug is an interesting one. There certainly was a bug - "import(InputPosition, position = InputPosition);" shouldn't have included the export from later in the fragment - this is fixed. However, as you've written it, the third fragment (which you didn't include) which imports the second export won't work, and it wouldn't have worked with Shawn's original system either. This is because a call to "import" will pick up ALL previous exports matching that name, not only the previous one. So you'd end up importing the exports from both Position.fragment and PositionTransform.fragment. That behaviour is both powerful and desired, but obviously doesn't help you for what you're trying to do. Will simply using a different name work?

`MadoxLabs - I have logged an issue for supporting sampler states, but I'd like to get some more feedback on the syntax before implementing it. I'm not totally comfortable with using a sampler_state definition to "initialize" a texture variable, but admittedly I can't think of a better solution.

I have started a discussion around the best way to implement techniques - please vote and comment with your thoughts.

I have added support for Texture1D, Texture3D and TextureCube.

I have added support for MRTs.

I have tried to explain my rationale behind the hlsl delimiters.

I have run out of "I have's" ;-)

Haha, you found my post, eh? I didn't link it here directly because I felt like it isn't really ready for primetime yet. However, Stitchup doesn't need to support annotations more than passing them through to the final .fx file.

Initializing the texture that way was just a quick hack using the new feature you provided, but I think doing something more 'proper' would only add verbosity and nothing else. Maybe thats good though.

Do you mind me logging issues for other things I'd like you to check out?

OK, I started adding issues for things I ran across and made changes for. I'm trying to only enter ones useful for a majority and not ones that are just for me (like changing ReplaceOutputCalls() to work on 'output.' instead of 'output()')

Let me know if its too much. I was just about to start making my own tool when I found yours, so I'm pretty excited.

`MadoxLabs - no, not too much :) I'll take a look at them in more detail shortly.

`Yufei - I made the same change in PreProcessor, and I've committed that already. What I meant was that your third fragment must have something like this:

import(InputPosition, position = InputPosition);

which would expand to:

position = Position0_export_InputPosition; position = PositionTransform2_export_InputPosition;

... which I guess works, but only because the second assignment overwrites the first one. If you were doing another operation (i.e. += or *) then it wouldn't do what you expect.

True, I could remove the data type parsing, but I quite like having it in there - it means I can pick up on syntax errors early in the process, and show nice error messages that link to the correct line and column in the .fragment file. Yes, it does mean I need to do some more work to support all HLSL data types. Please do log issues for data types that you'd like to see added - eventually StitchUp should support all HLSL data types. The only reason it doesn't right now is because I'm lazy ;-)