Redacted the mailing address and some info you don't need. :P

This means that I’ll be moving out to San Francisco, California at the end of June and starting work as a Software Engineer at Zynga at the start of July!  In the meantime I am going to try to work through my backlog of projects, so you should be seeing more in this space soon.

For now I’ll share a quick video of an AI project I worked on this past semester:

It was definitely a fun little challenge to make an AI that can play Mario! Hopefully I can find some to tinker with this sort of thing some more.

Uncompressed textures aren’t necessarily a bad thing, but ASS was pushing a fair number of large unique textures to the screen, eating up all the texture fetch bandwith on older and/or laptop cards. Many of these textures were generated at runtime (most commonly a texture was blurred). So I decided to look into compressing the textures.

Since the whole point is that I am trying to get back some texture fetch bandwith, I need to use a compression technique that is understood by the GPU. This leaves me with one choice: DXT. Specifically DXT5.

Ok I’m going to give you a quick explanation of  DXT right quick.  It is a type of lossy compression that nearly all GPUs “in the wild” can decode.  It works by:

• taking a 4×4 block of pixels
• then it uses some fancy math (like Principal Component Analysis) to find the 2 most important colors in the block.
• It stores these colors as 16- bit values (5,6,5)
• Then for each of the 16 pixels in the block it stores a 2-bit value that describes how far it is from each of the colors.

Now DXT compression comes in quite a few different flavors DXT1 and DXT5 are the most commonly used (as far as I can tell).  The only real difference between the two is in how they encode alpha.  DXT1 only supports “cutout” alpha (basically a 1 bit alpha, either it is opaque or it is transparent) while DXT5 supports  a gradient alpha.  I am not going to get into exactly how each encodes alpha for length reasons, but let me know if you would like to know more.

So after much searching I found a nice little paper about a Real-Time DXT compression.  It had code samples, and I couldn’t find anyone who had implemented the DXT5 compression in C#, so I decided to go ahead and port it!

Porting it took a while, and I had some issues… mostly with making it multi-threaded… It works now, and it looks pretty good! If a texture is too blurry (like the back grounds), then there will be a very distinct loss in quality but that is just a limitation of DXT. The compressed foreground objects look rather decent though (such as the platform the gum is standing on).

Now I hate it when people talk about a cool thing they ported and then refuse to share the code. So here it is, enjoy! (Just a heads up, it needs XNA 4.0 to work).

Hope this is helpful! Let me know if you have any problems/suggestions/questions/etc.

Before you watch them though, I should probably explain a few basics of how the game works. You play a piece of gum that can stick to nearly any surface, harden into a gumball, and blow up into a bubble. In the default sticky mode it can squeeze through any gap and climb around on walls and ceilings. The hardened gumball moves quickly, can bounce, and can crash through obstacles. Lastly, the bubble can, well, float like a bubble!

It doesn’t look like much because textures, backgrounds, foregrounds, and sound effects weren’t in yet… The red boxes are essentially trampolines or springs and the grey boxes are non-stick. This demo basically just shows off a couple of the basic ways to get around.

In sticky mode, the gum is rendered using a 2D version of “meta-balls.” It is essentially a collection of Gaussian textures drawn to a render target then passed through an alpha-test, yielding an “iso-surface.” Creates a nice little skin to the skeleton of 74 springs that make up the gum (no more detail than that… trade secret :P). AND I can render each meta-balls in virtually any [24-bit RGB] color; I use this to give the gum a neat little color swirl.

In the next few examples the sticky gum gets a black outline. The rendering pipeline I designed had space for an additional shader pass for the iso-surfaces, so I wrote a little shader that does a bit of edge detection using a Sobel Operator. No real reason I chose that one, I liked the final look a bit better than say, a Laplacian.

Collisions from textures! Since it is supported by Farseer and I had already made it so that the gum could adhere to any arbitrary geometry, there wasn’t a lot of code needed on my end… for once.

Gum needs to be able to blow up into a bubble right?  This was actually a bit of a pain… I was going to just use a circular collision, like with the gumball, but I wanted it to inflate.  Switching over to SAT instead of Distance Grid for the narrow phase (details here) increased the time the physics step took by about 80-90%.  Sure Distance Grid used more memory, but it was only about 5%, so I’m not worried. ANYHOW!  I could have cached a few collisions and just stepped to the proper collision boundary based on how inflated the gum was.  This just didn’t seem elegant to me; it really seemed like a major cop-out.  So instead I used a similar system to the sticky gum, but instead of using Farseer’s linear springs, I wrote up a much more rigid system.  I wanted the bubble to maintain its “roundness.”  Couple that with the iso-surface rendering code and toss a bit of jitter on the edge points and we have a bubble that looks like it is actually being blown by a fan! Yay procedural animation!

That’s all for now! Check back in the future for more updates about how things are going! Back to work… So much time and so little to do!

…

Scratch that; Reverse it.

-Ian

Hopefully I’ll be at Dragon*Con again next year. Maybe I’ll even make a good costume!

…

Ok, so it isn’t quite that big… It is big enough though. Unfortunately I can’t really share a video of the game itself, so instead I’ll share an older engine test video with you guys:

In case you can’t tell, the pink box is a button. It is pretty much triggered whenever it overlaps with a non-static object. Pretty cool, huh?

Hopefully I can show you guys something more relevant in the next update. Back to work!
-Ian

Well that’s all for now!

Well partially… Moving platforms are at about 75% (There is still too much jitter vertically.) and I need to get the rendering pipeline finished up, and the tie everything together into a nice little package. Then it is on to the level editor! I’ll need to make a second pass through and add proper sound support, networking, and a few other things… but my main goal right now is to get things to the point where my buddies can start making levels asap.

Look for another big update this weekend soon.

The idea is that the player controls a piece of gum that sticks to [nearly] any surface. Being a piece of gum, you can’t jump but you can detach from surfaces, putting a new spin on the platformer. A few more gameplay elements are in the works, but I don’t want to give too much away right now. I’m currently working on some of the more traditional components, such as parallaxing backgrounds. Look for another update in the next few weeks.

I think of this as the personal creative process. It gets the creative juices flowing, as they say. It doesn’t produce anything in itself, it may not even be a creative idea on its own, but it sews the seeds for a creative idea later on down the road, even if one can’t remember the act.

I have pages and pages of little ideas I want to explore to see if I can create tools, toys or gadgets that help foster the personal creative process. Let me know what you think of my little toys, the first is below:

Click in the white box below, and then press (nearly) any key on your keyboard to create a little patten. It is a work in progress, but it is finished enough to show. Hope you enjoy it.