I just realized this morning that I desperately want a Shakespeare Shakespeare Revolution t-shirt.

Glorious Trainwrecks Dot Com is turning two years old on the 24th of April (less than three short weeks!), and while I don't have the stamina to put together a Year Two collection, I am planning a little birthday surprise for all of you wonderful people. But it's a secret! Shhhh.

I'm close! I've been plugging away at it for a couple of hours every other evening or so. Every time I poke at it, I get a little bit closer to cracking what I need to know, which is really pretty cool.

(To be clear: What I have is still far, far away from a full understanding of the file format that would be required to, say, write them, or put together some sort of KlikVM. But I am one structure away from pulling out proper animation data, which feels really awesome.)

Yes, it's finally here! A tool to extract graphics directly from Klik & Play .img files! Source code is included.

I'm still working on cracking the .gam format, which is a lot tougher, but will allow me to extract the graphics in the proper order, and automatically group the images by object / animation / direction.

Inspired by qrleon's painstaking hand-capture of some of Klik & Play's most glorious sprites, I decided to look into how hard it would be to crack the Klik & Play file format.

As it turns out, it wasn't really that hard at all! Reverse engineering is kind of fun. And I discovered 010 Editor in the process, which is all kinds of badass.

I'm pretty sure I now have enough information to batch extract raw bitmap data, if I just knew exactly what KNP's colour palette was. I think the simplest way to find out is just to take a screen grab of the sprite editor and slurp up the colours from that.

The on-screen colour palette maps onto colour indexes like so:

0 16 32 ... 240
1 17 33 ... 241
2 18 34 ... 242
... ... ... ... ...
15 31 48 ... 255

except for one cute trick. The first colour, 0, doesn't actually map to 0, it maps to some other black elsewhere in the palette (207, IIRC). 0 is the transparent colour.

I'm not sure yet if there's any way to tell, just given the .img file, which images correspond to which objects, animations, etc. I'm guessing that there probably isn't, which is unfortunate, as .gam files are a lot more complicated. (There's all kinds of friggin' garbage data in them.)

I've attached the 010 Binary Template that I whipped up while I was figuring out the Klik & Play .img file format, to help future generations of people who want to reverse-engineer the Klik & Play file format. I also loaded that last sentence up with keywords so that Klik & Play hackers might find this page via Google.

I really need a snappy name for this project, so I can register a domain (or at least a Sourceforge project). InfraBaby isn't really doing it for me.

So, since my last update, I've managed to completely decode the V.Smile Baby's IR format. Those last three bits that were so confusing to me were actually a combination of a very simple "repeat" bit, and two checksum bits! Once I figured out how the checksum worked, everything became clear. I've attached a small document containing the complete decoding scheme, which is actually much smaller now since I can take the raw data out for repeat codes and so forth.

The next step is to write a little script to generate the Lirc configuration file.

The step after that is to package everything up into a user-friendly bundle. Even if I don't have a nice menu or configuration method to start, it'd be good to bundle WinLIRC and automatically start it when you boot up. Not to mention building an EXE instead of requiring the end-user to install Python and the various random libraries that I'm using.

As an aside, my son enjoys AlphaBoogie, but so far he still hasn't really made the connection between pressing buttons on the controller and things happening on the TV.

IT TOTALLY WORKS

OH MAN OH MAN OH YES

Eric is in bed now, but I can't wait to let him play with Alphaboogie.

It's going pretty smoothly, actually!

I wrote a little oscilloscope program in Python that interprets the raw pulse/space data from WinLirc (pasted into text files), then gathered the data for each of the buttons. Thankfully the encoding was easy to decipher (each bit has a short pulse to start, and then a short or long space indicating one or zero; a long pulse ends each batch of sixteen bits), so it's just a matter of looking at the picture and turning it into a code. I haven't really looked at how to write the configuration file properly quite yet, but I'm sure it won't be too hard after all.

Important findings for game designers:
- The codes are the same whether you roll the trackball up or down. :(
- The "release" code appears to be the same for all buttons, so there's no possibility of holding down multiple buttons simultaneously.

EDIT! For all the V.Smile Baby hackers out there, I've attached a text file detailing the codes associated with every button. If someone is ever crazy enough to try hacking the V.Smile console itself, knowing these codes could help you out.

So my infrared reciever has arrived! And I can totally read the raw IR coming out of the V.Smile. Unforunately, WinLIRC's learning function is retarded and completely refuses to learn my weird-ass device automagically. The raw IR data that I get from WinLIRC is very unfriendly state; it's not something I can just paste into a config file, or even a visualization program, for that matter.

Looks like there's lots more reverse engineering and learning about WinLIRC configuration files in my future! Yay?