This project is read-only.

Catching up, please read this on futures

Feb 21, 2010 at 7:43 PM

I have been swamped the last month or so working on this little video player for a small sporting event in Vancouver, and finishing up updating my book for Silverlight 4, so I have had very little time to work on SilverSprite. Rest assured that I will be going through these discussions over the next couple of days and responding to anything that needs to be addressed. In the meantime, I have been thinking a lot about the future.

1. SilverSprite "Lite" (now "Core")

For the last release I made an effort to split out a "Lite" version for people using Silverlight and wanting to take advantage of the game loop, keyboard handling, vectors and matrixes, etc. without getting everything else. This didn't work out the way I wanted when I started using it, so I've taken a step back and instead created a "Core" library with this stuff, and the main library that uses this and builds everything else on top of it. I'll be releasing this soon and blogging about how to use it. This new core library only takes 23k once compressed in the XAP file and provides a lot of bang for the buck. The one downside for XNA devs is that you'll have to add a reference to two assemblies, but it shouldn't be too big a deal. I may actually split out more assemblies so that you only have to include what you need.

2. XNA Namespaces

Originally, I went with our own namespaces to reduce confusion and avoid any namespace conflicts with other libraries. Unfortunately this causes problems with things like creating a content pipeline and processor for SilverSprite which is compatible with XNA. Also it makes getting your XNA game ported harder than it has to be. I'm looking for feedback on this. Would anyone be too upset if I go with the same namespaces XNA uses?

3. UserVoice

I've been going through the suggestions in UserVoice at and it's really helped me to decide what's important. Please add your own suggestions there if you have any, this is the place I'll look first for fixes/features to add.


Feb 22, 2010 at 12:54 AM
Edited Feb 22, 2010 at 12:54 AM

Regarding 2, I've no problem with it.  It would certainly simplify things for newcomers, by reducing the amount of preprocessors required (in my case I had to spend several hours on the 'using' declarations alone).

Feb 23, 2010 at 4:25 AM

1. No biggie.

2. Thank you!  The namespace thing was a bit of an annoyance, it's much easier if you keep as much as possible the same.

Feb 23, 2010 at 4:28 AM

I think those are all excellent ideas. My only concern for #2 is a legal one, will Microsoft be okay with SilverSprite using the namespaces?

Feb 23, 2010 at 4:33 AM
bennage wrote:

I think those are all excellent ideas. My only concern for #2 is a legal one, will Microsoft be okay with SilverSprite using the namespaces?

 Well the new "Core" library should really help people to write games in Silverlight, if Microsoft gets too upset that I'm helping them out (and keeping the interface consistent with XNA helps with that too) then I'll address that when the time comes. In the meantime the benefits far outweigh any risk of possible reprisal.

Feb 23, 2010 at 6:57 AM

Great to see your back Bill :)

2. Sounds great to me. I will have to go through my project and chance in all the classes, but I will gladly do that in exchange for "cleaner" looking code.

And as you say, this will help people getting started with SilverSprite too.

Mar 26, 2010 at 1:42 AM

I like #2 if it will increase support for the content pipeline! It would really help Silversprite developers to be able to use more of the XNA user community code out there!