Game Jam

I made a game last weekend!  It's stupidly hard (and just plain stupid) but I'm a certain fashion of proud of it.

It began with an email I skimmed and ignored last week.  Itch (an indie-friendly gaming site and distribution platform, think Steam but with no real entry barriers) frequently hosts game jams, which are week- or weekend-long (and other durations I'm sure) events where a genre is chosen and game makers are encouraged to quickly build a new game, optionally around some given theme(s).  One-mechanic games were on the docket this time.  I generally don't have time to participate in these jams, so I paid it no mind.

Then a work buddy of mine had a case of beer on which the word "Escape" was written, split by the seam in the cardboard.  He jokingly said we needed to make a game about an ape escaping.  We had some fun chatting about that.  There could be fruits or something to collect, but you would be scolded for doing so.  "Why would you waste time collecting stuff when you should have been escaping?"  Each level could just be the displayed image, with a corresponding bit map of which pixels are grab-able.  With the one-mechanic idea freshly ignored in my brain, the ape could constantly swing his arms, and you could swap which hand he was gripping with using one key or button.  ...This could almost work out.

It's Kim's busy season (beginning of the year, accounting) so she was going to be working Saturday.  That left me plenty of time, should I choose to spend it not sleeping.

Well that was that.  Surely I'm a quick enough programmer to make a one-button game about Esc the Ape escaping!  The event kicked off, and the themes announced were "water", "capitalism", and "man versus machine".  ...Well, that was fine, those themes are optional anyway.

Kim to the rescue, as usual.  I talked to her about this ridiculous plan, and without even knowing the themes, she had a suggestion. "The ape could be collecting anything, even coins.  What does an ape need with a gold coin?"  And there it was.  I could even slap a mild capitalism theme onto this thing.

Anyway, I had already developed some rudimentary code to help turn my scribbles into animations and games.  So I made some scribbles...

...and, with a day-plus of programming, turned them into this game!  Enjoy!


https://itch.io/jam/omgjam3/rate/223986


[ afterward... ]
I got some great feedback.  Fellow indie developers are a great audience, and willing to find good nuggets even in rushed, sloppy work like this.  :^)

[ even more afterward... ]
The people who ran the game jam streamed themselves playing all of the entries.  Couldn't make it past my first level, but I have to credit them for trying.  :^)
https://www.twitch.tv/videos/228848222?t=00h51m03s

Another silly device, another silly game

The other day, a friend tipped me off to an in-development smartphone with a round display. Circular. I've used a computer mouse that shape before, and wasn't super-impressed, but until/unless I see one in person I won't make jokes.

But it got me thinking, what sort of game or toy might I create for something with a round display?  My first ideas were tilt-based, like those old BB-in-a-maze toys.  But for whatever reason, I was compelled to quickly throw this together:

http://turn-n-seek.penduin.net

It's really dumb.  You have a little view of the goal pattern (which you can scoot around to see more, but never much at once), and you turn the dials around to try to match it.  Get everything lined up within +/-5 degrees, and you win.  Then it resets, and picks a new random number of dials, segments, and colors.

As it turns out, it's a kinda fun little time-waster on a normal slab-shaped phone or tablet too.  (Note: Android's stock browser is terrible; use Firefox or Chrome instead.)

I have a running in-joke (so in, it's basically just with myself).  The more effort I put into a game or app, the less people will care about it.  For example, according to the stats on the Firefox app marketplace...
https://marketplace.firefox.com/search?author=penduinbits
My most popular app by far is a stupid QR scanner I wrote in an hour.
In distant second is Halloween Artist, which I did put some effort into.
Dead last is Picross, which was by far the most work of the few apps I have listed here.

So, by this logic, since it took no time to throw together, my new "turn & seek" game will soon have hundreds of thousands of people playing!  ;^)

Bub

The short version:

Try out a prototype of "Bub" (a game I'm developing) in your browser:

http://smogheap.gitlab.io/bub/prototype.html

The long version:

Decades ago, I started scribbling alien critters, and this little guy(?) became one of my favorites.

Over a year ago, a scribble turned out like this...

...and I mused that this incarnation might need to star in a game at some point.

Months ago, I saw a crowdfunding campaign for this wild little thing.

Called Gamebuino, it's a tiny homebrew portable gaming console powered by cheap, ubiquitous, open technology all the way down.  I needed to pitch in, and I needed to write a game for it.

The screen is small, low-resolution, and black-and-white; my game had to use simple imagery.  There are very few buttons; the controls had to be simple too.  Ork is a simple shape, so I began prototyping a low-resolution game where he could walk around.

Completely-irrelevant tangent:  I say "he", but I'm pretty sure Ork and the other inhabitants of planet Snork (gimme a break, I was 8 :^) are hermaphroditic.  I'm not sure how biology works there, but no two critters look alike or have gender by Earth standards.

Anyway!  Ork needed some actions.  Traditionally he would blow bubbles, so I thought about how he might use those to get around.  Letting him blow bubbles just anywhere just got in his way since I hadn't coded any way to jump yet.  Blowing them beneath himself and climbing up, though, that was promising.

A long list of quick experiments flew by.  Different blocks, the idea of an inventory and slurping up bubbles before blowing them, bit by bit a prototype came together.  I've shared it with a few developer friends to get their feedback (and a few level ideas!) and now I think it's time to share it with anybody who will try it.  :^)

It's still a prototype.  There's no animation, there's no nice level select menu or custom controls, there's not even any music I'm willing to have on by default.  But you can experiment, play your way through the even-numbered levels and their odd-numbered evil twin versions, and once you've got the hang of it, you can build your own levels and share them by email or twitter.

Someday, I'll have a full, animated, polished version.  I also hope to publish it on Nintendo Wii U.  In the meantime, I hope you have fun with Ork in his new game, Bub.

 

Have a Gamebuino?  Grab the .HEX and play on Bub's inspirational console!
Have a computer/tablet/phone?  Play it in your web browser!
Have an interest in tinkering beyond making levels?  Poke around in its GPL3 code!

Tong on Wii

Well here's another fine mess I've gotten myself into: Tong can now be played on Wii!

It's fitting. Back in ... 1997? Some friends and I came up with the idea, and imagined it as a multiplayer game on Nintendo64, the party machine of choice at the time. That didn't happen, of course, but years later I did finish a single-player PC version. Years after that, I ported it to the GP2X/Wiz handhelds. Now, it's come all the way to a home console, and a Nintendo one at that.

...Plus, the line-breaking sound effect is me saying "Wheeee!"

Now before you go off to the Wii Shop Channel looking for Tong, let me save you some time. Nintendo doesn't endorse this kind of open/free homebrew, but unlike some manufacturers, they don't fight it either. Read up on the Homebrew Channel, then visit this site and use its handy packager to get homebrew running on your Wii (they've made it very easy, you won't break anything!) Once you have the Homebrew Channel, you can grab Tong for Wii here; just unzip it to your SD card.

My favorite bit of feedback about Tong has always been that it's a "bad idea well implemented". Nowhere is that clearer than on Wii, with tilt-controlled paddles. I've gotten pretty good at it, but it's probably the hardest and most insane version yet. Why I would be happy about that is a bit of a mystery.

For anyone interested in the technical details, "devkitPro" and "devkitPPC" are what you're after. Cross-compiling to Wii is mostly painless, and I only ran into a few snags. First, libfat needs to be initialized before doing any file access. That isn't the first thing that occurs to those of us who normally build stuff for OSes instead of raw hardware. Second, the guys who ported SDL to Wii did a pretty good job, but when it came to SDL_mixer, I think they got it working for their own stuff and then moved on. The easiest workaround is to resample your sound data to 32000Hz, which struck me as very odd considering how common 41000 and 20500 are. Also, simultaneously playing a Mix_Music and a Mix_Chunk causes some fascinating interference if they're both using tremor (ogg vorbis decoder). In my case that meant saving the short Mix_Chunk sound effects as raw .wav data instead. Finally, as much as I love to use my own simple-as-possible Makefiles, I had a much easier time working from devkitPro's examples. They're very flexible and general-purpose, I'll give 'em that. Everything's checked in; have at the CVS repository if you're curious.

To non-geeks who waded through all that, I should reward you with something clever and witty. ...Too bad. Play Tong for a few minutes; your brain will forget all about such small-scale confusion. :^)

GIMP Color Range Mapping

[note: This first section was typed in early February]

I've been a fan of the GIMP (GNU Image Manipulation Program) for a looong time. It's helped me create and modify and fake many, many pictures over the years.

A while ago, one of its features vanished. The code behind it was a mess, and the developers didn't see its value. It would have been a pain to go through and make it work the way a modern GIMP plug-in should, so it (along with other stuff which richly deserved to get culled) was lost. Overall, GIMP got better, but a handful of people including myself really wanted our color range mapping back.

We had some tricks. An old binary of the plug-in would still load and run happily on newer versions of GIMP until pretty recently. But GIMP has moved on, and at this point, that crufty old plug-in just won't cut it.

Well, long story short:
https://bugzilla.gnome.org/show_bug.cgi?id=641893

I fixed up the code, and submitted a patch. With any luck, future versions of GIMP will include my refactor of that good ol' plug-in.

Here's what it does, if you're curious:


You define a pair of source colors (usually colors from your current image) and another pair of colors as a destination. All areas of the image that match your source colors get changed to your destination colors, and, most importantly, all colors that are in between your source color pair get translated as colors between your destination pair. It's very useful for altering images that have anti-aliasing baked in, or large patches of color with subtle-but-important variation.

...As you might see from the discussion on gnome.org, even the developers don't really understand why this is so great, so don't feel bad if you didn't follow all that. :^)

[note: the following section is from today]

I've given up trying to convince the developers to take my patch. Or even look at it, it sounds like. It's too bad, but anyone else like me who wants the feature back can apply my code and have it. I'm tempted to babble about some of the common things that open/free software gets wrong when dealing with its community, but they're largely known.

Probably, I should have brought it to them as "here's a new feature" instead of "this went away and I've revived it". Then I'd only have had to climb the shallower "not-invented-here" incline instead of the steeper "we already decided no" one. Either way I'd have still faced "why would you want to do that", which is particularly obnoxious and spans all of software (and many other areas, I'm sure).

Ahh well, live and learn. Or, just live. :^)

[update: 2011-08-19]
to patch against stable release code (as opposed to the latest from the git repository) give this a try:
http://penduin.net/projects/color-range-mapping-2.6.x.patch

[update: 2018-01-10]
If building from source is not your cup of tea, others have figured out another clever way of resurrecting this feature:
http://billauer.co.il/blog/2010/06/gimp-map-color-range-mapping-64-bit/
https://wtanaka.com/node/7904

Gee Wiz

A while ago (a year? I don't know) I bought a GP2X Wiz. It's a little Gameboy-like device which, unlike most others, is designed to be open for all developers. My first reaction to reading about it was, "hey, I could get TONG to run on that!"

...If that was gibberish to you, TONG is a game I wrote ages ago in which you are tasked with playing Tetris and Pong on the same screen at the same time. It's very hard, and I apologize to anyone who has gone insane while playing it.

Anyway, so I bought a Wiz, with the primary purpose of porting TONG to it. But I got busy, and it became a lower priority, and then it just kind of sat there neglected and forgotten for a long while.

A week or so ago I came upon it and decided to charge it up again, and load it with some games from the internet. Time to see what people who hadn't forgotten about it had accomplished. As I was browsing and downloading various free games, what did I find but TONG! Some crazy person out there had found my game, played it, enjoyed it (at least enough to want a portable version), then dug into the source code and data, made some modifications, cross-compiled it for the device, then shared the resulting package with the Wiz community. That blew my mind a bit.


Anyway I'm very pleased. It's a bit of a quick and dirty port, using a slightly older version of TONG and the music was missing, but it runs great! I'm distributing a version of it myself now, with some new features, all the music intact and using the latest code.

Has anyone seen TONG spring up anywhere else? I was hoping to get it running on the Wii at some point, has somebody done that already? :^)

Sony, Go Sue Yourself

Warning: geekiness and venting ahead!

A few years ago, a very fancy (though unimaginatively-named) gaming machine was released, the PlayStation 3. I got one, for gaming reasons (Metal Gear, primarily) and because it had a novel feature for a gaming console: the ability to run GNU/Linux (or other operating systems as well) out of the box. I get to write and run my own code on a high-end 7-core CELL system? Yes please!

Of course, games are the primary business of the system, but the "Other OS" feature was widely advertised and very appealing to people like me. Recently, though, Sony saw fit to steal that feature away from myself and thousands of other geeky, premium-paying, early-adopting, target-audience technophiles. A mandatory system update removed the functionality completely. (I sure hope Ford doesn't remove my emergency brake, just because relatively few people use it...)

So there we were, a bunch of geeks who want to write our own programs to run on our own fancy PS3s, with the rug pulled out from under us. Well, turns out that us geeks, we're kinda geeky. And some of us are pretty clever. (I use "us" rather broadly there; I personally have only a little knowledge of how the PS3 works.) Long story short, some very bright people figured out ways to once again be able to load and run our own programs on a PS3. What Sony taketh, the community giveth back.

Now, Sony has filed for restraining orders against several of the lead geeks who won us back our freedom. As best I can tell, it amounts to nothing more than a scare tactic. Nevertheless, let's boil down this chain of events:
- Sony: Buy a PS3! You can even write your own software for it!
- Geeks: Yayy! Here's lots of money!
- Sony: Mmm, money...
- Geeks: This machine is great! Gaming AND homebrew!
- Sony: Actually... no more writing your own stuff.
- Geeks: What?! We paid for that, give it back!
- Sony: No.
- Geeks: Oh look, we can still write our own stuff.
- Sony: Lawyers ATTACK!

From Sony's point of view, the new ways of running homebrew are cause for concern, because some folks will very likely figure out how to copy and play retail PS3 games they haven't paid for. (In fact, they already have.) But that's not why I care about it, and it's not why most other geeks care about it. We care because we bought a machine that we could code for, and we intend to keep it that way. We were quite happy with Sony's sanctioned, non-piracy-enabling "Other OS" feature. Once they removed it, what were we supposed to do? Stop being geeks and give up on something we already had? Have you ever met a geek? That's not how we roll.

There is a class-action lawsuit concerning Sony's mass theft, or bait-and-switch, or whatever one wants to call it. But it won't succeed; the law protects wealthy (and foreign, in this case) corporations, not consumers. The homebrew community, all of us still fans of the PS3, simply want the machine we purchased: a beefy system that plays games, shows blu-rays, and runs homebrew.

[update: the class-action case was indeed thrown out.]

That's what you sold us, Sony. That's what we all agreed to. You stole part of our own PS3s from us, and we've taken it back. If you want to sue someone for opening roads that could lead to piracy, go sue yourself.

Approaching Three Oh

For some time, I thought of 30 as a scary age. An age beyond which I would be old and unrecognizable. Given how far along I already am in the feeling-old department, and how little my appearance has changed (I've been fat, bearded, and bald since college at least), I'm less concerned about that. The number 30 still had a bit of psychological weight, though, so I decided I had to look at things differently.

In a week or two, "30" will be the layman's way of describing my age. The finger-counter's perspective. But to me and any other system software engineer, I'll be 0x1e. I'll be 00011110, and that's according to the first computer I ever hacked on. By today's standards, I'll be 0000000000000000000000000000000000000000000000000000000000011110. Just look at all those insignificant digits. How could anybody who knows anything call me "old"? :^)

Point is, I won't need an extra binary digit until I'm 32 in decimal. 0x20 hex. And the extra-bit logic works just fine for me. Time flies when you're young, so you get extra bits pretty frequently. At 2, at 4, at 8... but the next bit you need is at 16, which in my case is still holding out just fine. If I use this reasoning and set my scary "old" age at 32, then I won't have to bother with a midlife crisis until I'm 64! Then I can pop my meds, buy a hotrod hovercar and blast that Beatles song loud enough to drown out the tinnitus.

After that, I can measure life as a countdown to 128. Anything beyond that's an awfully big bonus, at least by modern reckoning. Even with leaps and bounds in medicine and cheese-healthification, I don't see having any chance of overflowing even the trusty ol' Apple II's native integer. And, if by saying that, I'm jinxing my own life upon turning 256, well, so be it.

But thirty? Hardly seems worth mentioning. Multiples of ten are for chumps. In fact, forget I even said anything. ...Thirty. Pff.

Does Not Compute

I grew up with an Apple IIe. Six expansion slots, color graphics, dual 5.25" floppy drives, but most importantly, BASIC in firmware. I was writing programs before I even really understood what that meant. To use the computer was to program it, and I couldn't have been happier. Sure, pre-compiled programs like Print Shop and Mario Bros were fun, but making my own stuff, that's what I liked best. That's where the magic was.

I was really, really lucky. I grew up at just the right time. To own a computer was to be a computer enthusiast. It wasn't a means to an end; the point of having the thing was to mess around with it. It could certainly be used to do useful work, but it was every bit as common (and easy) to use it as a toy.

(Begin hearing the "old man" voice in your head at this point.)

Modern computing does not compute! Computers nowadays don't come with any (programming language) interpreters built into ROM. Or pre-installed on their hard disks, as might be more appropriate. The closest you can come to writing programs out-of-the-box today is to use a featureless text editor to write some javascript and run it in a web browser.

<script type="text/javascript">
alert("Hello World, this sucks!");
</script>

Now, the way I learned to be a programmer isn't the only right way. But doing BASIC, being taught C, and picking up on everything else was a pretty fun and natural progression. There are entire college computer science tracks now that don't teach C at all anymore, instead using Java or something. It's not bad to learn Java, but I would argue that learning C is more important, if what you care about is computer science. If you care about crafting cookie-cutter corporate apps quickly, Java's where it's at. But if you care about what's going on, or if you like the idea of a computer as a toy, C is really important. The rub is that it's an awful language to write your first program in. My brain, anyway, wasn't ready for it until I'd done something simpler first.

That's where BASIC came in, and where something like Python could come in today. A person's first program shouldn't be graphical. It shouldn't be run in a web browser. It would be nice if it didn't have to import any libraries. And it would be great if there was a realtime interpreter console, something to try out commands and code chunks before saving them in a file. Apple's flavour of BASIC did all of that, and Python does too.

Python is free in all senses of the word, and runs on any platform. The only problem is, it's not just waiting there on any computer one might buy. Before you can do anything with it, you must learn of its existence, find it, download it, and install it. To me, that's tragic. That's depriving little 5-year-old me's all over the world of something really special. It would be trivial to include in any desktop operating system, and could be presented much more nicely than BASIC was back in the day. In the Start menu, or the Apple menu, or on the desktop, or at whatever handy spot user consults regularly, there ought to be a "Create Programs" menu/folder/whatever. It should contain an interpreter, a decent text editor, a language reference, and a quick start guide to explain what those other things are and how to use them. Why isn't this done?

I understand there's not much consumer demand for this kind of thing. Joe Schmoe wants to buy a computer in order to click around on web pages and print term papers, not as a toy to write his own programs for. But I think that could change, if it was widely understood that software can be made by individual people in a matter of minutes. Sure, it won't be the same as software that comes from big corporations on 18-month release cycles, but why does that matter? MySpace pages, YouTube videos, and blogs, aren't the same as designer-comissioned websites, Hollywood films, and professional journalism. It doesn't matter. Joe Schmoe cares about that stuff anyway.

Microsoft, Apple, Dell, HP, somebody... Put Python on the desktop! Add a notice that you don't provide Python support, with a link to python.org, and you can forget all about it. It wouldn't even have to be Python, that's just my opinion of a good introductory programming language. But for cripe's sake, make it happen! There should be a way to be introduced to programming on every computer out there. The fact that there isn't, just doesn't make sense. It's illogical. It doesn't add up. ... Oh, surely there's a phrase that explains the situation.

Pi compression

This idea I've had for a long time, and if it were mathematically and computationally feasable, it would probably have already been done. But never mind all that. I still like the idea, and I'm still going to spout it off.

I chose pi because I just like it, but e or any of those other fun infinite-digit, non-repeating numbers would probably work, and possibly be better. An unfathomably good pseudo-random number generator might even work. But let's call it pi for now, because the important thing is that it's this infinite sequence in which, theoretically, every possible sub-sequence exists. Somewhere in that infinitely-long series of digits, there'll be a hundred sequential zeros. Somewhere, there'll be a million. And somewhere, there'll be a sequence that matches the sequence of ASCII values for this blog entry, and every other text you've ever read (and ever will read... but that's a different story).

The idea is, whatever data you have, your term paper, that movie you swear you didn't download, or that log of leaked AOL searches, that data is already encoded somewhere in Pi. It may be several centillion digits out, but it's there. Theoretically, you just need to let a grep algorithm slide along Pi until it finds a match, and then just remember the offset and the length to get it back out. Suddenly all files, all volumes, all anything, can be represented by two numbers.

Parts of this have already been implemented, though on a scale much too small to be useful. (Four billion binary digits of Pi? Pff, weak sauce.)
Finding sequences in pi:
http://pi.nersc.gov/
Getting hex digits (half-bytes) out of pi:
http://www.geocities.com/hjsmithh/Pi/PiQPCpp.html

Our CPUs' abilities to crunch numbers aren't advancing as fast as our networks' abilities to pump big bunches of data around, so this whole thing isn't terribly practical. Still, you could back up your whole hard drive on a floppy diskette. The idea is fun even if it wouldn't be worth doing.

Let's take it a little further, though. Maybe we can still do something useful with those first four billion binary digits. Play around with that Pi-search link above. It only uses a 5-bit character set rather than ASCII's 8, but let's experiment anyway. I'm going to search for "penduin".
In 5-bit-per-character binary, that's:
10000001010111000100101010100101110The sequence is found at 8748556 binary digits in. 8748556 in binary is:
100001010111111000001100
...that's a noticably smaller sequence than the binary representation of "penduin". Our data is 7 "bytes" long, which in binary is:
111
Those two numbers, the offset and length, happen to take fewer bits to represent than the string "penduin", in ascii or even in 5-bit characters. Houston, we have compression! But hang on, let's say that sequence didn't happen within 4 billion bits of pi (according to that site, an arbitrary 7-character sequence has just an 11% chance of being found that early). We could still find "pend" and "uin", though - the odds of finding three or four letters are essentially 100%. If we do that, though, we'd need more bits than the raw ascii just to keep the two offset/length pairs, let alone any padding we'd need for any sanely-packed descriptor.

That packed descriptor would be 35 bits per chunk: 32 bits (maximum value: 4,294,967,295) for offset, and 3 bits for length. Why 3? We're unlikely to find an arbitrary 8-letter pattern (8 is 4 digits, 1000 in binary) in just the first 4 billion bits of pi, so our algorithm won't even try. So every 35 bits in our "compressed" file points to the next up-to-7-letter chunk of our data. On a good day, that'll beat ASCII, which would take 56 bits to store 7 letters. But, we're still playing with 5-bit characters, a paltry subset of ASCII. We're also playing with odds where only 11% of our chunks will be able to point to the maximum 7 characters.

Looking at hex digits instead of 5-bit letters gives us a better picture of how useful this might be. Any byte (8 bits) can be expressed in 2 hex digits. Any four sequential bytes has about a 60% chance of being found in these first four billion bits of pi, and sequences of three and a half (7 hex digits) are pretty much guaranteed. 7 was the maximum length of our chunks from before anyway, so let's keep using that. So, to recap:
With our 35 bits descriptor, we can know where in pi to find up to three and a half bytes, or 28 bits, of data.
...
As far as compression algorithms go, that doesn't seem particularly good. :^) But we're chopping into 3.5-byte pieces or less because of the near statistical certainty of finding any 3.5 bytes in the first half-gigabyte of pi (four billion bits). Give us twice as many digits of pi, and we'd only need one more address bit, plus another bit or so for length, as longer patterns would have improved odds of being found. Keep bumping up the searchable pi digits and we could eventually hit a sweet spot beyond which we'd actually be able save disk space. Once that happens, we can keep on increasing the available pi digits to achieve better compression, but more interestingly, we can add another layer of logic in which we take our packed bits, chunk them up, and look for those sequences in pi. If we're going to do that, we need to pack an extra bit for each chunk to say either "I point to data" or "I point to a pointer", but if we've got so many pi digits to search that we're actually saving space every time, we can still wind up with simply a pi digit offset and size, which would lead to a lot more lookups, and eventually, chunk by chunk, the data we care about.
A tip of the hat to the first person to find this post within pi. It's there! Extra points if you also find my next post before I post it. :^)

edit from much much later:
I'm glad people keep finding this post and having fun with the idea!  I'm sorry to have gotten anybody's hopes up, but this is one of those fun ideas that is impossible in practice.  (Well it's possible, it just can't achieve any data compression.  :^)  See the comments below, including my own, for reasons this doesn't and can't work.

AI-engineered codecs?

Someone else has probably had this idea, and someone else has probably explained it better than I'll be able to. Someone else yet has probably proved that the whole thing's implausible. Nuts to them; I have a fleeting thought and I'm going to publish it! :^)

I'm not very well-versed in either genetic algorithms or neural networks, but neither are those just buzzwords to me - I have written genetic and neural equivalents of "Hello world". The techniques differ, and stacking layers of these algorithms has different effects, but the thing that makes them interesting (to me, at the moment) is that we wind up with a computational system without the programmer having to actually solve the problem. A typical neural network will take a piece of input (say, a scanned image of a paper) and produce some output (say, a set of bounding box coordinates of each interpreted dark blob on the image). These outputs may then be the input of another neural net which produces some more output (say, ASCII characters interpreted given those dark blobs) and/or a non-neural algorithm that just looks for patterns (say, a spellchecker). Writing an actual algorithm to turn an image of a paper into a text stream would be massively hard, but writing and training some neural nets is much less painful. Let the computer do the computing.

In the world of Free software (free as in liberty), a world in which I happily live, there are some struggles happening around various proprietary formats. A while back, Unisys declared to the world that they owned math and thus we all had to pay royalties if we wanted to use .gif files. That particular software patent has since expired, but nowadays there are companies convinced that they own the math necessary to encode and decode MP3's and such, and even worse, there are widely-used formats like Apple's "Sorensen" QuickTime and Microsoft's Windows Media for which no Free codecs exist. There's not much motivation for someone to hack such things up, either, as they'd be sued into oblivion the moment their code became useful. God bless the US, eh?

Forget reverse-engineering, forget exploiting the closed code, and especially forget paying big corporations royalties for the privilege of doing math. I propose that it might be possible and worthwhile to write some AI to figure out these pesky formats for us. We have input, say a QuickTime .mov file, and we have the desired output. (Scrape all the raw bitmap image data and all the output audio. It'll be huge, but that's our target.) I don't know what sort of scale, how many layers, or what ghastly amounts of memory and floating-point muscle it would take to set up and train a neural net to get from point A.mov to point B.raw for any given movie, but I doubt it's impossible. Flip the input and output to train an encoder. Not too shabby!

I know even less about genetic algorithms than I do neural nets, but maybe they are better equipped to solve the problem. Plenty of other AI techniques are out there too; perhaps some combination of them would be the optimal approach. The idea is to have a program reinvent codec wheels for us, since others won't share their wheel understanding.

Shackles begone! One way or another, we need to get to the point where the format is irrelevant, only the data matters.