Lately a lot of discussion had the ActionScript language as its focus. People start complaining about complex language features but I think they are great because the end user will benefit from that. Yesterday evening I had my very first test with Silverlight — and I am really impressed.
It took me a short amount of time to port the strange attractor to Silverlight. I agree that this is may be not a fair comparison because I know C# already but have a look at the source code. I make heavy use of type inference and the Matrix4x4 class has the plus, multiply and array-index operator overloaded. The code is more readable. And besides: it executes really fast. Faster than my heavily optimized ActionScript version. Imagine I would write var bleh = 1.0 in ActionScript. Framerate would drop to something like zero. But this is sad since there is no reason for me to write var bleh: Number = 1.0. A modern compiler should be able to figure this out. haXe can do it, C# can do it, OCaml can do it and lots of others as well.
Remember: This was my first time using Silverlight. To achieve the same result with Flash you have to be kind of an expert in strange player and language “features”. Now tell me again that the end user will not benefit.
Lately a lot of discussion had the ActionScript language as its focus. People start complaining about complex language features but I think they are great because the end user will benefit from that. Yesterday evening I had my very first test with Silverlight -- and I am really impressed.
It took me a short amount of time to port the strange attractor to Silverlight. I agree that this is may be not a fair comparison because I know C# already but have a look at the source code. I make heavy use of type inference and the Matrix4x4 class has the plus, multiply and array-index operator overloaded. The code is more readable. And besides: it executes really fast. Faster than my heavily optimized ActionScript version. Imagine I would write var bleh = 1.0 in ActionScript. Framerate would drop to something like zero. But this is sad since there is no reason for me to write var bleh: Number = 1.0. A modern compiler should be able to figure this out. haXe can do it, C# can do it, OCaml can do it and lots of others
Everyone likes examples. So here are three examples using TDSI. The archive includes a ready-to-go FDT project with post-compile ANT tasks configured.
This is the old code of the already optimized attractor using the Memory API instead of a Vector.<uint>.
In this case there exists no Particle class at all and no linked list. The particle information is stored inside the memory as well. Particles are extended to a fourth value so indexing a particle can be done with a simple bitshift which is very fast.
The last example uses float instead of double values for the particles. The framerate stays the same which is really cool because the memory usage drops. Before a particle consisted of four doubles which is a total of 4 * 8b = 32b. In this example each particle takes up only 16b. There the memory difference is 0x4B0000b which is about 4.7mb in total.
And also the first version needs about 20mb on my machine which means about 12mb of RAM are not wasted. Pretty cool when thinking about devices with less memory.
By the way I just stumpled across a bug when using [Embed]. Hopefully it will be easy to fix.
Everyone likes examples. So here are three examples using TDSI. The archive includes a ready-to-go FDT project with post-compile ANT tasks configured.
Example01
This is the old code of the already optimized attractor using the Memory API instead of a Vector.<uint>.
Example02
In this case there exists no Particle class at all and no linked list. The particle information is stored inside the memory as well. Particles are extended to a fourth value so indexing a particle can be done with a simple bitshift which is very fast.
Example03
The last example uses float instead of double values for the particles. The framerate stays the same which is really cool because the memory usage drops. Before a particle consisted of four doubles which is a total of 4 * 8b = 32b. In this example each particle takes up only 16b. There the memory difference is 0x4B0000b which is about 4.7mb in total.
And also the first version needs about 20mb on my machine which means about 12mb of RAM are not wasted. Pretty c
