Greyboxware

On April 1st, 2010 YouTube pulled what I considered to be the greatest Tech Industry prank of the day: TEXTp. For the fools, YouTube claimed that using this video quality mode saved bandwidth; an obvious ruse. In reality it was simply a pixel shader that was applied to the video stream that turned streamed video frames into the ASCII style that we all know and love. I love ASCII art, so I thought this was the coolest thing I’d seen in a long while. I had hoped that YouTube would realize just how awesome this effect truely is and leave it available year round, but my hopes were in vain. At midnight on April 2nd, the effect was gone. You couldn’t even append the &textp=fool parameter into the querystring. Lucky me I had Firefox save me a page on my disk that still had all the proper flashvars to keep using the effect. But sometime on April 5th, YouTube removed the pixel bender shader they were using for the effect from public access. TEXTp was no more as far as YouTube was concerned.

Long story short, I was mad that they removed something so awesome, so I created my own TEXTp pixel shader to cope. I call it AsciiMii. Here we have optimus prime demonstrating the effect:

The shader is written in Adobe’s Pixel Bender framework. There’s still a few things that need tweaking, but I’m going to see how far I can run with this. I’ve already got it attachable to video objects in flash, and since its a Pixel Bender kernel, I can probably turn it into a Photoshop filter. I’ll post more when I actually figure out what I’m going to do with this. At the very least, I’ll just release the shader (sorry… I should really be calling it a “kernel”) source code and be done with it.

Note: Recent tests lead me to believe that this does not work properly in IE7. I still have to look into it.

So some buddies of mine asked me a few days ago if I would build them a web application to help them track runs in EVE Online. Seeing as how it would both give me something to do and let me start a fresh web project not riddled with code I wrote when I didn’t know any better, I agreed. One thing I wanted to do correctly from the start was JavaScript DOM mutations. Back when I didn’t know any better I used innerHTML like it was thrown in free because I waited for more during a Billy Mays infomercial (Hi, Billy Mays here for Internet Explorer! Why conform to all those pesky internet standards…).

As I started writing client-side DOM mutation functions for AJAX callbacks, I started abstracting the logic into simple DOM functions. After awhile I realized that the only way I was going to be truly happy was by using a JavaScript parser that could take a string of HTML markup and convert it to a DOM sub-tree. This way I could have templates of HTML stored server-side, send those templates back with the proper information when requested by the client, and the client can just parse the HTML string and inject it into the DOM as needed. I initially set off to write one, but then thought that somebody else probably already wrote one (this is, after all, the internet). After a bit of googleing, I found that John Resig had already modified one made by Erik Arvidsson to seemingly do exactly what I was looking for. I gave it a spin and it did most of what I wanted, but was lacking one feature that, after taking a bit of time to figure out the parser’s logic, I added to it.

I really only added about three lines of code to make it work. Originally, the HTMLtoDOM function did not actually inject the parsed HTML into the DOM at the given node, it would just blindly inject it into the document body. Also, the original function would only seem to inject the parsed HTML into the DOM, or return a complete DOM tree, starting at an HTML root node. I thought it would be more useful if it returned the parsed DOM sub-tree without actually injecting it into the DOM, that way you could still do whatever you wanted with it (element swaps/clones/etc. outside the parser’s logic). This is done by returning the first child of the parent DOM object that marks where the parsed HTML is to be injected. By supplying the function with a garbage div [HTMLtoDOM(htmlString, document.createElement("div"));], the parser injects the parsed HTML as a child of the bogus div that was created for the parser, and returns that element. Since the bogus div is never injected into the actual page DOM, you’re free to do whatever you want with this DOM sub-tree before your attach it to the page DOM.

Here is the JavaScript file: htmlparser.js
The original can be found at John Resig’s blog

I haven’t tested that the other functions still work because I never use them. I just left them in for completeness, but there’s no reason that they shouldn’t work. Modifications were only made to the HTMLtoDOM function.

I had an epiphany (well, it wasn’t an epiphany, but more of a realization that I’m a college graduate and nowhere near a path that leads to what I want to do with my life) the other day, and decided that it was time to stop playing games and start messing with them again. I had just finished another run through of the Half-Life series and decided that it was time to get back to my game modding roots. Back in the day (when I wanted to go to Art School), I started making maps for GoldSrc games (Counter-Strike, Day of Defeat, HLDM, etc…) and finished about 5 or 6 that I ended up releasing. I always wanted to make a short single player mod, but found that I lacked the honed art skill to make original content (models and textures) and the programming ability to make changes to the game so that it wouldn’t seem like 30 minutes of the original game with a face lift. But now that I’m a college graduate with a degree in Computer Science, maybe now I can make some of those code changes to make the game slightly enhanced from its parent and embrace my art roots to make some custom content that actually looks good. I decided to start my endeavor at the most logical continuation point: The Source Engine.

Actually, on reflection, it would seem more logical to pick up my game-making endeavors where I left them off: the Doom 3 engine. The Doom 3 engine is great for making maps and mods. Everything is open. You don’t need any custom tools to compile anything. Everything except the modeling program (Lightwave) ships with the game, and id software has always been stellar at being open to the modding community. Truth is I’m going with the Source Engine for two reasons: After playing with Portal for the n-th time, I had some ideas of possible modifications I could make to the code base that would enhance the game-play possibilities far greater than I could think of with any other engine; and two, all of my “game-making” buddies I hang around with work with Source on a regular basis (all of them either worked or are working on the Black Mesa Source modification for Half-Life 2).

Cracking open the hood of Source (specifically the Portal code), I see a lot of potential. I’m quite surprised at the way some of the things are done, and other things are just genius (portals are rendered by copying the view into the frame buffer, and use the stencil buffer to help with filters… absolute genius). I would like to build some kind of very quick single player mission that involves not only portal puzzle solving, but also combat with the portal gun. I first tried to see what I could get away with using what’s currently under the hood of the Orange Box SDK. I build a very quick “orange box” (no pun intended [no, seriously, it was a dev level that was a box with a light and a few entities]) to check a few things, and the results… out of the box… not a whole lot that deviates from Portal itself.

First thing I noticed is that all NPCs that aren’t npc_turret_floor or npc_turrent_ground objects do not comprehend Portals at all. I can understand this. I dig some digging through the code-base and found what seems to be the reason for this.

inside npc_turret_floor.cpp:

#ifdef PORTAL
if ( !FInViewCone( pEnemy ) || !FVisible( pEnemy ) )
{

CProp_Portal *pPortal = FInViewConeThroughPortal( pEnemy );

if ( pPortal )
{
// Translate our target across the portal
UTIL_Portal_PointTransform( pPortal->m_hLinkedPortal->MatrixThisToLinked(), vEnemyPos, vEnemyPos );

}
}
#endif

The majority of the Portal specific code seems to be inside of precompiler directives (for obvious reasons). This little snippet lives inside the function that determines how a turret searches for an enemy (the player); basically the turret is saying “if I can’t see the enemy anywhere, are there any portals I can see, and if so, can I see the enemy through the portal (UTIL_Portal_PointTransform function call)”. I haven’t actually ported this logic into any other npc classes yet (I’ll see what I can do this weekend… I really should be studying for my MS Active Directory certification test).

I only spent about an hour prowling through the source code looking for explanations as to why things were they way they were in my test level. While messing around with my box level, I jotted down a few things that I noticed were awry and want to look into changing:

• NPCs don’t understand portals (can’t detect through portals) [see images at end of post]
  • after detection works, see if I can get the AI to follow through a portal
• prop_physics don’t seem to inflict fall damage on NPCs (might just be incorrect settings in hammer)
• Weapons do not understand portals (a combine soldier’s dropped weapon)
• Ragdolls don’t understand portals
• Cannot spawn portals underneath NPCs (except turrets)
  • Begs question, what do you do when this happens? If I spawn a portal
    link underneath a combine solder and the end of the link is on a wall
    at floor height, the damage inflicted by the trip wouldn’t kill him…
    The easy way out would just be kill him and make his ragdoll fall
    through and only build maps that allow soldiers to drop through portals
    that cause a very long fall. Also easier because of the fact that
    objects can emerge through a portal upside down in certain cases…
    this would require a metric fuck-ton of animations/conditions to kill
    the npc if he/she’s oriented a certain way, and just fall in others.
    Maybe it wouldn’t be that hard, but at first glance, this seems light a
    lot of work.
• NPCs don’t shoot bullets (they do throw grenades though) [i hear it's a problem with the multiplayer code base, which I didn't think I was using... maybe Portal's code base is a branch of the multiplayer code base?]
• Physics gun does not re-grab teleported prop_physics object after going through a portal (portal gun does)

Long shots ideas that will probably never get implemented:

• HDR through portals?
• Emulate light coming from a portal [[Extreme Long Shot (Don't have
  access to radiosity engine; probably hard to fake with it still looking
  good)]]

I’m actually kind of excited to see what kind of havoc I can make with the Source SDK.

Creating a portal in front of a Combine NPC and trying to peek-a-boo through it. Combine NPC complete ignores me, while the floor turret (off to the right, not shown) detects me no problem

After going through the portal, and then stepping back through, the Combine NPC is alerted to me, but can’t find me.