This project is read-only.

Update from the bridge

Sep 1, 2009 at 1:53 PM

First I would like to say how much I appreciate the excitement of the community surrounding this project. This is my favorite and most popular open source project since the tintin++ MUD client I created in the early 90's and hearing back from the community keeps me motivated. Unfortunately over the last couple of months I've been on a very time consuming project and haven't had much time at all to devote to anything else. By the end of this week, that project will be done and I'm excited to move forward and see what I can do to bring this project to the next level. I ask for your patience until then as I may not be able to respond right away.

I'd like to thank Qbus for stepping in and holding down the fort and moving things forward. If you are serious about contributing to this project please let me know, it's a big project and I could use the help. If you've already asked about helping out I'll get back to you as soon as possible.

Now for an update on the state of the version in source control. If there are any specific pieces that anyone would like to help with or take the lead on, let me know.

1. Pixel shaders have helped a lot to allow tinting of textures when drawing, but when doing a lot of draw calls they slow things down significantly. This is especially true for particle effects. The guys over at the Mercury Particle Engine have ported to SilverSprite but it doesn't perform near well enough to be especially useful. There have also been requests for additive blending. The answer to both of these issues is probably the same, and that's to render to a bitmap instead of the ImageBrush/Visual Tree tricks we're currently doing. Now there is still value in the current technique especially for large images. For particles, however, that are short lived, move a lot, and are tpyically relatively small, doing our own rendering to a bitmap should be able to perform well enough. So what will probably happen is that you will be able to set a property on SpriteBatch (or maybe on SpriteBatch.Begin) which requests this other rendering mode so that you can choose which to use. For the current rendering technique, opacity is also done by the pixel shader currently. To avoid the need for a shader when just doing opacity with no tinting, the opacity logic will be taken out of the shader and done using the opacity property of the element (this is how it was in the Silverlight 2 version).

2. It doesn't look like general support for XNA style Pixel Shaders is realistic since you need to create a paixel shader per element and this doesn't fit the XNA model very well. Hopefully a future version of Silverlight may make this possible.

3. Render targets should be possible, and refactoring to allow them will also help support item 1 above.

4. I've been reconsidering the decision to not have a Silverlight 2 version going forward, specifically because Moonlight is going to be on version 2 for a while and it sounds like there may be a Moonlight for iPhone sometime in the near future. I'll see what I can do about setting up a Moonlight environment and getting together a version that will work with it. The current release should work, but as some new features are added it would be great to make them available for Moonlight if possible.