.net, Balder

EQATEC donates profiler license to the Balder project

One of the things that has been missing in the Silverlight development story is a proper profiler that is simple to use and does not require you to hack the registry or do complex command line hacks to get it working. The Danish company called EQATEC has been making profilers for a while for the compact framework, but now they have implemented a Silverlight version that I must say I'm really impressed with. EQATEC has donated a professional license to the Balder project and I have already started using it, and my findings are very interesting. I've found more bottlenecks the last 24 hours than I have during the entire course of the project without a profiler. So I'm expecting Balder to get even more speedier in the near future.

If you want to have a look at how the profiler works, Channel 9 has a great video on it here.

 

Standard
.net, 3D, C#

Balder 0.8.8.6 is out

UPDATE 8th of July 2010 : 0.8.8.7 is out – read more here.

Finally after a couple of months of hard work and polishing the code, API and performance, version 0.8.8.6 ofBalderis out. A SampleBrowser can be found here for viewing most of the features ofBalder.
The features that has changed or is new are as follows:

* Introduced Silverlight in Core, but still maintaining platform independence
– Using core objects directly in Xaml can now be done

* Removed all controls in Balder.Core.Silverlight.Controls – not needed anymore

* Introduced View namespace with IView interface and Camera implementing it

* Viewport has View property insted of Camera

* Moved rendering from a multithread environment to run synchronously on the CompositionTarget. It gives better performance, due to synchronization issues between all threads. Will be revisited in the future.

* New drawing routines, optimized

* Heightmap primitive

* Box primitive

* Rotation, Scale on nodes

* Cylinder primitive

* DebugLevel is known as DebugInfo

* Material system in place

* Support for ReflectionMapping on materials

* Double sided materials

* Sprite rendering with alpha channel

* NodesControl – datadriven nodes control with templating – In Balder.Silverlight.Controls

* NodesStack – datadriven stacking of nodes with templating – in Balder.Silverlight.Controls


Standard
.net, 3D, C#, Game Development, Optimizing

Upcoming Balder release – 0.8.8.6

Its been crazy weeks since I decided to pull 0.8.8.5, but it was for the better. The result is that the rendering speed and quality has gone up quite dramatically. The next version of Balder will be 0.8.8.6 and will contain at least the following: 

– Optimized framebuffer management

– Optimized drawing/rendering

– Optimized lighting

– Proper polygon clipping against the viewport 

– Completely refactored way of handling objects, no duplication in the type hierarchy for Balder, like in 0.8.8.0.

– New controls : NodesControl, NodesStack – similar as Canvas and StackPanel works with 2D elements in Silverlight

– New geometry types; Box, Cylinder, Plane

– Transparency for objects / materials

– Introducing the concept of View, you can now create custom cameras

– DebugLevel is no longer flag-based, but a self contained object with properties for all Debug options

– Rendering is now synchronously – gives better framerate in most scenarios, but hogs up rendering event. Ongoing process.

 

Its been crazy since december with a lot of work being put into Balder and more to come. I don't have a date yet for when I'll have the release, but I'll try to push it as soon as I'm content with the result. 

 

Standard
.net, C#

Dispatcher Safe INotifyPropertyChanged

Update, 19th of November 2011:

Eduardo Elias Mardini Bitar did an article for the CodeProject with some updates and improvements.

 

One of the things I really love in Silverlight is the promotion of non-locking UIs through heavy use of asynchronous operations for things like webservice calls. The main problem though with this is that it is running on a different thread than the UI thread and you can't modify anything on the UI without running on the same thread. This even goes for databinding, so if you have properties on an object databound in the UI and you set the value on any of these properties, you still need to be on the UI thread in order for this to work. This is also true for WPF applications.

The way you could do this is to get an instance of the Dispatcher and use the BeginInvoke() method on it. In Silverlight there is only one Dispatcher and it can be retrieved from the Deployment object in System.Windows; Deployment.Current.Dispatcher. In WPF there can be several Dispatchers, so it gets a bit more complicated, you'd have to do Dispatcher.FromThread() and use the current thread during the add method of your PropertyChanged and store it alongside with the instance of the delegate to know which Dispatcher to invoke a change on.

 When I first wrote my automagically implemented INotifyPropertyChanged post, it didn't have this support. I knew I needed it to support it, but I didn't want to have a dependency directly to the Dispatcher found in the Deployment object, as my unit tests would have a hard time coping with that dependency. I needed to abstract it away so I could have a cleaner way of doing this and be able to test it without too much hassle. By introducing an interface representing the Dispatcher, I was halfway there, but had no way of injecting this into the proxy types being created. The problem is that you can't define a constant on the type that holds a reference to a ref object, it only supports value types. I really struggled a full day with this, I was trying to not have any dependencies from the proxies in order to get the Dispatcher, and I didn't want to tie it up to just be compatible with IoC containers and specifically NInject that I'm using for the most part. The result is that I had to implement a DispatcherManager and have a private field on the proxy type holding a reference to an IDispatcher and let the manager control which implementation it got. This worked out nicely, even though it now have a dependency to the DispatcherManager directly. 

This has all been implemented into the Balder project, as I need it for my SampleBrowser I'm working on, the code is located inside the Notification namespace and can be found here

What does it do?
Lets say you have your object like below, the virtuals are in there for the weaver to be able to implement these properties in its proxy (as eplained in my previous post). 

[code:c#]
public class Employee
{
    public virtual string FirstName { get; set; }
    public virtual string LastName { get; set; } 
}
[/code]

The weaver will then go and inject its magic, the end result is pretty much like this:
[code:c#]
public class EmployeeProxy : Employee, INotifyPropertyChanged
{
    private IDispatcher _dispatcher = DispatcherManager.Current;

    public event PropertyChangedEventHandler PropertyChanged;

    public override string FirstName
    {
        get { return base.FirstName; }
        set
        {
            base.FirstName = value;
            OnPropertyChanged("FirstName");
        }
    }

    public override string LastName
    {
        get { return base.LastName; }
        set
        {
            base.LastName = value;
            OnPropertyChanged("LastName");
        }
    }

    private void OnPropertyChanged(string propertyName)
    {
        if( null != PropertyChanged )
        {
            if( _dispatcher.CheckAccess() )
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
            else
            {
                _dispatcher.BeginInvoke(PropertyChanged,this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

}
[/code] 

Standard
.net, 3D, Balder

Sapient using Balder for client project

Balder is rapidly moving from being a proof of concept for rotating a box in 3D as it was in early 2007 to becoming a quality library that can be used for gaming and line of business applications. Thanks to all that has shown interest in the project by using it, writing books about it, creating your own demos and posting it, and last but not least companies like Sapient – that took a leap of faith and went with Balder for visualization on a Silverlight project they are doing for a client they have.

A little more than a month ago, I came to an agreement with Sapient on helping them out using Balder on a non-disclosed client project. The Balder project itself is not affected by it, licensing or ownership wise. But it is affected in a rather positive way, it gives me the extra motivation to keep adding features and at a much faster rate than before. Although it might seem "quiet" on the outside, seeing thats there been more than 4 weeks since a release – its very hectic from where I'm sitting. I'm at high speed and turning out code as fast as I can. I will try to get a release out now and then, and hopefully we'll see one out in a short time span. More on the upcoming release in another post. Stay tuned.

Standard
.net, Balder, Silverlight

INotifyPropertyChanged – Automagically implemented

 

Update, 19th of November 2011:

Eduardo Elias Mardini Bitar did an article for the CodeProject with some updates and improvements.


 

Recently I've been working on a small Silverlight project at a client and at the same time I've been working on implementing a SampleBrowser for Balder on my spare time, both these applications are using the MVVM paradigm and all that comes with it. One of the things that has really been bugging me is the INotifyPropertyChanged interface, a key interface for making the View observe changes on objects. Not only do you have to implement the same thing over and over again (the notification bit), but also the PropertyChanged event takes an argument that holds the property being changed as a literal. Although, the literal bit can be solved quite easily with some Lambda Expression magic, like I've blogged about in the past. But your still left with writing the same boring notification code over and over again.

I got really inspired by Jonas Follesoes post about how he solved the ever lasting challenge of INotifyPropertyChanged using Castles DynamicProxy to generate a proxy and automatically handle most of it. I read it and automatically started thinking about how I could remove the last bits and make the objects needed notification totally ignorant of the fact they should notify any changes. The Castle approach described by Jonas is very clean and I love working with Aspects like that, but it is pretty much impossible to get it to 100% automatically generate everything. The reason for this is that in the Silverlight runtime, you are not allowed for security reasons to invoke delegates on another type other than your own through reflection. Another issue I had that I could never figure out, was how to tie it in with an IoC container. I couldn't find a way in Castles solution to actually get the proxy type and not the instance, this of course is quite possibly possible, but I couldn't find it at all.

I started earlier today with the idea I could generate the proxy from scratch myself. The idea is to create a new proxy type that derives from the type you want to automatically notify its changes by overriding your properties. The properties you want to automatically notify must be virtual and implement a setter. The weaved version will override these properties and actually forward both the get and the set method of the properties to your type, so you can still do more complex stuff in your property methods. The result is a specialized object weaver for handling INotifyPropertyChanged. The code is too much to include in this post, but you'll find the implementation here and the unit tests here, also it support a couple of attributes – much like Jonas' solution for ignoring and adding other properties it should notify as well. Take a look at the entire namespace for all files needed. Also worth mentioning is that if you define your constructor to have arguments, it will implement a constructor on the proxy that is exactly the same and forward any arguments when instantiated. That way in a typical ViewModel scenario were you have dependencies to typically services, these will be injected when creating an instance of the proxy through an IoC Container.

Using it is very simple, create a class:

[code:c#]
public class ViewModel
{    
    public virtual string SomeString { get; set; }  

[/code]

Getting the proxy type:

[code:c#]
var proxyType = NotifyingObjectWeaver.GetProxyType<ViewModel>();
[/code]

Once you have the type you can bind it in your IoC container or simply use the Activator type and create an instance of it. 

UPDATED 12th of January 2010: Discovered a small bug when I moved it into production, had forgotten to mark the type created with public. Silverlight can't instantiate private types via dynamically from other types. Its all been updated in the repository. 

EDIT 18th of January 2010: Made it dispatcher friendly – read my post about it.  

 

Standard
.net, 3D, Balder

2009 coming to an end – Welcome 2010

2010 is just a couple of days away, I thought I'd do a recap of 2009 and what has happened in my little world. 🙂 

Back in August 2008 Balder was at a proof of concept stage and I had close to abandoned the project, I had so many things I wanted to do which resulted in not doing anything. Along came a couple of emails from Clinton Rocksmith who found the project interesting and wanted to know how he could contribute. I was really surprised, I never imagined anyone actually looking at the project. Timing was a bit off, I had just signed a contract with a new company and never got around to prioritize Balder, other projects always came in the way. Again, a couple of months later the project was at a stand still and I was getting again to a point of almost abandoning it completely. In the beginning of 2009 though, I got contacted by Gastón Hillar who also found the project interesting and wanted to include a couple of samples in his upcoming book. This spun me completely of my axis. I worked closely with Gastón in providing him the best possible solution and bring Balder to a new level. For me this was a true turning point for Balder and I quickly decided to put all other projects on a complete halt and focus my energy on Balder. The result was that we managed to get Balder to an API level that felt a lot better, performance was increased with several hundred percent and the codebase quality was increased dramatically with retrofitting unit tests for critical parts. 

The project was all of a sudden going somewhere, it was time to look for other developers to join in. A good friend of mine; Petri Wilhelmsen joined the project and has contributed a bit and will commit more time next year to the project. Another friend of mine; Raymond Holmboe has been contributing some on and off since I started the project back in the days and will be committing more time next year as well to the project. 

The ultimate result from all of this is that there has been quite a few commercial interests in the project, everything from companies wanting to buy the project as a whole to companies wanting to utilize it professionally. This is something I can disclose more information on later next year. One thing is certain though, Balder will stay open source and free to use.

Also this year, I was suggested as a Silverlight MVP and was eventually moved from Xna to Silverlight. Thanks to Justin Angel for recognizing me and suggesting the move, its a true honor. 

Although I had a very nice job at Objectware, the distance of 125 KM to work one way was to big. Even though I didn't commute everyday, it got to be a strain on my family when I had to go early in the morning and wasn't back till late and most nights after the kids had gone to bed. So I started sniffing the market to see if there was opportunities closer to home. I ended up at a company called Bouvet, and don't regret my decision. Bouvet has in my opinion the right focus for consultants, and it just feels right. Happy to be onboard.

Professionally I've had the opportunity to work full time on a Enterprise Silverlight project, I've worked on two Microsoft Surface projects, some WPF projects and finally ended up spending the last 3-4 months of the year working on an ASP.net MVC project with some Silverlight content.  

Its also been a very busy year when it comes to speaking engagements, I've been part of Microsoft Norways MSDN Live tour, been speaking at NNUG a couple of times, Game Camp, did a Silverlight course. 

2009 has truly been an exciting year, busy, but very exciting. With the release of Silverlight 3 this summer and the beta version of Silverlight 4, I'm at a point were I really can't wait to get out of bed in the morning and just find the keyboard and start hacking away. It has never been more fun to be a developer, a lot is happening these days, not only in the Microsoft arena, but in general. I can't wait to see what 2010 brings.

 

Happy new year everyone, looking forward to participate next year. Thanks to everyone who has made 2009 so much fun and exciting, especially I'd like to thank my wife and kids, who has really been patient with me and supported me along the way. 

 

 

Standard
.net, Balder

Innovasys donates to the Balder project

One really important thing when creating a framework like Balder, is to create proper documentation. The purpose of the documentation is for people to get good explanations for the API and samples on how to use it. 

I've been researching quite a bit for finding a good solution for doing this and didn't want to do all documentation by using XML comments only, but wanted more rich content and must admit that I never found any free solutions that I found satisfying. In the past I've used Innovasys' solution called DocumentX and was very happy with it. It might not be the natural choice for an OpenSource project to chose a commercial product, but the quality in which I want the documentation to be in I really wanted to use a product like DocumentX.

DocumentX provides a combination of documentation generated from XML comments in the code and rich text edited content, all mixed in nicely in the development environment; Visual Studio. This makes it easy to use and maintainable.  

Long story short, we've been so lucky to get Innovasys to sponsor  donate a license to actually do this. So a big thanks goes to them for providing the necessary license for this.

  

We will be working on updating the documentation and get it in future releases and part of the regular development. 

Standard
.net, 3D, C#, Game Development

Balder 0.8.8.5 pulled – why ?

A couple of days ago I published a new version of Balder; 0.8.8.5. It had a bunch of improvements in it, especially when it comes to the Silverlight Control support. I had to pull the release mere hours after its release. The reason for pulling it was that I did a lot of optimizations in the rendering, or at least I thought I did. Turns out that when running on a very fast Dual core or Quad core computer, it was faster – but on slower machines, it turned out to be quite slow. 

Instead of reverting the entire optimization, I've decided to actually get the performance up quite a bit. I've been working on a new rendering pipeline that would increase the performance dramatically, so no time like the present.

The biggest change however with the release was the Xaml support. In the Development branch over at GitHub you will find source code with the rendering pipeline being the same as in version 0.8.8.0, but with all the new Xaml support. So if you can't wait for the optimizations and want to get your Xaml right from the start – you should go pull the latest on the Development branch and compile the binaries yourself. In fact, it should be fairly simple to do it, just download it and run the build.cmd file from a command prompt and it will output a Drop directory with all the binaries in it.

Standard
.net, 3D, Balder, Game Development, Silverlight

Balder 0.8.8.5 Release is out

UPDATE 8th of July 2010 : 0.8.8.7 is out – read more here.

UPDATE, 16th of December 2009 : Release was pulled due to issues with rendering. New release will be pushed soon.

Its that time again, yet another release of Balder. You’re probably thinking – whats going on? Pushing releases close to every week.

Well, this release had to be pushed out fast, the reason being that a couple of days after the previous release I realized that the Xaml support introduced felt good while using it, but clearly had its limitations and also maintainability issues when working with the library.

In the previous release I introduced the Xaml support as Controls in the Balder.Silverlight assembly, which seemed like a fair place to have it, seeing that Xaml/Controls are a very specific platform option that Silverlight supports and should not be present in Core. Problem with that was that we now had two object hierarchies to maintain, one just reflecting most of the properties already found in Core and doing some crazy magic to maintain these hierarchies. Needless to say, this approach is very error prone and hard to maintain.

Dependency Properties

The main reasons for not pushing the Control support into Core was the fact that I didn’t want DependencyProperties leaking into it all over the place and not wanting types to derive from DependencyObject or any other Silverlight specific type. So what I came up with is to make the types in question partial and implement the Silverlight specifics in a .Silverlight.cs file – which then could be skipped for other platforms. Then for DependencyProperties, I wrapped everything up in a generic Property type that has a Specific Silverlight implementation that again can change for other platforms.

The result is a more maintainable codebase, and a better experience when using it.

Speedups

Another reason for pushing for another release was the fact that I did some heavy optimizations. Earlier when doing optimizations, I worked mostly with Silverlight 2 and Silverlight 3 Beta. For SL2 I created a RawPngBufferStream, since no WriteableBitmap was available there, and for SL3 beta, the WriteableBitmap was quite different than what the final RTW version had going for it. Long story short, I ended up with a multithreading scenario that gave quite a performance boost.

After looking at this for quite some time, I found that it would be better to have multiple WriteableBitmaps and do triplebuffering with these and use different threads for different purposes (Clearing, Rendering, Showing). Turns out that this was quite efficient, only problem was that synchronization turned out to be a bit of a problem. So I did a test with doing all the operations synchronously in the CompositionTargets event, and it gave a serious performance boost. That combined with some optimized ways of clearing surely seemed to do wonders.

The new release is available fromhere.


Standard