NND’s source is being analyzed

Buddy James has taken it upon himself to get familiar with NND’s source code base. I find him a very brave person indeed. Of course, you don’t climb the mount Everest without any tools. So he’s been testing out NDepend on NND’s code base to get a better picture of the whole thing. And he’s started to write about his findings so everybody can enjoy the results.

I must say I’m dying to find out the final results of what NDepend has to say about my code, especially since it was written completely free-hand. That is, I started writing the source code without any initial design sketch at all. One thing I can probably already say right now: there is 0% test coverage, mostly because I hardly wrote any tests (bad idea, I know, but I had my reasons at the time, also I’d probably still be writing code right now, if I had). I’m kind of hoping that NDepend finds the functions itself fairly clean (I hate functions that are bigger than the screen and I always try to add some comments here and there).

Anyway, I hope that the results can be of use to you in your endeavor to better understand what’s going on under the hood. And of course, I’ll do my best to be a good sherpa during the climb to that top, so if you have any questions, feel free to contact me and ask


Well, sometimes things just go wrong, plain simple wrong. Today was one of those days. Confucius ruled and the order of things just went wrong, so instead of backing up the DB first and then trying something, I first tried it and then overwrote my good DB backup with a bad one. How stupid…

So now, I’ve lost all my posts.Luckily, most of  the important ones had long since moved to my other site. Anyway, a fresh start, a new day…


It looks like the Viseme images hosted by Verbots have disappeared after their commercial activity stopped. Fortunately, Freddy from AIDreams was kind enough to restore the page on his own site so that people can still access this very useful info. Thank you Freddy.

Window RT: dead man walking

I’ve just been chasing my tail for the last couple of days, trying to get my upcoming ‘Go’ game also ready for Windows RT, aka ‘Metro’.  I figured that it wouldn’t be too hard building a version for this platform since the UI was just freshly written in the latest .net version, well separated from the back-end and only using basic XAML + some code behind for the rendering. Oh, and apparently from now on, there would only be 1 windows 8 for all platforms. All of which made me think it would be fairly easy to develop apps that can be ported to Metro.  Boy, was I wrong.

Don’t be fooled by the sales pitch, this is not 1 windows 8, but 2 very different beasts. Especially from the perspective of a developer: Porting your existing xaml over to a Windows RT app is no trivial task, and often simply not possible. Here are some examples of what you can expect:

  • Do you have any listviews that display data in columns: too bad, you can’t do that anymore. MS’s explanation: it’s not the ‘metro’ look????
  • no more references to static fields (things like {x:Static xxx} ) Why? Who knows..
  • No more effects, not even bitmap effects. Apparently, MS doesn’t want you to make pretty  interfaces.
  • According to the same principles: No more radial gradient brushes
  • Visual brushes or CachedBitmapBrushes: illegal
  • Oh, and you no longer have an ‘OnRender’ or DrawingContext, so forget about making responsive UI’s
  • Thinking about adding some triggers to you templates: too bad, use StoryBoards or converters instead.

The list goes on and on. And this is just for the Xaml part. There’s also Files, threads and lots of other classes that are no longer there or are completely different. For the C# bit, you can probably still work your way round most things by carefully designing your app and using #ifdefs where needed. But you simply can’t do that with Xaml, it’s an all or nothing thing. And since so many pieces are missing, creating a UI for Metro, means writing a completely new one. All this results in the sick and perverse effect that it’s actually less work porting a game like this to the android platform (using monodroid) then to port it to Windows-RT (how much of a failure is that!!)

You could argue to write all your XAML in ‘metro’ style and use this for the regular Windows platform as well since after all, ‘metro’ seems to be sort of a sub-set of the full windows API. From a technical point of view, this might work, with some #ifdefs here and there in the backing code. Unfortunately, in most cases, you’ll get a completely unusable app due to lagging response times. Take the ‘Go’ game for instance. With a full board, there are 625 stones (25 * 25). There are 3 layers for drawing each stone: a dropdown-shadow, a rotated image, and another overlay-shadow. That makes a total of 1875 object + a few extras for the border and score values. Lets say, all in all there are 2000 objects that need to be drawn on the screen in total.. Well, this is too much for xaml. You need to use some tricks with CachedBitmap brushes and rendering graphics from code in order to get a responsive app. All these things can’t be done in the WindowsRT version. This means that either the RT rendering engine is a multitude better than the windows version (sounds highly unlikely) or you simply can’t build responsive applications without switching to C++/DirectX.

Then there’s the whole ‘lock-in’ story. If you want to develop a Metro app that you can put in the windows app store, you’ll have to install windows 8 on your desktop, cause Visual studio 2012 will only run on this OS (potentially also on Windows 7, but definitely not on Vista, Why??). And before you can create any software for other users, you’ll need to pay. Seriously?? Are you really asking me to pay you for the privilege of making your product more attractive for your consumers by creating free apps? How is that supposed to make me feel as a developer? Granted, Google does this as well (and I wont even mention Apple). But at least, Google’s price was 4 times less then that of MS.

I guess that’s what you can expect from a personality such as this:

And this is only one side. There’s also the fact that there are still only very few Metro-tablets out there, so very few potential users. And the tablet itself isn’t very cheap either.

Granted, there are folks at MS that appear to be trying their very best getting this whole thing of the ground. I think the team that made the back-end of windows 8 at least tried to produce an OS that’s fast. And the whole developer oriented marketing machine is also doing it’s very best: their free workshops all over the world that allow you to test your apps on different hardware, seemed very attractive at first. And when I asked for my money back from the app-store, they didn’t make a fuzz about it. But all that’s just not enough to offset the deficiencies of the crippled Windows-RT OS.

So if you are like me and want to write a small app that supports both a desktop and mobile environment but you don’t have the time to write multiple mobile interfaces or want to start out with 1 before writing yet another UI, I’d pick the one with the most users, provides better features development wise and requires the least work. Oddly enough that’s android for now. And thanks to monodroid, that’s also feasible for C# devs. Pity it’s not free. Alternatively, you can simply release it as a regular windows app and put on download.com, which is also an app store after all..