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 »

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 »

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 »

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 »

You can see the glitch-enabled version here: http://www.fashionbuddha.com/horaciosalinas/

More »

"The electrical static was very disturbing. I don't think it adds to the photography, but it did add to my anxiety about my own computer enough that I bailed even though I knew it was something on the site. HTH" -- Zani

(There is a glitchless version of the site at horaciosalinas.com.)

Also... They say imitation is the sincerest form of flattery, so I'm amused that yenisanat.net copied the site in its entirety (even the images!) but changed the copyright. I'm glad you appreciate our hard work, Yeni. I feel like I've finally arrived, ya know?

More »

http://www.fashionbuddha.com/horaciosalinas/

The site seems typical at a first glance, until the glitches kick in... Then you're in for a treat. (You can adjust the glitch rate in the menu.) Here's how the effect works:

The concept + design were crafted by Fashionbuddha Studio. They handed me proof-of-concept code that loaded a JPEG, scrambled its bytes, and rendered it to the screen. Corrupted JPEGs look like you'd expect; some are beautiful, with distortions in their colors and textures; some were nasty or unrecognizable. A few wouldn't display at all, but more on that in a minute...

The site uses JPEG corruption as a method of animation. When the site is idle, a photograph will sometimes crackle to life and progressively corrupt itself for several frames. When you click a menu link, you see a similar effect, but it's reversed: the corrupted frames are quickly pre-rendered in memory, and then displayed in reverse order, materializing from the most corrupted frame to the least.

All the corruption effects are performed inside Flash. Use a URLLoader to load an image, then on Event.COMPLETE, you can access the raw JPEG data as a ByteArray:

var bytes:ByteArray = e.target.data;

You can traverse the ByteArray and change selective bytes, just like editing an Array. (Some people would call this "data bending".) Then you can display the corrupted image by using the Loader.loadBytes method:

_loader.loadBytes( bytes );

Matt Rooney of Impact Resist helped me with the next phase: sometimes, our corrupted ByteArrays weren't recognized as valid JPEGs, and Flash wouldn't display them. Matt dug into the JPEG file structure, and created a class that identified various markers inside the file.

I wrote a quick 'n dirty test harness (warning: contains drugs and boobs) that loads a couple images, and lets you change the value of one byte at one particular position. Using the harness, and the info gleaned from Matt's JPEGInfo class, I determined that there are three "hot zones" where you can garble the data and produce desirable effects:

• Scan data. (This is the bulk of the file, containing the image data). These effects are usually relatively weak, and cause horizontal tearing, or sometimes color changes. Applying several corruptions is effective. To see a single corruption effect, drop these values into the harness: [10000/200]
• Quantization tables. These are beautiful effects that can affect the entire image. The first half of the quantization data controls the visual complexity (Fourier constants) and the second half controls the overall color. Try these values: [60/40], [61/40], [64/75], [125/110]
• Huffman lookup tables. This is the most drastic effect. Try these values: [366/28], [367/28], and explore the surrounding bytes.

It took lots of tuning to make the photo corruption look aesthetically "correct" -- not too intense, not too subtle. The final algorithm applies a number of scan data glitches every frame, and sometimes one quantization or Huffman glitch per frame (and always on the first frame, to emphasize that the glitch is occurring). Some byte values aren't safe to inject (or modify): 0, 1 and 255 have special functions in the JPEG file format, so the site avoids those completely.

If you want to scramble your own JPEGs, but don't want to write a whole Flash harness to do it, then you can open JPEGs using a text editor (such as TextMate) and edit the file as text (with unpredictable results). Have fun!

EDIT: The glitch effects have been removed from horaciosalinas.com, see this post for more info.

More »

Before we jump into ColorMatrixFilter, let's ponder a different, and more commonly-used, class first: ColorTransform . Using a ColorTransform, you can "tint" any DisplayObject with color. But there's something sneaky you can do, as well -- Notice that ColorTransform gives you two parameters for each of the four color channels: Red, Green, Blue, and Alpha. One parameter is the "multiplier," which takes the input value and (predictably) multiplies this value by a constant. The other is the "offset," which works like addition: adding (or subtracting) another constant from the value. These two functions are applied to all four color channels of each individual pixel. That's how the magic works.

Allow me to spend a few paragraphs making sure this idea is lodged in your head. Imagine that you have a DisplayObject; one of its pixels has a red value of 128 (out of a range of 0-255. So this red is at a medium level.) We don't care about any of the other color data right now; let's just focus on the red.

Let's say you have applied a ColorTransform to this DisplayObject. The ColorTransform has a redMultiplier of 0.5, so our working red value is now 64. (The red value is now somewhat darker.)

But the ColorTransform also has a redOffset of 128, which is then added to the pixel's red value. The final red value is 192, so the output color has a fairly bright red component.

Keep in mind that we aren't considering the green, blue, and alpha channels in the above steps. We're just altering the red value, at this point.

Now for the first round of magic: There's a slick way to colorize a black-and-white image, using a ColorTransform to "map" its black and white values to two destination colors of your choosing. Shades of grey will even be mapped to the spectrum of colors between your chosen destination colors. Here's a quick-and-dirty .swf showing this in action. Every time you click the mouse, the application selects two new destination colors (you can see these values in your trace log) and creates a new ColorTransform that maps the black pixels to one destination color, and the white pixels to the other color. The grey pixels create a smooth blend between the two extremes.

How do we accomplish this? By using simple math. Suppose one of your destination colors has a medium red value (128). Mapping all the black pixels to this red value is the easiest thing in the world. Since black pixels have a red value of 0 (because they have no brightness whatsoever), we can set our redOffset to 128. ...

Stepping through the math: The ColorTransform is about to crunch a black pixel. Since the red value of the pixel is already 0, it doesn't matter what our redMultiplier is. Any number multiplied by zero is 0. Then, our redOffset (128) is added to the working red value.

Imagine doing this with green and blue, as well. Congratulations, you've just mapped your black pixels to any specific color you want.

Once you understand that concept, mapping the white pixels to a different destination color is easy. Suppose our second destination color has a red value of 192. Incoming white pixels will always have the maximum red value, which is 255, right?

Since we know our redOffset will add 128 to the final red value, we need to make up the difference between 192 and 128 (64!), using the redMultiplier alone. And since we know our incoming white pixels have red values of 255, we can set our redMultiplier to ... 0.25 . (This is an approximation, for the sake of the example. 64 divided by 255 is 0.2509803 .)

Imagine that the ColorTransform is processing a white pixel; the incoming red value is 255, yes? Our redMultiplier acts first, and multiplies this value by 0.25. The working red value is now (approximately) 64. Then, the redOffset steps in, adds 128, and the final red value becomes the desired 192.

Again, the process for the green and blue channels is similar. Here's some AS2 code that uses this technique, hopefully you can guess that a "ColorObj" is a little object that holds red, green and blue values, ranging from 0 to 255:

import flash.geom.ColorTransform;
import com.zacharcher.color.ColorObj;

class com.zacharcher.color.ColorGradient
{
	public var transform:ColorTransform;

	function ColorGradient( black:ColorObj, white:ColorObj ) {
		transform = new ColorTransform(
			(white.r - black.r) / 256,
			(white.g - black.g) / 256,
			(white.b - black.b) / 256,
			1.0,
			black.r,
			black.g,
			black.b,
			0.0
		);
	}
}

Ok. Let me wrap this up, because it's 4 in the morning here in Portland! For Space Kitty, we wanted each cat to use a different color scheme, but without going to the trouble of creating dozens of MovieClips (one for each cat). We discovered that we can use ColorMatrixFilter to perform the same trick as with ColorTransform, but it's more sophisticated because we can map to 4 (four!) destination colors at once.

First, Miles drew a cat using four specific colors: black, pure red (#ff0000), pure green (#00ff00), and pure blue (#0000ff):

Then I wrote the code. Here's how ColorMatrixFilter crunches one pixel value, say we start by examining the red component: The value of the red channel is multiplied by a red multiplier (just like ColorTransform), and also three other multipliers (for green, blue and alpha). The four resulting values are added to four separate output "pools". One pool will become the final red value; one will be the final green value; etc.

Then the incoming green channel is examined, and four different multipliers act on it, adding new values to the four pools. Then the incoming blue channel is evaluated in the same way, and finally the alpha channel is evaluated.

As a finishing touch, there are four additional values which are added to the pools, much like the offsets of the ColorTransform. All that math produces a simple result: four "pool" values, representing the new red, green, blue, and alpha values for one pixel. That's how ColorMatrixFilter works.

And it lets us map four colors, not just two! The technique is just like our ColorTransform technique, except that we don't need to handle the red, green, and blue of the destination color separately. We can handle them all at once, because we have multipliers that splice the color values onto each other: the incoming red channel can affect the green pool, and so on. Here's the AS3 code we used... Our cat MovieClips featured red eyes, so the "redDest" in this code holds the cat's desired eye color:

var matrix:Array = new Array();

// RED RESULT:
matrix = matrix.concat([
	(redDest.r - blackDest.r) / 255.0,
	(greenDest.r - blackDest.r) / 255.0,
	(blueDest.r - blackDest.r) / 255.0,
	0,
	blackDest.r
]);

// GREEN RESULT:
matrix = matrix.concat([
	(redDest.g - blackDest.g) / 255.0,
	(greenDest.g - blackDest.g) / 255.0,
	(blueDest.g - blackDest.g) / 255.0,
	0,
	blackDest.g
]);

// BLUE RESULT:
matrix = matrix.concat([
	(redDest.b - blackDest.b) / 255.0,
	(greenDest.b - blackDest.b) / 255.0,
	(blueDest.b - blackDest.b) / 255.0,
	0,
	blackDest.b
]);				

// ALPHA: for now, do not adjust opacity
matrix = matrix.concat([
	0,
	0,
	0,
	1,
	0
]);

var filter:ColorMatrixFilter = new ColorMatrixFilter( matrix );

And here's how it looks in the game!

I look forward to experimenting with this technique more in the future. You'll notice we didn't perform any magic with the alpha channel, although both ColorTransform and ColorMatrixFilter let you treat alpha in the same way as red, green and blue. So there are still interesting tricks waiting to be discovered!

More »

It's a lot of fun, but I need to warn you about a serious problem in Space Kitteh. This is a heads-up for users of Windows Flash Player --

Our game will crash your browser.

And we don't know why. It has something to do with this level:

Every Windows user who spends a little time on this level reports the same problem: the game crashes hard, and takes down their browser. Sometimes it's after a few seconds, sometimes it's minutes, but eventually, this level will get you.

And the frustrating thing is, we have no idea why. Mac users (including myself) have no problems, PowerPC- or Intel-based. Perhaps it's due to the glut of sun ray shapes in the center of the solar system? Look at the size of those things! Do these malloc huge chunks of memory, and overflow the heap? Who knows. One day, Miles reigned in the rays, so they wouldn't grow to immense proportions, but that didn't remedy the crash. Then he disabled the sun rays completely, and this seemed to work, although the game did crash in another area thereafter. It's all very confusing.

I feel like we're sitting on a time bomb. This is going to ruin our chance of winning a prize. (Not that we entered to win, but it would be nice! We both put serious time and energy into Space Kitteh.) Jay Is Games devotees are going to enjoy some of our hard work, but it crashes, irritatingly so, and you can't win the game.

In addition to this method of crashing Flash, I stumbled on another nuclear exploit that even crashed Flash on my Mac (it took down the Flash CS3 application). Here it is, the purpose of this code is to play a sound after a short delay:

var snd:Sound = fetchSoundByName( name );
var timer:Timer = new Timer( delayInSeconds * 1000, 1 ); // seconds => milliseconds
timer.addEventListener( TimerEvent.TIMER, snd.play );
timer.start();

In this example, I'm guessing that the native Sound.play() method barfs because it's not equipped to handle any arguments, such as the TimerEvent it receives? Whatever the cause, enjoy the exploit. Play practical jokes on your friends, and the whole of digg.com, and whatnot.

I doubt we can mend Space Kitteh in time for its debut, which happens in a few days. I don't know what to do, really. We put a lot of love into Space Kitteh, and tried to create a quality experience. And I'm already grieving in anticipation of our (otherwise wonderful) game crashing browsers worldwide.

What would you do?

More »

Today I thought about interface design, and performance issues (the sluggishness this early in development irks me) so I thought about simplifying the design a bit. Here's where I'm at:

Play with the swf. The button has a rollover state, but doesn't react when clicked.

MUST ... INCREASE ... PERFORMANCE. Somehow. I have some approaches in mind, but I was hoping to escape the long process of experimentation & optimization. Oh well, stay tuned.

More »

Play with the swf. Move the camera with the mouse; Click the mouse to summon a new message.

Creating this graphic demo was not a huge ordeal. I probably spent more time futzing with Subversion than writing code; and by the way, this project may evolve into my personal website, so it has its own SVN repository now.

I've pinpointed two interesting problems with my 3D engine: 2D Symbols (such as the letters) do not exhibit foreshortening, yet 3D symbols do. (This is almost a good effect; like a low-fi hack that ends up being more stylistic than a hi-fi equivalent. Maybe I'll conveniently forget about this issue for now...)

And, my Matrix3D class has a buggy method: either multiply() or rotate(). An early version of tonight's .swf turned the cube in space, but it would also re-apply the camera angle to the cube, turning it in crazy unexpected ways. ... TODO.

I just looked at the PaperVision API (.pdf), they have a Matrix3D object that is much more advanced than mine. I'm still glad I wrote my own engine, it was fun and I feel more competent with 3D math and matrix operations now.

I removed the glow effects in an attempt to boost performance. I should have whipped up a little FPS counter several posts ago, of course... The performance on my G5 (dual-core 1.8ghz PowerPC) is already less-than-optimal, and there's not a ton of stuff happening on the screen. This worries me a bit.

More »

http://dev.zacharcher.com/svn/as2/

Have fun, give me feedback, but for the love of all that is holy, use this code at your own peril... This codebase is growing rapidly, and some classes that work today might have a different interface tomorrow.

More »

Play with the .swf. Click the mouse; type some letters; move the mouse for beefy, savory 3D taste. Backspace to clear.

You'll notice that the letters flicker; this is intentional. It's a step towards simulating the "old cathode ray tube" look and feel that I desire.

I'm creating the flicker using one of my favorite tricks: flash.geom.ColorTransform . The line segments (and the glow) are being drawn using random shades of grey (including black and white). The ColorTransform maps black to a new color, and white to another color; in doing so, shades of grey are automatically mapped to color values ranging between the two.

The 3D action is, in a word, complicated. Many websites were consulted; many mathematical formulas were borrowed.

One of the biggest challenges was extending flash.geom.Point to a new class: "Point3D". Also (especially) difficult was extending flash.geom.Matrix to "Matrix3D". Of course, I wanted all my Vector drawing methods to support both 2D and 3D geometry, so there were issues with inheritance and casting. ActionScript 2.0 can't tell you what class an object belongs to (all the classes mentioned in this paragraph evaluate to "Object". Not helpful!) so I had to improvise. The 3D classes return true if you evaluate myObject['is3D'].

Also I added static create() methods to the 3D objects: these accept a Point/Point3D, or a Matrix/Matrix3D, and verifiably return a 3D equivalent of whatever you passed in.

I did this because I had issues with casting. This cast did not work for me, and I don't yet understand why:

var myMatrix3D:Matrix3D = Matrix3D( myMatrix2D );

The 3D algorithm took a day and a half to get right. I relearned matrix multiplication along the way. I was giddy and cheering when it finally worked. This is a major step forward.

More »