Conclusion
At the end of the last section I tied off a discussion of the graphics rendering in AvalonLife with a look at its performance running a large model on a large grid. There is so much happening under the hood that I had sworn it would crawl when it came time to actually draw anything. And yet, the performance when I got it running was more than acceptible. This is interesting, but why is it notable or important? Nobody is actually going to program games in the WPF, are they? A few weeks ago I would have said “no.” Now… well, I’m not so sure. The framework is efficient and very well designed, and there is a whole layer of 2D and 3D animation support that hasn’t even been touched on here. I can see those facilities being used for some relatively low-velocity games, and if it turns out that there are good ways to interop WPF and Direct3D, such that you can use WPF and C# to script and drive the interface, and then overlay it on a rendered 3D scene, then things could get much more exciting. It’s the “overlay” part that is the problem now, as I understand it, but perhaps Microsoft will come up with a solution. Even if the graphics model works for games, there are others reasons to be wary about designing a game with thousands of on-screen objects the way this one is designed. For one thing, it eats gobs of memory. AvalonLife takes up something like 80 megs running a 100 x 100 model.