Shazzam development is moving again
Shazzam is changing. There hasn’t been much improvement to Shazzam this year and that’s a shame. Especially since there is an influx of Silverlight developers exploring the benefits that pixel shaders bring to their projects.
Many of you have discovered Shazzam via enthusiastic support from the WPF and Silverlight community. Thank you Laurent Bugnion, Josh Smith, daneshmandi, Karl Shifflett, Adam Kinney, Craig Shoemaker and Polymorphic Podcast, Channel9, Andy Beaulieu, Bill Reiss, René Schulte, the Silverlight 3 Programmer’s Reference crew, Dave Campbell (WynApse and Silverlight Cream) , Tim Heuer, Jeff Prosise, Matt Castro and many more that I don’t have links for.
I’m flattered that my little utility is finding a home on so many desktops. It’s nice to hear about the projects you’ve created with Shazzam’s help. For example, check out daneshmandis Face Maker application for an superb example of WPF in action. Being developers you’ve not been shy about expressing your desire for new features either. Which brings me to Eric.
Agent of Change
Say hello to Eric Stollnitz.s
Eric has worked at Microsoft for seven years, first helping to create the Expression Blend user-interface design tool, and more recently helping the Interactive Visual Media group of Microsoft Research develop innovative ideas into shipping software.
Some of you might know his work. He was on the Expression Blend team and also did some work on Peter Blois’s Snoop utility.
Eric has been a great help in getting development on Shazzam moving again. It all started when he wanted to make a couple changes to improve Shazzam’s ability to generate Silverlight shaders. Here’s Eric explaining how he got involved, “Yeah, at first I just wanted two features: remembering default values for shader registers, and generating Silverlight-compatible C# code. Then it kind of snowballed…”
Snowballed is an understatement. Eric has done some great work on the project. I will be chronicling improvements in the next release (many of which are from him) over the next couple days but first let me give you glimpse one of Eric’s contributions.
You can specify minValue, maxValue and defaultValue for values for registers using triple-slash comments in the shader code. The generated C#-VB class gets these values supplied for the defaults. Plus the testing UI is initialized with these settings too. No more reentering values every time you compile the shader!
There’s plenty of other changes. Stay tuned.
As always, you can install Shazzam from the shazzam-tool.com site. The new version will be available by next week.
Since you’re working on Shazzam again, one thing that would be very nice would be eliminating the requirement for installing the DirectX SDK. It’s a huge install just for the sake of the FX compiler. Could you possibly do something like the Shader Effects Build Task (see http://wpf.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=14962 and http://blogs.msdn.com/greg_schechter/archive/2008/08/11/a-visualstudio-buildtask-and-project-and-item-templates-for-writing-shadereffects.aspx) to build it in without requiring the SDK?
It would seriously simplify using Shazzam on a new machine. Thanks!
Scott. That’s a great idea. I’ve found a way to enable this using the DirectShow API instead of FXC.exe.
FYI, you can also enter bugs and feature request at
http://shazzam.codeplex.com/WorkItem/List.aspx
Congratulations on the nice tool, thanks for making it. I’ve been using it fairly successfully for a day or so. I look forward to the new features and versions. So far my suggestions are — 1. Allow the user to specify the pixel shader type to the compiler e.g. ps_2_0, ps_2_a, ps_2_b, ps_3_0, etc. I know ps_2_0 is the only officially supported version in WPF 3.5SP1 but that will hopefully change to ps_3_0 with WPF 4, and anyway it is still possible to use the tool to test shaders that might be implemented other than through WPF plumbinbg. 2. It is said that if you modify the PS version code in the first word of the shader object to be the ps_2_0 FFFF0200 value even if you’ve compiled the PS as ps_2_a or ps_2_b that in practice WPF/SL can load and run it very successfully in most useful cases, and the unfortunate ps_2_0 instruction limits in 3.5SP1 are bypassed thusly. This would be a VERY nice option to facilitate by enabling compiling to any other PS version and having an option to modify the signature word accordingly. The ps_2_0 instruction limits are just too severe for many uses and many people would not mind using an less than officially suggested workaround to get past that. 3. The ability to show the effect of chained or nested shaders would be handy since you can sort of kludge that to occur by nesting stacks of effects in nested SL/WPF elements, so previewing that shader stacking in shazzam would be nifty. 4. Multiple input texture specification to shaders would be nice. 5. You can apply an unrestricted shader variety in WPF by using D3D which renders into WPF supported D3DIMAGE class as a host window. If there was template code and example GUI to facilitate developing this [e.g. input textures / memory buffers from WPF passed through ps_3_0 or other D3D loaded shaders with output to either WPF D3DImage or binary D3D render to offscreen texture target passed back to WPF that would be ultimately wonderful. Thanks for all the good work!
Chris. That’s a nice list of feature requests. I’ve had a lot of requests for multiple input shaders, so that is high on the list of new features.
On a related note. There is a bug tracker and feature request available on the codeplex site. http://shazzam.codeplex.com/WorkItem/List.aspx
I’ve also had requests to chain shaders together. I’m not sure how I would implement the UI to faciliate that yet. I’m open for ideas.
Thanks, Walt. I’ll check out the codeplex page. As for shader chaining UI in the context above, I suppose whatever is easy and works would be suitable. Since you’re already using a multi-tabbed UI style to switch between the sample images perhaps just have a tab for each shader instead shader 1, shader 2, shader 3, each presenting a window of the various input control slider/value parameters for that particular shader. In each shader’s tab window would be also something like a set of list boxes or radio buttons to select texture bindings e.g. Shader_1_Input_1 = {Sample Image_1, Sample_Image_2, Custom_Image_1, …} … Shader_1_Input_2 = {Sample Image_1, Sample_Image_2, Custom_Image_1, ….} for each sampler defined in that particular shader. Now if you added to those texture/image lists the values: {Shader_1_Output, Shader_2_Output, Shader_3_Output, Shader_4_Output…} you could just click to select Shader_3_Input_1 = Shader_1_Output and Shader_3_Input_2 = Shader_2_Output and Shader_3_Input_3 = Sample_Image_1 for instance. So each shader’s output would just be equivalently listed as an possible image input for the other shaders.
The other sort of UI approach that comes to mind for this sort of multi input source multiple output entity chaining hierarchy would be a diagram/graph control similar to what you might draw as a diagram in VISIO or a UML editor where the various shaders have graphical attachment points for their inputs and outputs and you simply select sources like image files / thumbnails or chained outputs from other shaders to flow into a given input node/property graphically. I suppose that would be the more expressive and adaptable sort of UI, but probably the most change relative to the current dialogs.