Sep
22

Fun with Arduino!

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.

Sep
16

No item should ever go un-processed

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.

Sep
05

My CV as an Infographic

I recently got an invite to a service called visualize.me, it takes data from your linked-in profile and turns it into a neat infographic. I’d like to see what the recruitment folks think. The link to my profile is below:

http://vizualize.me/0S62S_ZXAT#

Jul
24

GreenScreen for Kinect

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.

Mar
20

To share or not to share…

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.

Read the rest of this entry »

Older posts «