Continue reading »]]> So a couple of days ago my Adafruit Experiment Kit for Arduino (ARDX) arrived, and today I spent some time playing with it.

I went through the first couple of experiments but decided to go off the range a little with the second one. Instead of writing a whole bunch of code which goes through and sets individual pins, I decided to try using the Port Registers to set a whole bunch of pins at once. So, what I decided to do was make an 8-bit binary display. I had to use some Bit Math to take the lower 6 bits of the number and put them onto one port register, and the upper two onto the other port register. Thanks to Cosine Kitty for the info on Port Registers.

Here’s a video of my first pass at the experiment, with scrolling LEDs.

And here is the binary counter.

My next step will be to read bytes from the serial port and show them on the 8-bit display.

That’s all folks.

Continue reading »]]> I have recently been fixing a support incident with a system of ours which processes data in the form of CSV files emailed to an exchange mailbox. Occasionally the producer of these CSVs doesn’t form them correctly and the whole thing packs up; the item stays in the mailbox, and somebody has to go digging to fix it, and get the whole thing up and running before the backlog of data to be processed gets rather large. This has brought to light two important points about data-processing in my mind:

1. No item should ever go “un-processed” – if it fails to go down the normal handling path, it should go down an error handling path – either way it should leave the main queue.
2. There must always be a mechanism for a human to intervene, and correct (or choose to ignore) malformed data; this makes for nice error-handling path for point 1.

Continue reading »]]> Since Microsoft released the official Kinect SDK for Windows I have been doing a tiny bit of mucking around with it.

I am working on a poor-man’s “Green Screen” app which uses the Kinect’s skeleton tracking to mask out the background. I got the first stage of it working today.

I’ll post more videos as the software progresses.

Continue reading »]]> So, I’m gradually working towards making a simple fighting game, using my Kinect as the input sensor. I think initially it’ll be one person punching a punching bag, then two people competing, and then probably some sort of computer controlled AI which looks at your pose, and chooses the right pose/move accordingly (although since I don’t really know how to fight, that will be interesting).

The Experiment

Anyhow, a few weeks ago I got a very rudimentary scripting host working, where I have my rendering infrastructure written in C++, and I have a mono .NET window displaying the output etc. Well I have since improved it to allow me to create entities on-screen in a (somewhat) adhoc manner (they’re all the same entity at the moment). In doing this I decided to do an experiment to discover what we all know is true: if you have more than one instance of the same model on screen, it better be the same vertices et al in memory. My Naive version loaded the model from disk, and packed it into my renderable format in memory each time the scrip requested an entity from the engine. I wanted to do 1000 entities, but the Naive approach crashed my computer at ~380, so for my performance comparisons I only went up to 200. My second approach uses boost::flyweights to share the model amongst all the entities that use it. I performance tested this one up to 200 as well, but as you can see below it gets up to 1000 dwarves on screen quite happily.

Snow-white couldn't cook for all these guys.

The Results

I’ve also attached a bunch of graphs of the comparison between the two approaches. Obviously, the approach using the flyweights was much better than the naive approach, but there are a few interesting features on the graphs. First up is the load-times. In the naive approach the curve starts out very steep for the 1, 2, 5 and 10 dwarf runs, and then peels of to some sort of linear amount function for the rest. It seems to me like it takes at least 10 reads of a file for my Windows/my hard disk to cache the file fully. You’ll also notice that there is a tiny amount of growth in the load-times for the flyweight approach, although I think this is down to the “.” that gets printed to the console for every constructed entity (printf and its higher-level cousins are SLOW).

Load times

Next is the memory graph. The thing that strikes me here is that the memory growth appears to slow for the naive approach, which I don’t quite understand. You can also see a delta between “max” memory, and “rendering” memory. This is because the importer library loads a copy of the file into its format, then I convert from its format into vertex and index arrays, and the create vertex/index buffers out of those, and then clean everything up so that only the buffers are left. “Max” memory, therefore is during the loading phase, and “Rendering” memory is once we’ve created the buffers and cleaned up the other stuff. Note that there’s no delta between these in the flyweight approach, and as we would expect, the memory usage is constant.

Memory Usage

Finally, a graph showing something that I have not made much any better yet, and that is the frame time. I didn’t really expect any improvement, but it seems that repeatedly setting the same vertex and index buffer is slightly faster (maybe ~15%) than setting different buffers each time (I guess that’s the GPU cache being nice, or maybe the driver being smart and not actually doing anything). I am hopeful that if I do GPU instancing it’ll make the rendering much faster because the only thing I’ll have to change per entity is the world matrix.

Even the frame time was slightly improved

A Problem

I am a little uneasy with my current approach, using boost::flyweights, because the flyweight pattern assumes an immutable shared-object, and my design does the loading in two stages: the first loads from disk, and packs into my runtime format, the second actually creates the gpu-based resources. This is deliberate, partially because I don’t want to couple the disk-based loading code to my graphics API, and secondly because I want to go multi-threaded and perform the second stage in a prologue for each frame (ie, at the start of each frame the load-queue is processed, and recently loaded assets get turned into resources on the GPU). So, back to the problem: the flyweight supports get/casting to a const value_type& (value_type is your type, ie GraphicsResource), but I can’t populate the buffers inside the object if it is a const, so I had to “cast away the constness”, which felt horrible and left me feeling empty inside.

Conclusion

As I always knew, sharing a single instance of resources like models is not just a good idea, it is vitally important. Boost::flyweight is a nice pattern and removes the need to write complicated factory and handle classes, but the fact that a cast from const to non-const is required to satisfy my design smells like a two-week old dead turtle washed up on the beach. So, sharing instances is definitely the way to go, boost::flyweight just might not be the vehicle to get me there.

Continue reading »]]> I’m currently working on a project where we are using a technology called DDS (Data Distribution Service). DDS is a Publish/Subscribe technology for Inter-Process Communication. It is fast, and very flexible in terms of the Quality-of-Service that you want. Now, I have developed a framework around it so that various parts of our application need only interact with a state class, and in fact they can register to be notified of changes to properties on these state classes. These state classes effectively register an interest in a particular Topic (the fundamental unit of data within DDS, a collection of repeated fields, a single occurrence of which is called a Sample). Now, when a class uses my framework to register an interest in a particular topic, it supplies an Action<T> which is used to process Samples of the Topic in question. In some cases I have passed a C# Lambda Expression in as the Action, but I find a key problem with these lambdas is that they are very hard to test (I’m pretty much doing TDD, not quite, but pretty much). I’m leaning towards the idea that if you can’t test it easily, it isn’t all that useful as language element. I’m interested to see what people think.

Continue reading »]]> I’ve been tasked with presenting a training session at work on the new concurrent programming features in the .NET Framework 4.0, so I’ve been playing around with a Mandelbrot set visualiser for which I have written three routines: a sequential routine, a (potentially) each line can be calculated in parallel, and a third where (potentially) each pixel can be calculated in parallel. I say “potentially” because the resource manager underneath the TPL actually manages the threading for you. In essence, when using a technique like Parallel.For you create a lambda function for the loop body, any single iteration of which could be executed in parallel to any other iteration of the loop body, and the TPL takes care of scheduling these iterations across some magically optimized number of threads.

My sequential code is a nested for loop where the out loop iterates y and the inner loop iterates x. In the Parallel.For version of the visualiser I replace the outer loop with a Parallel.For like so:

Parallel.For(0, parameters.imageHeight, y =>
{
    double c_im = parameters.maxIm - y * parameters.imFactor;
    for (uint x = 0; x < parameters.imageWidth; ++x)
    {
        mandelbrotPixel(bmd, (uint)y, c_im, x);
    }
});

What this means is that the TPL will try to run as many iterations of the body of the lambda function in parallel as is sensible.

So, onto the results. I ran the same program on my work machine (Core2 Duo, 4GB RAM, Vista 32) and my home machine (Core2 Quad, 2GB RAM, Windows 7 64), and got the following results:

Test        |     Time (work)        | Time (home)
-------------------------------------------
Sequential  | 9.480s                 | 9.373s
Parallel.For| 4.540s                 | 2.451s
Nested P.F  | 4.300s                 | 2.403s

As you can see, by simply running the code on a machine with two more cores, the runtime was halved.

In order to get the run-times large enough for changes in performance to be meaningful I made the application generate a 4096 by 4096 image.

Take a look at the source code here: ParallelProgramming.zip, it’s a Visual Studio 2010 solution, but the code is fairly straightforward.