First, do you know Lev Grossman? He's an incredibly talented author who recently toured Portland. If you haven't read his book The Magicians, then stop whatever you're doing and procure a copy immediately. Without trying to spoil anything, the major college in the book is named the Brakebills College for Magical Pedagogy. Lev saw the Brakebills T-shirt that I designed for my sweetheart's birthday present:

Long story short, my Brakebills shirts are now officially endorsed by the author! Please buy twenty of them, or thirty if the spirit moves you. Zazzle's print quality is great. The colors are vivid, and the ink has survived many washings. Rabid fans are buying and even customizing them! I love the internet.

Lev blogged some of my other work, too ("the guy who does this has the enviably fake-sounding name of Zach Archer"). It's true, I have an awesome pro wrestler name.

Second, my new iPhone app has landed in the App Store:

Twang is a handheld guitar. It's easier to play than a real guitar, and is very expressive. Instead of using audio samples, Twang uses physical modelling techniques to create a more natural, dynamic sound. No two plucks are identical. Watch my grainy first video if you disbelieve.

In the next version of Twang, left-handed people will be able to switch Twang's orientation, and serious musicians can dampen or mute strings with their fingers. And probably more! This version is already in development, and may be submitted in a week or two? Follow Control Z, Inc on Twitter if you have a ravenous thirst for updates!

More »

Here's something from the vaults. Aquasound was built with these requirements in mind:

• Generate sounds that aquatic animals might make
• Sounds can be "combined" somehow
• Sounds can emote

This was never used in production. I wonder if I could turn this into something? Like a paid iPhone app? ;)

Double-click the envelopes to add/remove control points. Drag lines up & down to change their curviture. The best feature is the "Combine With" dropdown, which splices the current sound with your selection. Also the "Emote" menu will play sounds with different expression.

The audio algorithm is reverse-engineered from my beloved FS1R. I generated formants in two ways (toggle the "Tonal" checkbox to hear both), the "atonal" version is closer to ring modulation than actual formants. It's more fun if you don't understand what the controls are doing, but if you insist: Pitch controls the overall pitch of the sound. Freq controls the center frequency of the formant (like a bandpass filter). LFOFreq and LFOWeight control a low-frequency sine wave, which can be applied to other controls via their "___LFOAmt" curves. Amp is amplitude, Width is formant width (think: width of the bandpass filter), Skirt adds distortion. Each voice has two formant generators, check "Formant Active" to enable them.

May all your bloops and crackles be happy ones!

More »

Here's my second batch of image reconstruction using Times New Roman characters. The algorithm is a brute-force affair: New characters are colored & positioned randomly. Any characters that make the canvas look more like the original image are saved. And that's about it. Oh, and the font sizes start large (5120pt) and end small (10pt), so that fine details have a chance of survival.

Time lapse of the Mona Lisa reconstruction on YouTube, with silly music.

My first batch uses a different algorithm. Each canvas allocates a certain quantity of letters, and progressively mutates them, trying to mimic the original image as closely as possible. This technique is more akin to image compression. This batch is still in progress, it's very slow. I'll post these when they're ready!

More »

This took about 5 weeks to develop. Meanwhile, I've started another app, and I envision releasing Metal Mouth 2.0 in a few months, with more voices, and the ability to record audio.

More »

I spent a couple hours generating strange attractors in Flash, just a simple 2D version for now. Click to play:

Click the black region to generate new polynomial coefficients and redraw. You will have to click many times to generate something interesting. That's the nature of fractals, I'm afraid. Some coefficients are automatically thrown out if the drawing exceeds a certain size. Unfortunately, the inverse is not true: the code isn't smart enough to trash any drawings that shrink to microscopic size.

I believe that you can stabilize any coefficients by scaling the values of each coefficient, gradually nudging them larger/smaller until the drawing is stable. I'll try this when I get more time. I've been gung-ho on my first proper iPhone app, trying to finish it before Christmas! Stay tuned...

Also, here's the source code for the strange attractor harness! Enjoy.

More »

Today I noticed that if you right-click on yesterday's SWF and show the redraw regions, you can see that it's redrawing the contents of the entire stage, even though I put the scene in a scrollRect. Is it seriously rendering a scene that's thousands of pixels wide before displaying it ?!?!?!? Oh, no. No they DIDN'T.

Today I ported the scene to the Away3D rendering engine. Here's the result:

It's beautiful, and provides access to low-level drawing routines, light sources, normal maps, ... It was speedy at first, then slowed down considerably when I added the glowing floors. (Each glow is 16+ triangles right now, for various reasons including: I can't render objects in my own custom order.) This makes yesterday's version look performant, I'm reluctant to admit.

Possible next steps:

• Reduce the native 3D rendering area, see if performance improves?
• Grow beyond Flash, embrace the future and try Unity 3D?
• Dump this project, finish that iPhone game I started, make a million dollars in 2 weeks?

More »

Click to set the focus. Use the arrow keys to move. Touch blocks to illuminate.

I'm disappointed with two things:

1). How much time is required to create a 3D engine, even a grid-based one like mine. I've been wrestling this project for 4+ hours every day, for a week. I feel like I must be lagging behind, but there are ten thousand things that will go wrong when developing in 3D. The paradigm is uniquely punishing, there are always edge cases where some polygons aren't drawn correctly. This project hasn't been a joy.

Also:

2). Flash's native 3D is not suited for a high-performance application like this one. It would be fine if I was only spinning a few DisplayObjects in space. However, the scene above displays up to 125 Bitmaps simultaneously. (Light all 25 bulbs (3 Bitmaps each), stand in the corner facing them, and the 25-segment walls.) 125 Bitmaps would be child's play in OpenGL. But after you light a few blocks, Flash Player chokes pretty hard.

Here's another version that uses a BlendMode on the lightbulbs. It looks great, but its performance is even less acceptable.

Here's an early version that uses my own 3D computations, and the Graphics API. Also it has a limited field of view, which I widened for the latest builds. The performance is surprisingly high. I abandoned my custom 3D when I reached this point; drawing lines around each cube face was expensive, so I switched to Bitmaps, and the native 3D.

The cube faces are set to width & height of 100. However, the bitmaps are higher resolution, a 200x200 region is shown. They're being downsampled at 100x100 before they're rendered, not by my choice.

At runtime, I get periodic warnings like these:

Warning: 3D DisplayObject will not render. Its dimensions (8238, 1628) are too large to be drawn.

What?! How is this happening? I swear that any blocks behind the camera are being removed from the Stage. (Actually, this is difficult to verify. If I shrink the scene, Flash magically applies the 3D perspective with a weird projection, and distorts everything in Lovecraftian dimensions.) Please, Adobe, tell me that you're not rendering the scene at 8000 pixels wide, then scaling it down to my 700x400 window, frame after frame?

Also note that you, the developer, are responsible for drawing the DisplayObjects in the correct depth order (farthest to nearest), Flash doesn't handle it automatically. This is known as "2.5D", and it's wildly inconvenient.

So, I'm pretty disappointed with Flash 10's native 3D. Even with my limited 3D experience, I dislike how it renders the scene (I'm not alone in this) and the performance is obviously sub-par. This technology will not bring 3D games to the web, it cannot.

I need to decide whether to endure its shortcomings for 4 more weeks, or if I should abandon this project altogether. There are moments when you realize you've outgrown something you used to love, and this may be one of mine.

More »

Recently, I learned about Linear Predictive Coding ("LPC"). This technique is used in classic arcade games (such as Gauntlet) and the Speak & Spell to synthesize speech.

Here's my first attempt at LPC speech in Flash: (click & explore)

It's great, except for one tiny problem: It sounds horrific. Can you feel the cold, robotic love? This voice will stalk your nightmares.

The phonemes were derived from an unrehearsed recording of my voice. I'm confident that it can be improved. Note that direct LPC encodings of my voice, such as this one, sound more acceptable.

EDIT: I made an iPhone version, "Metal Mouth", with lots of features. Here it is on YouTube and the iTunes Store!

More »

(You will need Flash Player 10.)

Ten days have elapsed since I shared this version with friends (who are unwittingly being used as play testers). It's time for a "wrap-up" meeting, because I want to examine what went wrong/right, and instead of a meeting it's a blog post:

The tile engine has existed for half a year. Toaster Bro began its life as "Roomhack", one of the pet projects Miles and I dreamed up -- could we create a game that was Turing complete? In the tradition of Robot Odyssey, we wanted to create an experience that was both programmable and entertaining.

During the development of Space Kitty, we used its script engine to change the rules of the game at runtime. Once, we configured a cat to act as an "attack cat", which chased (and kicked) the player. We discovered new modes of gameplay -- how long can you say aloft? Can you slingshot yourself around a dense star? (Ultimately, we ran out of time before we could make the Kitty-verse bigger. We're currently discussing a Space Kitty sequel.)

The script engine whet our appetite -- what if the player could modify the rules of the game itself? What happens to the gameplay? Can it remain challenging and fun? We talked about this for days, weeks... Hashing out ideas for an "ultimate" hacker game. I think we're still talking about it.

I imagined such a game would resemble a dark, apocalyptic 3/4 view basement crawl, reminiscent of:

So I built the tile engine. The plot & aesthetic of the game were still unknown. Tavvv challenged me to invent a "missing" console from the NES-SNES era, devise hardware specs for it, and develop the game in accordance to the hardware specs. Constraints fuel creativity, right? I settled on SNES-era hardware, with a custom color engine, and improved sound. Television artifacts & blur could be exaggerated to make the game creepier; bosses would have extra blur and distortions, so you couldn't get a clear image of them. The lurking horror. This concept was eventually dropped, once I realized that I'm not ready to develop a Turing-complete game... yet. I'll come back to this project in the future, I'm sure.

"The tile game" evolved into a shooter, much like Smash TV but with a heavy-handed political bent. That still didn't feel right, even with "a spider-tank with Richard Nixon's head" in tow. In the middle of this confusion, we realized that putting hackable terminals in a tile-based game detracted from the appeal of both. Is there a way to allow hacking, within the context of a tile engine? From this fray emerged the Toaster Bro mechanic. I rolled a quick proof-of-concept. It seemed like we were on to something.

Then the game sat in stasis for a few months, while I worked and tended to life. I wanted to finish one solid level, and I imagined a 4-week timeline:

• Week 1: Engine Malarky. Moving between rooms, easier wire drawing, electricity & fire shouldn't hurt you, remove crufty code.
• Week 2: Levels & Art.. Finalize the plot & characters, somewhat. Replace stand-in art with "real" art. On-screen text. Create a bunch of rooms.
• Week 3: Audio, splash screen, boss fight, begin testing.
• Week 4: Music, ???

This seemed like a good plan. Work began, but here's how things really went down:

Week 1: Plugged lots of holes in the engine, but a single week wasn't enough to tackle everything. There are major structural implications when you modify your game's core. Still no way to change blocks at runtime, yet. I need a scripting engine, but I want one with infix notation (Space Kitty used various postfix notation languages, before Miles settled on an implementation of the PostScript language I think? It made my brain bleed.) I didn't allot time for creating a scripting engine, but clearly there was a need for it.

Week 2: I'm not sure how the 8-bit NES aesthetic won out, but I liked it because it entailed fewer artistic decisions. The aesthetic had an entire era of gaming backing it. This seemed like a wise choice, because I'm not an accomplished artist, nor designer. I'm partially colorblind, in fact. Could I still cobble together pixel art?

I bought a Wacom tablet and books on animation, hoping to produce an acceptable look & feel. By the way, nearly every graphic in the game has been redrawn at least once. You should have seen the original sideways animation for Toaster Bro, it took a few tries to make him look non-crippled.

So I had a decent lead on the art, but bugs kept popping up. Fundamental pieces of the puzzle were still missing (no scripting engine, no on-screen text, player can't die).

Week 3: I caught a bad cold, so I spent most of this week supine on the couch. I forced the "game" on a few people, and collected their feedback. All the responses were valuable, and people raised issues that I hadn't considered. One tester said he couldn't view the entire window, he was on a MacBook with its standard (small) screen. Oops! Sorry about that... I reduced the console's "pixel" size.

The upshot of being sick was having lots of quiet time, during which I (slowly, groggily) puzzled out the scripting engine. Here's what the scripting language looks like now, this is extracted from the first room on the Dark Chocolate level:

function clubDoor_electricity {
	i.isDoorOpen = true;
	call o.setBlock '__' 7 4; // empty space
	call o.setBlock '__' 7 5;
	call o.playSound 'doorOpen';
	call o.emotePlayer 'happy' 75;
}

function clubDoor_stop {
	if(i.isDoorOpen == true) {
		i.isDoorOpen = false;
		call o.setBlock '$L' 7 4; // lock
		call o.setBlock '$L' 7 5;
		call o.playSound 'doorClose';
		call o.emotePlayer 'sad' 75;
	}
}

The interpreter supports a large syntax, including: loops, switch/case statements, tons of operators, enterFrame yields, userInput yields, recursion ... You get the idea. Variables are always referenced through a few specific objects, right now these are: thread, interpreter, owner (this is the Room that created the Interpreter instance), level, and global (or game). (These are all dynamic objects except for owner.) The script engine is decoupled from the code, I wrote a harness for it.

Also the 8-bit NTSC artifacts happened during week 3, somehow.

At this point, the game had a mere 3 rooms, all unsightly geometric slogs used for testing. Uh oh.

Week 4: Still a bit sick, and my real-world work schedule poked its head in, and needed some attention. The list of bugs & issues was huge; 30 items, including toughies like art and program flow.

I forced myself to draw the dreaded sprite animations. Infrequently, this was relaxing and zen-like. But in the wrong state of mind, it was taxing and disheartening. I'm using the palette swap trick from Space Kitty, so I stared at grotesque red, green and blue images all day, and felt sorry for myself. Definitely out of my league.

Also I hacked together a level editor using Flex components, accessible through a magic keystroke. It's buggy and non-intuitive, but it's better than editing the room layouts as raw ascii! Here's how the final room in Mom's Kitchen is stored:

[P,d [P,d [P,d [P,d [P,d [f,d ..,d ..,d ..,d ..,d [d,d [P,d [P,d [P,d [P,d [P,d
[P,d [P,d [P,d [P,d [P,d [f,d ..,d ..,a ..,a ..,d [d,d [P,d [P,d [P,d [P,d [P,d
[j,d [P,d [P,d [P,d [P,d [F,d ..,d ..,a ..,a ..,d [D,d [P,d [P,d [P,d [P,d [k,d
[J,d [h,d [h,d [h,d [h,d [i,d ..,d ..,d ..,d ..,d [g,d [h,d [h,d [h,d [h,d [K,d
[f,d ..;n ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;p [d,d
[f,d ..;q ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d ..;q [d,d
[f,d ..;q ..,d ..,a ..,a ..,a #a,a #a,a #a,a #a,a ..,a ..,a ..,a ..,d ..;q [d,d
[f,d ..;q ..,d ..,a ..,a ..,a #a,a #a,a #t,a #a,a ..,a ..,a ..,a ..,d ..;q [d,d
[f,d ..;q ..,d ..,a ..,a ..,a __,a ..,a ..,a ..,a ..,a ..,a ..,a ..,d ..;q [d,d
[F,d ..;q __,d __,d __,d __,d ..,d ..,d ..,d ..,d ..,d ..,d ..,d __,d ..;q [D,d
[i,d ..;r ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;o ..;s [g,d

I resolved to ride my bike every day, to avoid getting sick again. So far so good, but now I ride to coffee shops and spend a metric crapload of money dining out of the house. The hidden price of wellness...

Week 5: The list grew even longer. Lots of bugs, lots of missing features that I didn't consider -- the heart containers, the health bar. Dark Chocolate's level was half done. The entity behaviors were unstable; the damage system was finicky, every Entity required too much configuration to properly interact with others. This needed an overhaul. I'd started thinking about unit testing, which I'd never tried before.

I drew Dark Chocolate, but with no behavioral code, he didn't move. Fun fact: I saw his animation in a dream.

Week 6: Dark Chocolate's level was finished, mostly. The boss fight took a day and a half to get right. You still couldn't "win" a level. I always joked that the goal was to plug in a toaster. Hmmmmm...

Weeks 7-9: Sound design, on-screen text, Mom's kitchen (the training level), giant toasters. Redrawing sprites. Bigger croissants (the laser-guards). Spotlights. Refactoring lots of code. The scripting engine is versatile, but not easy to use. In week 7, it was much clunkier than the syntax listed above. There were no switch statements, you had to write a list of consecutive if statements instead.

Days passed. The spit 'n polish phase took forever. I sympathize with whoever said, "your code is always 85% done". It sure felt that way.

Also I finally implemented unit testing. I tried ASUnit first, but it's not very Flash-like; I believe it's a direct port of JUnit (as evidenced by the Java code in its comments). If I'd realized FlexUnit was still in development, then I would have jumped on it, but... Long story short: I wanted to display failed tests on the stage, and ASUnit made that difficult. So I threw out the ASUnit code, kept my custom TestCase subclasses, and wrote my own Flash-centric versions of a TestRunner and TestCase (they both extend Sprite).

I can compile Toaster Bro in two ways: I have a Main.as class which will compile in the Flash IDE. But there's also a Roomhack.mxml wrapper which creates a "developer" build, integrating the testing framework and level editor. When the developer build is launched, it runs every TestCase. If a TestCase fails, and if it has added children, then it's displayed on the stage, with diagnostic messages & an execution trace. Failed TestCases can be dismissed with a click. I'm not "in love" with unit testing yet, perhaps because writing the tests after the code was tedious. I'm sure it will save my butt in the future, tho.

Week 10: Toaster Bro alpha is unleashed on the world!

Overall, feedback has been positive. Like Space Kitty, most people want the game to be longer. The negative feedback has been very helpful, pointing out specific problems which aren't obvious to me, since I view the application as a whole now.

So, after writing this gigantic treatise, I figured I'd have some insights on how to improve the process. And you know what? I don't.

Gamasutra had an excellent article on rapid prototyping, and their process echoes what we experienced on Toaster Bro and Space Kitty: Creativity can't be scheduled, and you'll spend a huge chunk of time germinating the idea in your head. We had 2 months to develop Space Kitty; we spent almost exactly 1 month dreaming up the idea. After that, the initial prototype took a day or two, and we were rolling.

With Toaster Bro, nearly half of the "serious" development time went towards polishing the game and making it presentable. This was a surprise, even though most of my interactive work has followed this pattern, too. The functional code is fairly easy to develop, but then you must meet the clients' standards, and hammer the UI to find the rough spots.

Sound effects gave Toaster Bro an air of legitimacy. The difference was like night and day. Without sound effects, it was a shaky graphics demo; with sound effects, it felt alive. Hard to explain unless you've witnessed it.

Testers will comment on all the broken windows they find. I still hear about the missing sound effects in Toaster Bro (and yes, there are plenty!) But that's okay, their feedback is always valuable. Occasionally they'll have solid ideas on how best to fix a broken window, too.

What happens now? I have to produce more levels, art, and script. I'd like to believe that my productivity will ramp up, with so much of the infrastructure and assets completed. Sadly, I don't think it works that way. I have big ideas for the remaining Toaster Bro levels, and these involve intense scripting. The second room of Mom's Kitchen (where Toaster Bro learns how to use a wire, via 4 simple dialogs) is 131 lines of script, and it's still not done -- Mom should rush in and cheer after you activate the toaster, right? I can only imagine the length of the equivalent code in AS3. I want big effects & easter eggs. It will be difficult to develop and test these.

Whatever skills you have, I recommend bringing these into your projects, and emphasizing them, even leaning on them. I produce groovy electronic music, so I made a bunch of chiptunes early on, to help center my thinking. Some aren't useable for Toaster Bro, they're too active -- they have the pace of Mega Man, rather than Zelda. It was good to realize that, it helped shape my thinking.

More to come?...

More »

Click the animation to change scale & scroll speed.

Source code & .fla: nes_ntsc.zip

The .pbk code is not optimized yet. The code is fairly explicit, I tried to explain how it works in the comments. Blargg's pages have better explanations tho.

The test harness lets you select two flavors of the effect. The numbers 8 and 12 denote the width of the lowpass window used for applying crosstalk. 12 is more processor-intensive, but will look "smoother", which may not be what you want. The mathematics can be reduced to a few (long) lines, which should reduce processor overhead; I want to do this in the future. unic0rn left some nice comments suggesting more routes to optimization.

The filter still needs some tuning. Areas of solid (non-black) color have diagonal stripes in them. I believe that normalizing the strengths of the filters will fix this.

To be continued...

More »

Also I had 2 notable mentions with Sea Sphere and 3D Sketch. I figured my entry The w00t Quilt would have placed, but perhaps I'm just easily hypnotized...

I think the strongest entry was Diagonal Snake by @tomee6, which is (not coincidentally) also one of the winners. Move the mouse to attract the snake; you lose when the snake crosses itself or touches you. There's even a death animation. Amazing.

Here's looking forward to round 2...

More »

Check out the rules, and the results. Oh man, I was hooked.

I admit, I'm suspicious of Twitter's usefulness in the grand scheme of things. You're allowed 140 characters, eh? You can only communicate the big picture; blipverts. Twitter is addictive because it doesn't require any commitment -- it takes 10 seconds to "tweet". You can tweet like mad. You can tweet at any moment of the day, even from your phone. You can abuse the Twitter API, and post non-human-readable text (such as tweetcode), which will drive your friends crazy.

Having said that... It was stunning to watch everyone create beauty in the face of the 140-character limit. Constraints fuel creativity. Here's what I came up with:

• The w00t Quilt
• 3D Sketch
• Ghost Marquee
• Sea Sphere
• Sound Effects. Move the mouse for FM synthesis. (Caution: kinda loud.)

Many people posted entries that blew my mind. Some favorites:

• @oskitar: The Day The Earth Stood Still
• @og2t:My 1st Tweetcode
• @flashpadawan: 3D Particle Emitter. Custom 3D rendering!
• @kalisnik: Grass in the Wind
• @piXelero: Inversemapping, and Tweetcoding With Recursion (probably my favorite examples of beautiful recursion)
• @pantaa: Alien Lifeform
• @rmdesign: Jellycube
• @Quasimondo: Hyperdrive

Who am I kidding, I have too many favorites to list. The most interesting aspect was watching personalities emerge, as people submitted multiple entries.

I'm sure I could have crammed more features in my code; I remembered the comma operator late in the game, which lets you shorten

if(condition){doThis;doThat}

into

if(condition)doThis,doThat

You just saved two whole characters!! Epic savings, there. Now I find myself tightening up my "real" code: using multiple assignment, and increment/decrement operators within expressions. Back when I studied Perl, I feared this: You can cram an entire script onto one line, how clever!.. "Clever" code doesn't seem smart later, when you have to maintain it.

Cheers to Grant Skinner for developing the contest, and to all the judges who are about to wade through hundreds of entries -- we salute you. Here's looking forward to Tweetcoding: The Sequel!

More »

Like the era-defining DX7, the FS1R is an FM Synthesizer, but it boasts a massive 8 operators per voice, compared to 6 in the DX. And the FS1R sports a new toy, Formant Synthesis, capable of mimicking voices, human and otherwise! Waves and formants can modulate each other in 88 different configurations. Top that off with LFOs, filters, on-board effects... It's so flexible, and so complicated. So much power.

The FS1R was the last of Yamaha's FM synthesizers, and that's no accident. Even by 1998 standards, this thing dwells in a deep abyss of user-unfriendliness. Without a GUI, you must program 1,000+ parameters using 15 tiny buttons on the front panel. Fortunately, K_Take has developed FS1R Editor Software which lets you load/save patches, and twiddle the internals in real time (thanks K_Take!)

The unit sold poorly and was discontinued after 2 short years (long before a proper GUI emerged). I didn't know the FS1R existed, until Tavvv of the Braindead Monkeys mentioned it might be something my brain would enjoy -- Weird vocal effects! Technical crazy-sauce! Aural blasphemy!

Thus, the hunt was on. After two months, I had a single nibble -- a unit appeared on eBay, and I became its adoptive parent. (These units are scarce; only two units are listed on eBay at the time of this writing, and they're not getting any cheaper.) Was it worth it? Good question. If I had to describe this thing in one word, it would be: "Uhnnnhhhhh ... !!!"

After three months of use, I'm starting to comprehend this beast. With 8 operators (waves/formants) per voice, you must choose one of 88 algorithms. Here's a screenshot of a few (in K_Take's application):

Each operator has a zillion parameters: pitch and amplitude envelopes, a "skirt" (which makes the sound fuzzier), and wave shapes (sine, sawtooth-esque, square-ish, formants) which have another zillion parameters of their own. Also each voice has 8 "unvoiced" operators, which generate pitched noise. These imbue its "speech" with sibilance, and thus, consonants; A zillion more parameters.

Everything I just listed is actually quadrupled, as you control 4 voices per program. And you can use "formant sequences" to make the operators fly around and "talk", morphing into vowels and phonemes.

Yeah, it's pretty hectic. This is a saturation point of some sort. This must be what happens when synths fly too close to the sun. Here are some sound samples that demonstrate the madness. If you're brave, here's a medley of my FS1R creations spanning 3 months, oldest to newest.

What the hell can you do with this device, then? I tried using the FS1R in a "lead" role for months; carrying the melody, or standing in front of the other instruments, snarling aggressively at the listener. That's not what the FS1R excels at. It sports an impressive collection of waveforms, but compared to other synths I've used, the waves sound soft, and clean. Even with the "skirt" maxed out, the FS1R can't produce a sawtooth wave, or a square wave, or anything big and phat that resonates your rib cage. FM synthesis can sound harsh on other platforms (the Yamaha TX81Z; the Sega Genesis) but the fidelity of the FS1R is apparently too good. You can't make this thing scrape, or scream.

This leaves you with a few options -- you can use it as a "background" instrument, or as a smooth pad. This is where the FS1R shines. It produces excellent textures that liven up a mix if they're used ornamentally. The FS1R could become my "secret weapon", adding that undefinable something to my sound universe. At least, I hope so. FM synthesis is hard to program because you don't really know what will happen when you twist that knob; little tweaks can send a patch spinning. The FS1R constantly surprises me, and that makes it cool. My best sounds come from building a patch using one algorithm (out of 88), and then clicking the other algorithms, arranging the operators into something that I couldn't have premeditated.

It has filters and on-board effects, too. Honestly, I've barely touched these, I'm still internalizing the other stuff. The filter seems unexciting; it's transparent and color-less, although it does offer three lowpass slopes (12, 18 and 24 db/octave), which is nice. The effects include several flavors of chorus & reverb, delays, dynamics processors, and two distortions (although they're soft too, and neuter the sound more than give it teeth).

My wish list for a sequel (the "FS2R"?):

• New modulation types between operators -- ring modulation and hard sync. That way, "the kids" can play it in "the clubs".
• More LFOs. You get 2 per voice, and 1 is reserved for the filter. More are needed!
• Formant sequences should be editable, or better yet, recordable. The manual states that sequences cannot be edited, but of course they can if you're willing to hack it a bit.

Meanwhile, the FS1R will keep me busy with its steep learning curve. At this point, I have rare moments of clarity where I can plan, and (mostly) construct the sound I want. What will I produce after 3 more months? I have no idea, none at all. We shall see.

P.S. Thomas Gruber explains how the FS1R's DSP works, and it's spiffy.

More »

Source code: julia_tile_src.zip. Pixel Bender code is in src/shader/.

The default image is Seattle's Space Needle. You can upload custom images. Very large images may set your processor on fire.

Parameters: Iterations sets how many times the Julia formula is applied per pixel. The iteration increments appear smooth, not stepped, because the code tweens across the destination coordinates of the two nearest iterations. Complex X&Y are the real & imaginary values of the transform constant. Bias X&Y is something I hacked in, it skews the coordinates in a linear way, becoming more intense with each iteration.

The Fill Types are as follows:

• 0: Pixels out of range are transparent; no fill.
• 1: Repeats the nearest edge pixel.
• 2: Repeats the source image, mirroring every other copy to create a smooth transition.
• 3: Repeats the source image without mirroring.

The filter needs more features before it's "done", hopefully it's still enjoyable. The Pixel Bender code took about 30 minutes to write; the Flex wrapper took much longer.

Despite its limited feature set, Pixel Bender is pretty cool. My only misgiving is that Pixel Bender's runtime performance is never as good as I hope. I have another filter in the works that mimics NTSC television artifacts, but the performance is abysmal. The code can still be optimized; stay tuned.

More »

Eventually I want to add NTSC artifacts using Pixel Bender. For now, I have to produce a small miracle of art assets, and use the tiny palette effectively. I never thought I'd study old Nintendo games, but that's exactly how I spent my evening.

According to Tsugomo, the eye perceives brighter colors as being closer. Most games with decent art have solid blocks brighter than the background.

Mega Man 3 - Needle Man

Mega Man 3 - Shadow Man

Obviously, you can see what's solid, and what's not. But, there are other ways to make this distinction.

Mega Man 2 - Air Man

In this example, the noisy texture of the glass tiles sets them apart from the solid background.

Mega Man 2 - Bubble Man

The waterfall is a torrent of bright colors, so the solid platform has to be even brighter, mostly pure white. Mega Man is almost the same blue as the background, but stands out because in this case, he is darker.

Mega Man 2 - Flash Man

Kinda pushing it here... Everything is blue. The platforms are bright enough to stand out, but Mega Man is almost lost in the background.

Mega Man 3 - Magnet Man

Interesting use of color. Lots of black pixels in this image, but the platforms have the brightest colors, and stand out.

Mega Man 3 - Needle Man

Mega Man 3 - Needle Man

These are tricky -- orange blocks are solid (they have bright highlights), green are background. They introduce this concept earlier in the level, too.

My game uses an overhead perspective, so I'm hunting for similar games with nice art. This screenshot is from the "Mission Impossible" Nintendo cartridge:

Mission Impossible - Stage 1

I love the geometry and the crafty use of shadows. Almost every tile uses 4 shades of one particular hue, and the effect is striking. And again, the most significant objects have the brightest highlights (your character, the solid crates, the medical kit).

Mission Impossible - Stage 3

More shadows, with varying lengths (compare the bench to the statue). This image uses a mere 14 colors, which surprises me.

One more from Mission Impossible, then it's bedtime:

Mission Impossible - Stage 3

More »

The Braindead Monkeys: Space Donut

After a 4-year hiatus, Space Donut arrives! It's their strongest album to date. Lots of head-nodding jams, and lots of smiles.

Recommended tracks:

• #3: Parody of a popular 80's cartoon
• #4: TERRORISM! "The United States is currently at war with everything..."
• #7: Nintendo (NES) + marching band
• #5, #13, #18: Delicious electro jamstep

Grab a banana and an electric drill, and enjoy!

More »

There are many ways to disable Spotlight. I don't remember which combination worked for me, but the end result is that mdutil doesn't run on this machine anymore, and my menu bar is devoid of a Spotlight icon. (Also I disabled Quick Look, since its indexing also caused problems.)

But I still want to search my files. My solution was to create an automated job that runs once a day, and saves the path of every file into a big text document. Then I created a little command-line alias called search, which prints any file paths that match a search term. Here's how to do it:

First things first... We need a script that will traverse the file system, and save the path of every file into a massive text document. This is pretty easy, the find utility can do the heavy lifting. Here's the script I wrote:

#!/bin/bash
rm /Users/chaz/dev/search/tree.txt
find / > /Users/chaz/dev/search/tree.txt

I saved this script as /Users/chaz/dev/search/build_tree.sh . Make sure it's executable, then run it:

$ chmod a+x build_tree.sh
$ ./build_tree.sh

The first time through, the rm command will complain that it has no tree.txt to delete, but that's okay. find will throw some other warnings at you: it can't traverse every directory because it doesn't have permission. Again, that's okay -- I probably won't be hunting for files in such places.

Grab a beverage, this process takes a few minutes. When it's done, you'll have a (rather large) tree.txt file in the directory. How large, exactly?

$ wc tree.txt
1719365 5761267 196118611 tree.txt

1,719,365 lines, so I just indexed 1,719,365 files. Awesome.

It would be nice if the indexing ran automatically, preferably when I'm asleep. Since cron is being phased out of OS X Leopard, we'll use launchd instead. I created this file, called rebuild_search_tree.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://ww w.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>chaz.search.tree.rebuild</string>
<key>ProgramArguments</key>
<array>
<string>/Users/chaz/dev/search/build_tree.sh</string>
<string>daily</string>
</array>
<key>LowPriorityIO</key>
<true/>
<key>Nice</key>
<integer>1</integer>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key>
<integer>6</integer>
<key>Minute</key>
<integer>15</integer>
</dict>
</dict>
</plist>

Save this into ~/Library/LaunchAgents . You may have to create that directory, and there's an added wrinkle: for both the LaunchAgents directory and the .plist file, the owner has to be root.

$ sudo chown -R root ~/Library/LaunchAgents

Register this script with launchctl:

$ sudo launchctl load -w ~/Library/LaunchAgents/rebuild_search_tree.plist

Now this launch agent will run automatically at 6:15 every morning.

Finally, we need a command-line tool to search the tree. I added this line to my .profile:

function search() { clear; cat /Users/chaz/dev/search/tree.txt | grep "$@" | more; }

And here's how you use it:

$ search test
/Applications/Adobe Photoshop CS3/MATLAB/tests/teststats.m
/Applications/Audacity folder/nyquist/test.lsp
/Applications/iTunes.app/Contents/Resources/da.lproj/iTunes Help/gfx/gfx_test.gif
...

For each file that matches your query, it displays the full path of the file. This could be made fancier, but for now this is all I need!

More »

OpenMoko Train Wreck from Dave Fayram on Vimeo.

More OpenMoko Train Wrecking (Now with Qt!) from Dave Fayram on Vimeo.

There's a ton of literature describing best development practices out there. But I think case studies of failure, or good intentions gone horribly awry, are just as important. It's essential to recognize what not to do. I still regard The Daily WTF as a learning resource, full of cautionary (and hilarious) case studies.

Also, there are no "________-killers," but that's a subject for a different day.

More »

Click to play.

• Move: Arrow keys, or WASD
• Shoot: Mouse button, or IJKL

Make sure you grab a weapon in room #2, so you can shoot the orcs. Currently, there are 9 rooms for romping.

Not one pixel of the art should be considered "final". Most sprites & tiles have a ColorMatrixFilter that "skins" them with four particular colors (see my post detailing this technique). In some respects, this is wonderful, as the colors can be randomized, and it's easy to change the palette of an entire room. Unfortunately, to maintain retro look & feel, I chose the Atari 2600 palette. The dark colors are over-saturated, the pastels are unexciting, and the hue distribution is completely wrong (nearly half the colors could be considered "green"). This will be dealt with.

An earlier screenshot shows some vector art. Unfortunately, the vectors currently require Flash 10. I've disabled this feature... for now.

More »