There may be some value in trying without VKD3D_SHADER_PARSE_DXBC_IGNORE_CHECKSUM first, to determine whether the checksum was valid or not.
And what would happen depending on whether it's valid or not?
We could print a "(valid)" or "(invalid)" next to the checksum in the --list output, I guess.
- I don't completely understand how you perform input: you seem to have the concept of a "main input" (using the positional argument at the end), which is interpreted as the beginning of a pipeline on which a few filters operate, possibly using auxiliary inputs (using `-o`). Is that the intention? The main input is allowed to be the stdin too?
I'm not sure pipeline/filters is the quite the right model, but essentially, yes. The current input/output start out as stdin/stdout, and -i/-o change them. Add/update/extract etc. just use the current input output file, and after parsing the command line we'd have a list like this: ```c struct { enum operation op; const char *section; const char *file; } operations[] = { {EXTRACT, "t:SHDR", "shader.SHDR"}, {UPDATE, "t:ISGN", "shader.ISGN"}, {DELETE, "t:SHEX", NULL}, {ADD, "t:OSGN", "shader.OSGN"}, }; ```
- You seem the consider `-o` an option (changing the command line parsing state but not performing actions themselves) and the various filter (`-x`, `-u`) as the actions, i.e., points at which the program does something for real. Maybe it might be more expressive to reverse the point of view? I.e., `-x` and `-u` merely configure a filter on the pipeline (with the possibility to chain many, or zero) and `-o` takes the current pipeline state, executes it and writes to the specified file. My proposal rather fits this model (except that no filter is currently defined, i.e., you can only write the same shader you just read), which looks more flexible to me. For example you can chain or otherwise compose filters and operators, which seems harder if filters immediately trigger an action.
I think you're essentially arguing for something like ```bash # Extract the SHDR section to shader.SHDR vkd3d-dxbc -x t:SHDR -o shader.SHDR shader.dxbc # Update the SHDR section from shader.SHDR, write the new DXBC to shader2.dxbc. vkd3d-dxbc -i shader.SHDR -u t:SHDR -o shader2.dxbc shader.dxbc ``` right?
I don't necessarily have an issue with that, but I guess the question then becomes what e.g. these do: ```bash vkd3d-dxbc -i shader.SHDR -u t:SHDR -i shader.ISGN -u t:SHDR -o shader2.dxbc shader.dxbc vkd3d-dxbc -i shader.SHDR -u t:SHDR -i shader.ISGN -u t:ISGN -x t:ISGN -o shader2.dxbc shader.dxbc vkd3d-dxbc -i shader.SHDR -u t:SHDR -i shader.ISGN -o shader2.dxbc -u t:ISGN -x t:ISGN shader.dxbc vkd3d-dxbc -x t:ISGN -o shader.ISGN -x t:OSGN -o shader.OSGN shader.dxbc vkd3d-dxbc -o shader.txt shader.dxbc vkd3d-dxbc shader.dxbc > shader.txt ``` and whether that's better than the alternative.