Palagpat Coding

Reclaiming Content: A Manifesto

2010-09-27T22:50:00.000-05:00

I've been thinking for a while now about trying to get away from using a hosted blog, but I wasn't satisfied with WordPress — I found it too complicated to do what I really wanted with it, plus it opened me up to all kinds of comment spam and malicious attacks of other sorts. Yes, I realize that I could keep it patched up and minimize my attack profile, but it would still be there. That's the hazard of using something that's widespread: it makes an attractive target.

Beyond that, I'd also like to archive the URLs to things I share online, e.g. on Twitter. There are services that help with this sort of thing: del.icio.us, bit.ly, etc etc etc. But anytime I'm giving my data to someone else, I'm a little uneasy, for a couple of reasons:

What are they going to do with that information? Google and Facebook have both gotten really good at targeting ads at me, and I don't like it.
What happens if their servers suddenly dump my data, like Twitter recently did to my @-replies, or like Google Buzz did a few weeks ago to Leo Laporte?

So, here's what I'm going to do about it.

Manifesto of the Independent Voice

I reject the notion that free on the Internet can only be achieved through selling one's soul to corporate interests. I declare that search engines and blog services do not own the rights to my voice and my words; I do!

I hereby declare my intention to divorce myself from all third-party content management systems. If I cannot find a suitable open-source blogging platform or content management system, I will build my own.

Small.

Fast.

Simple.

Free and Independent.

Mine.

In Case You Missed It: JSConf.eu 2010 (day 2)

2010-09-27T04:35:00.009-05:00

As expected, Day 1 of this weekend's JSConf.eu JavaScript conference in Berlin was, as the kids say, EPIC. So much so, in fact, that I found myself following the Twitter channel all morning, and retweeting WAY more often than usual. Of course, a lot of those retweets were to presenter-uploaded slide decks, but here they all are in one place, in case you missed it:

Speaker(s)	Topic
THEATRE (TRACK A)
Douglas Crockford	Loopage
Jens Arps	The hitchhiker's guide to client side persistent data storage
Ryan Dahl	Techniques for a single stack world
Jed Schmidt	Getting functional with (fab)
Tom Hughes-Croucher	Don't write spaghetti code in server side JavaScript
Kevin Dangoor, Joe Walker & Patrick Walton	~~Bespin~~Skywriter: The JavaScript Programmer's Editor
Jörn Zaefferer & Nikolai Onken	Robotic JavaScript
Mark Wubben	Browser Extensions for Web Hackers (code)
Alexander Lang	Not your unit test (note: Chrome on OS X)
Stoyan Stefanov	Performance Patterns
Chris Williams (JSConf co-creator)	Community.js

MUSIC SCHOOL (TRACK B)
Paul Irish	The State of HTML5 : Inaugural Address (note: Webkit/Chrome required) (sidebar on polyfills)
Tobias Schneider	Not your Mother's JavaScript!
Sebastian Werner	Introducing Unify - A Framework for Cross Platform Applications
Guillermo Rauch	Socket.IO: Web Sockets for Everyone (nodestream, demo)
Thomas Steiner	Pirating the Semantic Web with JavaScript
Rotislav Hristov	The Art of deep linking and AJAX crawling
Kris Kowal	CommonJS, I Promise
Aaron Quint	The Front-end Takeover
John David Dalton	Srsly R1pp3d J@vaScript
embedJS team	What is embedJS (I don't see this one on the schedule, only in the Twitter stream; where was it?)

Undoubtedly there will be more slide decks uploaded as presenters return home over the next day or two, and when they do, I'll update this post to reflect those additions. For now, though, I've got plenty of reading material to digest, and to share with my co-workers. ;)

Projects released and/or updated this weekend (as compiled by Brian Leroux):

Cloud9 IDE (by Javascripters, for Javascripters)
Unify: single-stack project for developing cross-platform, native-looking mobile apps
Scripty2 beta 1
apparat.io: packaging HTML5 apps for mobile app stores
PhoneGap's hosted build service
Joyent's node.js hosting
VaporJS: the smallest, fastest, (most useless) JavaScript framework ever!
soca: Sammy on Couch App

nodestream

Yet another great conference has come and gone, but now we can start looking forward to JSConf 2011. And next time, I'm going to do all in my power to give my recap first-hand.

Updates:

9/27 0747 - Added link to Jed Schmidt's slides
9/27 1403 - Added link to Sebastian Werner's slides
9/27 1732 - Added link to Tom Hughes-Crouche's slides
9/28 1108 - Added link to Jens Arps' slides
9/28 1442 - Added link to Alexander Lang's slides (note that they require Chrome on OS X for best experience)
9/28 2330 - Added link to Tobias Schneider's slides

In Case You Missed It: JSConf.eu 2010 (day 1)

2010-09-25T14:44:00.011-05:00

This weekend, the second annual JSConf.eu conference was held in Berlin, Germany. If you've been keeping track, this JSConf juggernaut just keeps getting bigger and more epic with each successive iteration. Continuing my series, In Case You Missed It, let's take a peek at this weekend's published schedule and the accompanying Twitter stream to see if the trend continues.

Day 1: Saturday, September 25, 2010

Speaker(s)	Topic
THEATRE (TRACK A)
Dion Almaer & Ben Galbraith	Using the Web to deliver the next wave of computing experiences
Peter Higgins	Your library sucks, and why you should use it
Jenn Lukas	JavaScript + Web Standards II: The Quickening
Tim Caswell	Techniques and Tools for Taming Tangled Twisted Trains of Thought (PDF)
Ulrike Müller	Server-side JavaScript the untold story
Nicole Sullivan	CSS Lint for Massive Sites
Brian LeRoux	PhoneGap: Love the Web and Lose the SDK
Ben Firshman	Lessons learnt pushing browsers to the limit (links: 1 2 3 4)
Mutwin Kraus	Using canvas to develop classic 2D games
Rebecca Murphy	The jQuery Divide
Pete LePage	Chakra: Building A New JavaScript Engine For Internet Explorer 9
/be (Brendan Eich)	Proxies are Awesome!

MUSIC SCHOOL (TRACK B)
Robert Nyman	HTML5 APIs - The new Frontier
Nicolas Garcia Belmonte	Creating Interactive Data Visualizations for the Web
Sebastian Deutsch & Stephan Seidt	If it moves they will watch (sample code)
Paul Bakaus	Aves Engine: High performance browser games
Mikeal Rogers	node.js + CouchDB == Crazy Delicious
Felix Geisendörfer	Dirty NoSQL (code, blog)
Philip Hofstetter	node.js in production use: tempalias.com
Markus Franz	Better Life with shared resources
Joe McCann	Rapid Prototyping for Multiple Platforms with JavaScript
Fabian Jakobs	Kick ass code editing and end-to-end Javascript debugging

Some of my favorite finds/revelations of the day:

Transformie: provides CSS Transforms for Internet Explorer by mapping the native IE filter API
Zynga buys out HTML5-based Aves game engine
Transloadit: cool new service to provide robust file uploading (with image resizes, video encoding, etc)
vapor.js, the smallest, fastest JavaScript library ever
Cloud9 IDE: the Javascript IDE by Javascripters, for Javascripters

Look for tomorrow's recap late in the afternoon, and as always, if there are slide decks from other talks online that I don't have linked here, please note it in the comments below, and I'll update accordingly.

Updates:

9/26 0530 - Added link to Rebecca Murphey's slide deck
9/26 1813 - Added links to Jenn Lukas & Fabian Jakobs' slide decks, and removed speakers whose sessions were cancelled.
9/26 1839 - Added link to Philip Hofstetter's slide deck
9/26 1847 - Added link to Mutwin Kraus's github repository (which includes the slides)
9/28 0549 - Added link to Brendan Eich's slides
9/28 1119 - Added link to Felix Geisendörfer's slides & recap

IE9: Microsoft Strikes Back

2010-09-16T08:22:00.000-05:00

After pretty much ignoring Internet Explorer for the last few years, I'm surprised to find myself using the latest and greatest version this morning. And so far? I like it.

The first thing I did once I got the new browser beta up and running was to check out my own site, where I've got a pretty good idea of what previously didn't work well (or at all) in IE. What I found surprised me:

What Works

Surprisingly, Canvassa! IE9 runs my little HTML5 Canvas game quite well, in fact.
My resume looks great. The only advanced feature it doesn't do right is liquid columns, but that's relatively minor, really.

What Doesn't Work

My portfolio doesn't work. Time to revisit some of that code.
The new "pinning a webpage as an app" functionality doesn't look very good for my site yet; I need to figure out what <meta> tags to include to make it look better.

Everything else seems to be working well. The new developer tools are nice, addon-disabling feature was pretty sweet, and the minimal browser chrome gets out of the way on my tiny netbook screen and lets the Web shine through. Overall, I've got to hand it to the IE team: this is a great step in the right direction, and I for one welcome the return of the Browser Wars... because Competition = Innovation.

Cloning Zelda: Candles, or the Magic of dojo.connect

2010-08-23T11:27:00.003-05:00

It's been a while since I've worked on Canvassa, my HTML5 love letter to the original 8-bit NES Legend of Zelda. If you remember last time, we worked out some kinks in the code that were causing it to crash in Google Chrome. Today, it's back to implementing missing functionality: namely, how to make the blue candle behave appropriately. Fortunately, Dojo provides us a way to do this, and it's actually a pretty cool feature of the framework. Read on to see how it works.

Step 1: Defining the missing behavior

In the original game, the blue candle was one of the first items available to you: for the bargain price of 60 rupees, you could buy it from the merchant just around the corner. As such, it had some cool functionality (damaging enemies, burning down trees), but one steep limitation: you could only use it once on any given screen. When I first implemented the candle item, it included no such limitation — mainly because I didn't want to pollute the main game loop by writing some specialized code for that purpose in the loc.Game class. Rather, I wanted to keep the game loop as clean as possible, and let all of Link's inventory items take care of themselves as much as possible.

Step 2: Framing the Problem

I determined that what I needed was a way for the candle to know when Link had moved to a new screen, and reset itself whenever that happened. This suggested the need for either the candle object to poll the player's position on a regular basis, or the player object to notify the candle object when its position changed. Neither solution appealed to me: having the candle object query the player object for anything at all seemed hackish at best (especially since proper encapsulation dictates that an owned object shouldn't be privy to all of its owner's properties), and forcing the player object to notify the candle object whenever it entered a new screen would tightly bind the two objects, requiring one to know and manage the internal state of the other — something I want to avoid if at all possible.

The solution lies in an often-overlooked corner of Dojo Base called dojo.connect, which allows us to create event listeners for not only DOM events, but any arbitrary JavaScript functions that we want. Here's how DojoCampus describes it:

// When ob.onCustomEvent executes, customEventHandler is invoked:
dojo.connect(ob, "onCustomEvent", null, "customEventHandler");
dojo.connect(ob, "onCustomEvent", "customEventHandler"); // same

In our case, we want the player inventory to be listening for an event that tells us that the game's map screen has changed. Here's how it works:

// in Player.js:

updateInventory: function{} {
...
// when Link first picks up the candle:
dojo.connect(game, 'setupMapScreen', this.resetItems);
...
}

resetItems: function() {
    // reset the candle
    game.player.inventory[3].reset();
}

// in Item.js:
dojo.declare("loc.Candle", [loc.Item, loc.InventoryItem], {
...
    available: true,
...
    getProjectile: function(args) {
        // if we're color=0 (blue), check to see if we've been used already on this screen
        if (this.available || this.color) {
            this.available = false;
            soundManager.play('candle');
            return new loc.FlameProj(args);
        }
    },
    reset: function() { this.available = true; }
});

Once you pick up the blue candle, the Player class starts listening for the Game class to run its setupMapScreen function, which is not an event. When that function is invoked, Dojo lets Player know, and it quietly resets inventory item #3 (i.e. the loc.Candle object). When the Player has the blue candle equipped, the getProjectile call, which is used to get the loc.FlameProj projectile-flame object, first checks to see if available is true, or failing that, if its color is nonzero (the red candle, which comes much later in the game, doesn't have the once-per-screen limitation, and is assigned color=1). Not too tricky, and it allows each object to take care of itself as much as possible.

The full change set for this feature is in my Github repository, which also includes several other tweaks I've made in the past several months but never had the time or inclination to blog about. If you see something you'd like to fix, feel free to fork it and give it a shot.

I'm starting to see areas where the code needs a refactoring, particularly in regards to the need for multiple game maps (i.e. for dungeons). Next time I'll begin to tackle the necessary changes to make this work.

One-page resume in CSS3

2010-08-10T10:29:00.003-05:00

Recently, I came across a really nicely done one-page resume on Scribd, and wanted to try to recreate it using the latest web technologies (no Adobe Acrobat, Microsoft Word, or OpenOffice allowed). Turns out with a few sprinklings of CSS3, it's pretty straightforward. Let's peel back the covers and take a look.

(If you want to skip straight to the result, you can click here)

Planning

First, let's take a look at what features our exemplar uses that we want to try to emulate:

grid layout (header plus 2-column flow)
pseudo-tabular formatting (Experience and Education sections)
2-column bulleted list (Software section)
custom typeface on headings

Grid Layout

This one was actually pretty easy, and didn't require any sophisticated CSS hackery at all:

/* set up a simple grid layout */
.resume { width: 860px; margin: 0 auto; }
.leftCol { width: 480px; }
.leftCol, .rightCol { display: inline; float: left; padding-right: 20px; }
/* end grid layout (see? I said it was simple) */

So we just set our .resume class to a specific width, then use the "margin: 0 auto" bit to center it horizontally on the page. We fix the width of the left column, set both left and right columns to float, and include 20px of padding to push them slightly apart. Simple, effective, and cross-browser compatible!

Tables Without <table>

If asked, most modern web developers will tell you that the practice of using <table> tags to do page layout belongs back in the "dark ages" of the Internet, but there are some things that are really hard to do without it. Knowing this, the W3C gave us a really nice solution... the CSS Table Model. In a nutshell, it gives you three new values for the CSS display property: table, table-row, and table-cell. Used together, they can turn hackish markup like this:


  2008—present
  
    Senior Computer Scientist

    White Oak Technologies, Inc., Silver Spring MD

... into this, slightly-more-verbose-but-less-hackish markup:


  2008—present
  
    Senior Computer Scientist

    White Oak Technologies, Inc., Silver Spring MD

Even better, we can employ some CSS class names and get basic semantics:

/* new table-display style: works in pretty much all modern browsers except IE before v8 */
.expJob, { display: table-row; }
.expDate, .expDetail { display: table-cell; }
.expDate { width: 7em; }
.jobTitle { font-weight: bold; display: block; }
.jobLoc { font-style: italic; }


  2008—present
  
    Senior Computer Scientist
    White Oak Technologies, Inc., Silver Spring MD

So is this a bleeding-edge, CSS3 feature? Not actually, no. It's from CSS 2, and since Internet Explorer 8 was released, it's been supported in all current-generation browsers. As is often the case with these types of things, only IE6 & 7 are the spoilsports. The thing is, though? I'm not inclined to care that much if my site looks a little different in some older versions of IE. The default, unstyled behavior isn't bad, it's still readable, just not quite as visually appealing:

Old and Busted:

New Hotness:

This is an example of Graceful Degradation (albeit not a very impressive one), which is a pretty good idea to use when designing sites with features that aren't ubiquitous across all browsers.

Liquid Columns

So after those last two, not-all-that-new CSS techniques, here's something that is a new CSS3 feature. So-called "liquid" layout basically just means that you write the content (say, a magazine article), then make it flow into the layout you want to give it later on. Historically this has been somewhat problematic in the Web world, but that's changing. One of the agents of that change comes in the form of the new CSS Multi-column Layout Module. In this instance, we want the bulletted list under the "Software" heading to flow across two columns, making better use of the space available in the resume's right column. This can be easily accomplished with two CSS properties, column-count and column-gap (currently, these are only in the latest releases of Firefox and Webkit-enabled browsers like Chrome and Safari, so we'll include the vendor-prefixed versions):

/* new super-cool CSS3 multi-column layout;
  only in Mozilla/Webkit for now,
  but it degrades to a regular list just fine */
ul.software {
  column-count: 2; column-gap: 2em;
  -moz-column-count: 2; -moz-column-gap: 2em;
  -webkit-column-count: 2; -webkit-column-gap: 2em;
}


  software
  packages
  I
  grok

Most browsers will render this as:

Non-liquid (single column):

Current versions of Firefox and Webkit, which both support multi-column layout, will instead do this:

Liquid! (two columns):

This is another case where the default behavior looks fine, and the new CSS features just make it a little bit nicer. The cool kids call this Progressive Enhancement, which is really just Graceful Degradation seen from the other side of the river. The only difference in these two techniques is whether you design the enhanced behavior first and then patch the fallback rendering (graceful degradation), or design the default case first and then enhance it where possible (progressive enhancement).

Fancy Font

Finally, let's take a look at our typefaces. In an inversion of their common perception as Johnny-come-latelies, Internet Explorer has had the ability to include custom fonts in a web page for quite a few versions. This is a feature that the other browsers haven't fully embraced until fairly recently, and even now, every browser's implementation of the font-face at-rule is just different enough to cause anyone headaches. There's been quite a bit of traction in the past year, though, and I recently discovered a great site that has taken the collective findings of great web font pioneers like Paul Irish and others to make custom web fontography almost (not quite, but almost) a no-brainer: fontsquirrel.com.

Browsing FontSquirrel's list of available free font kits, I found ChunkFive, which looks like a pretty good match for the font in the resume we're trying to match. FontSquirrel provides hundreds of @font-face kits for free download, so we just grab the kit for ChunkFive, extract it to a folder on our web server, and link to it with a single line in our header:


<link rel="stylesheet" href="/fonts/chunkfive/stylesheet.css" type="text/css" charset="utf-8"/>

With the cross-browser details abstracted away for us by this stylesheet, all it takes to use the new font is an ordinary CSS font property:

.header h1 { font: 32pt/24pt 'ChunkFiveRegular', Arial, sans-serif; }
h2 { font: 1.7em/1em 'ChunkFiveRegular', Arial, sans-serif; }
h3 { font: 1.2em/1em 'ChunkFiveRegular', Arial, sans-serif; }

For any browser that doesn't support @font-face yet (notably including most mobile browsers), the ChunkFive font kit suggests providing fallbacks to Arial and sans-serif, so we do just that. Just like that, we take the look of our resume from blah:

... to Bam:

Et Voila!

Having done all of the above, here's my final product. (If you don't have a browser that supports off of these features, you can see a PDF version here). If I had more time and creativity, I would have made a phony resume for Peter Parker instead, but you get the idea.

Once I'd gotten this far, I realized several things that would make it even better:

It would've been pretty cool (although ultimately kind of pointless) to create the header logo on the fly in Canvas
This format doesn't include the number of years of experience on skills / technologies / software
It also doesn't have "accomplishment" bullets on experience / education sections.
There should be a way to get a full list of jobs instead of just the few selected ones I chose here.
Maybe add a Publications section (including this blog, of course)...?
Use more semantic markup, in particular Microformats.

Microformats will give your data some computer-processable meaning, which sites like Google are starting to use to good effect. But we'll save that for another day. The rest of these quibbles are just stylistic choices, really. A one-page resume isn't designed to carry every single piece of information a potential employer or client needs to make a decision, it's to grab their attention. I think this does that job pretty well.

Slaying the Beast

2010-08-04T23:42:00.003-05:00

So tell me if this sounds familiar:

goal: build up my online portfolio.
how I'll do it: maintain a regular blogging schedule (this, too, I'll write more about soon)

Yeah, not so much. Instead, the past 6 months of my life have been swallowed up by a ravenous beast known as "graduate school," that has grown more and more aggressive in the past 3 or 4 weeks. I dealt it a mortal blow when I passed my defense on Monday the 19th, but it limped along for a while, whispering to me of Target Audiences, Proper Whitespacing, and Nested Bookmarks. Today, I think it finally gasped its last breath, but I have to wait until tomorrow for the official word from the ~~graduate reviewer~~coroner.

So, this is me saying "I'm back." I have a half-dozen half-finished posts in draft, way more free time than I'm used to, and a lot to catch up on.

See you soon.

In Case You Missed It: TXJS

2010-06-09T07:28:00.037-05:00

Last Saturday was the inaugural TXJS (Texas JavaScript) conference in Austin, Texas. Unfortunately, as with JSConf, I wasn't able to attend, but I still wanted to stay abreast of its happenings. Just as I did with JSConf, I've looked over the schedule, picked through the Twitter stream, followed the presenters, and where possible, found links to the slides they each presented. All for you, Dear Readers (well, for me too... but mostly for you ;) ).

So anyway, without further adieu, here we go!

In Case You Missed It: TXJS

Saturday, June 5, 2010

Speaker(s)	Topic
TRACK A
Douglas Crockford	ECMAScript 5: the New & Improved Parts
John Resig	JavaScript on the Mobile Web
Dan Webb	Building @anywhere: A Client-side Interface to Twitter
Paul Irish	10 Things I Learned from the jQuery Source
Nicole Sullivan	The Top 5 Mistakes of Massive CSS
Tom Hughes-Croucher	JavaScript Everywhere! Creating a 100% JavaScript web stack
Juriy Zaytsev	Dive into ECMAScript 5
Peter Higgins	It's Just JavaScript
Brian LeRoux	F#$% Yeah, Mobile JavaScript
TRACK B
Tom Occhino	Front End Abstractions at Facebook
Mike Taylor	Regressive Enhancement, or HTML5 for crappy browsers (PDF)
Joe McCann	Rapid Prototyping with JavaScript
Eugene Lazutkin	Dojo for Programmers
Alex Sexton	Breaking The Cross Domain Barrier
Andrew Dupont	How Custom Events Will Save The Universe
Brandon Aaron	Special Events: Beyond Custom Events
Tim Caswell	Writing a real-time game with NodeJS
Kyle Simpson	Web Performance & UI Architecture
TRACK C
Douglas Crockford	The JSON Saga
Jeffrey Van Gogh	Reactive Extensions for JavaScript
John Hann	Sneak Peek: Cujo - Dojo, CSS3, MVC
Jason Huggins	JavaScript Frameworks & Functional Testing (panel, no slides)

As of now, this is what I could find. If there are slide decks from other talks online that I don't have linked here, please note it in the comments below, and I'll update accordingly.

Tidbits

2010-05-25T13:55:00.000-05:00

As of this morning, JSConf 2010 videos are starting to make their way online. I'm looking forward to virtually experiencing the Piratey goodness for myself.

Oh, and I'm starting to fix/update the Canvassa mapping tool, still needs some optimizations and bugfixes, but at least it's not completely broken anymore... yay?

Finally, I've recently found myself on an insanely-accelerated timetable to finish my Computational Linguistics MA thesis in the next 3 weeks or so, so you can probably expect my next post or two to reflect that preoccupation. Provided I find anything in the course of writing it that deserves the (slightly) larger platform.

Solved: Cannot find -lgcc_s on Cygwin 4.3.4

2010-05-22T23:19:00.005-05:00

For the past week or so, I've been trying to build the Giza++ language modeling tools on my Windows machines, and have been having quite a bit of trouble. Permissions errors on Windows 7, weird "missing separator" error messages that were completely unhelpful (it means your text editor has replaced all tabs with spaces), and so on. Compile and build errors that have kept me up late into the night on several occasions lately, but which I was ultimately able to untangle with a little applied Google-Fu.

Despite my best efforts, though, I was stymied by this error:

g++  -Wall -W -Wno-deprecated -O3 -DNDEBUG -DWORDINDEX_WITH_4_BYTE -DBINARY_SEARCH_FOR_TTABLE optimized/Parameter.o optimized/myassert.o optimized/Perplexity.o optimized/model1.o optimized/model2.o optimized/model3.o optimized/getSentence.o optimized/TTables.o optimized/ATables.o optimized/AlignTables.o optimized/main.o optimized/NTables.o optimized/model2to3.o optimized/collCounts.o optimized/alignment.o optimized/vocab.o optimized/MoveSwapMatrix.o optimized/transpair_model3.o optimized/transpair_model5.o optimized/transpair_model4.o optimized/utility.o optimized/parse.o optimized/reports.o optimized/model3_viterbi.o optimized/model3_viterbi_with_tricks.o optimized/Dictionary.o optimized/model345-peg.o optimized/hmm.o optimized/HMMTables.o optimized/ForwardBackward.o -static -o GIZA++

/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lgcc_s
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
make: *** [GIZA++] Error 1

My initial web searches didn't illuminate much: the "-lgcc_s" bit in the error report pointed to a problem with Libgcc, but that library is part of GCC, and Cygwin installs it just fine when you tell it to — I should know, I've (re)installed Cygwin on two different machines 3 times in the past few days! So, what could the problem possibly be...? Tonight, I finally found the answer, with a nudge in the right direction from this blog:

'-static' option makes gcc to avoid the use of shared libraries. '-static' is supposed to make gcc use -lgcc_s and '-dynamic' to make gcc use -lgcc. Actually, Cygwin and gcc 4.3.4 are not coming with 'libgcc_s.a'. Something's wrong, but I'm not sure here. Anyway, in order to compile, it is necessary to change '-static' to something. For instance, if '-static' was removed, it would be okay!

This reminded me of something I read in the "Getting Started" guide to Moses, the statistical machine translation system I'm trying to use as part of my Computational Linguistics MA thesis:

OS X doesn't support static linking (here's more info), so we need to tweak two Makefiles. GIZA++-v2/Makefile:

15c15
< LDFLAGS = -static
---
> LDFLAGS =

mkcls-v2/Makefile is OK

Aside from the questionable logic here ("we need to tweak two Makefiles", but then the second one "is OK"? Hmm, if you say so...), this clicked into place alongside what the first blog said. If OS X doesn't support static linking, I'm willing to bet that Cygwin on Windows doesn't either. I edited the Makefile — taking care to preserve the tabs on save this time — and made the suggested change to the LDFLAGS assignment line. This time, when I ran make, it worked! Problem solved, finally.

Now, I can go to bed. :)

JSConf 2010: Final Thoughts and Links

2010-05-04T13:57:00.003-05:00

Today I saw in my blog reader that Guillermo Rauch over at DevThought has posted his list of JSConf links, similar to mine (Day 1 and Day 2). He's got a few links I haven't got in mine, but I have some he doesn't, too (he only listed Track A talks). So in the interest of cross-pollination, I've updated my posts and will give him a heads-up of my additions as well, when I can (my work firewall blocks his site for some reason).

Also, in the interest of pointing out other coverage of the best pirate-themed JavaScript conference on the East Coast, here are a few other blogs that have posted cool wrap-ups:

Cowboy, a.k.a. Ben Alman, posted this great summary of the talks he attended, complete with photos
Kevin Dangoor posted a similar wrapup to his own blog, with some nice commentary on Day 1 talks.
Ted Leung did a great overview of the conference as a whole
Rey Bango posted a bunch of awesome video interviews he took while attending. Go. Watch. I'll wait.

Oh, and in only-slightly-related news, I'm now on Reddit. Don't know that I'll post there much, but thought it was worth mentioning.

Finally, a note on plans. I think enough people appreciated these "In Case You Missed It" posts, that I'm going to try to keep doing them — at least when the conference interests me. Here are the next few I've got my eye on covering, time permitting:

Conference	Date
GDC Canada	6-7 May
Google I/O	19-20 May
TXJS	5 Jun
VSLive!	2-6 Aug
GDC Austin	5-8 Oct
JSConf.eu	25-26 Sept

Deep thought of the day

2010-04-28T12:19:00.002-05:00

Interesting advice from a former code monkey who quit his job to follow his dreams:

"If there’s one thing I’ve learned about living a life it’s that you need to keep moving, and if there’s another thing it’s that you really should quit your job every once in a while and take on something new, maybe even something that seems crazy and scares the hell out of you"

- Jonathan Coulton

Something worth thinking about.

How to move to Blogspot and keep your blog on your own domain

2010-04-25T21:38:00.001-05:00

Recently faced with the problem of how to have my blogs remain in their pre-existing locations while complying with Blogger's mandatory move away from FTP publishing, I think I've found a pretty easy solution: if you're on a LAMP server (which I suspect most of you are; it's nearly ubiquitous), it's as easy as removing all other index.* files and creating a new index.php file in the appropriate folder, and dropping in these 5 lines of PHP code, changing the URL in the first line as appropriate:

$session = curl_init("http://your.web.address");
curl_setopt($session, CURLOPT_HEADER, 0);
$content = curl_exec($session);
curl_close($session);
echo $content;

cURL is the secret sauce in there, and I could go into a lot more depth, but if you don't need to worry about authentication or anything more complex than a simple page-fetch, there's no need. I allow the post-comments and labels pages to link directly to Blogspot, and I use Feedburner to host my RSS feeds, so this simple solution gets me 95% of the way there. The rest is just resource-management and wise template design.

I love it when something that looks like it'll be difficult turns out to be so easy! But please, if I'm doing anything that opens me up to possible security problems (I don't think I am, but...), please let me know in the comments.

In Case You Missed It: JSConf.us 2010 (day 2)

2010-04-23T10:03:00.008-05:00

Here's part 2 of my attempt to distill the juicy bits from last weekend's JSConf presentations (here's part 1). Of course, this is only a pale imitation of the experience of actually attending the conference, but hopefully it will serve to keep you, dear readers, up to speed on the latest, bleeding-edge movements within the JavaScript community. Let's get to it:

In Case You Missed It: JSConf.us 2010

Day 2: Sunday, April 18, 2010

Speaker(s)	Topic
TRACK A
Mike Ball & Evin Grano	SproutCore: Introducing Greenhouse
Dmitry Baranovskiy	Raphaël the Great
CommonJS Panel Discussion	JavaScript Outside of the Browser - Where it is and where it's going! (wait for the video)
Makinde Adeagbo	Primer: Facebook's 2k of JavaScript to power (almost) all interactions
John-David Dalton	All you can leet - Coding for performance, CSS engines, and sandboxed natives
~~Felix Geisendoerfer~~	~~Dirty NoSQL~~ (cancelled due to Icelandic ash)
Jed Schmidt	A (fab) approach to web apps
Justin Meyer	Thin Server Architecture and JavaScriptMVC 3.0 (site)
Steve Souders	The Best of Steve
Marak Squires, @ScurvyConf Master	hook.io: the crowd favorite from ScurvyConf
Billy Hoffman	JavaScript's Evil Side (introducing Zoompf)
/be (Brendan Eich)	"An Introduction to JavaScript" (was actually a discussion of JS's future; wait for the video)
Alex Russell	Google Chrome Frame
TRACK B
Jonathan Julian	Hangover.js
Shea Frederick	Ext JS App UI Morphing
Kyle Simpson	Dude wheres my UI Architecture
Adam Moore	Running YUI 3 on Node.js
Dean Landolt	Pintura, Perstore and Awesome-Oriented Persistence
Suvajit Gupta	Colossal JavaScript
Malte Ubl	JavaScript - The Private Parts
David Furfero	Sexy.js Boots Bundles Binding
Rob Tsuk	Mojo: Developing and Building a touch UI framework for mobile using the Web (or, Writing webOS Services in JavaScript)
Gonzalo Cordero	Creating custom modules using YUI3
~~Alexandre Morgaut~~	~~Taking over the enterprise one hook at a time~~ (cancelled due to ash)
Jan Lehnardt	Evently: Declarative CouchDB Applications that practically write themselves
Brian LeRoux	PhoneGap Hack Around
Tom, Jenn, Adam & Derek	JavaScript. @$#*% yeah. (wait for the video)
Ray Morgan	Mustache is simplifying your templates
Brian LeRoux	best of wtfjs

As with Part 1, this is what I've been able to find so far. ~~A lot of the Track B and panel discussions were largely unscripted, and I'm pretty sure Track B wasn't taped, so~~ A lot of the slide decks haven't shown up online yet, so I've tried to link to the most relevant blogs talking about the topics in question. In a few instances (e.g. Rob Tsuk's talk on Mojo/webOS development for Palm), I've failed to find much of anything relevant online, so we'll have to wait and see what (if anything) eventually finds its way online. This is of course one of the big reasons why actually attending a conference is preferable to just reading about it after the fact, and I highly encourage you to take that opportunity when it presents itself.

As before, if there are slide decks from other talks online that I don't have linked here, please note it in the comments below, and I'll update accordingly.

Updates:

2010-04-23: @Getify corrected my bad assumption about the Track B talks, so I've revised the last paragraph.
2010-04-26: Gonzalo Cordero just posted his YUI3 talk slides, so I've added them.
2010-04-27: Dude sent me the link to JDalton's slide deck, so I've added it to the Track A listing.
2010-05-05: Paul Irish graciously shared his copy of Justin Meyer's JavascriptMVC notes, so I've linked them in.
2010-05-12: Tom Hughes-Croucher posted his JSConf recap on the YDN Blog, and it included refs to a couple of the Yahoo presentations that I'd been missing. They're now linked into the table.

In Case You Missed It: JSConf.us 2010 (day 1)

2010-04-20T11:33:00.020-05:00

Last weekend, the second annual JSConf conference was held in Washington DC. If you've been reading for a while, you know I went last year and loved it. This year, unfortunately, my work and personal schedules conflicted, so this week I'm playing catch-up: looking over the published schedule, then picking through the Twitter ~~stream~~firehose to find the presenters, and where possible, the slides they presented.

In doing this, it occurred to me that there may be value in what I'm putting together, at least until the conference's producers can catch their breath and upload the session videos (which, experience tells me, might take a little while). With that introduction, I present to you the first of what may become an ongoing series, which I'm calling In Case You Missed It:

In Case You Missed It: JSConf.us 2010

Day 1: Saturday, April 17, 2010

Speaker(s)	Topic
TRACK A
Douglas Crockford	Really. JavaScript.
Michael Erlewine	Mozilla's JetPack
Ben Galbraith, Dion Almaer, & Matt McNulty	Solving Device Fragmentation: How Do You Support 12,320 Different Mobile Platforms?
Francisco Tolmasky	Socratic: Documentation Done Right
Jenn Lukas	JavaScript and Web Standards Sitting in a Tree
Ryah Dahl	Less is More in Node.js
Tobias Schneider	Flash is dead, long live Flash! (Gordon: a pure-JS Flash replacement)
Aaron Newton	Programming To Patterns (per Guillermo Rauch)
Tom Hughes-Croucher	Piratin' the YQL way
Aaron Quint	Making Bacon: Making Code (video, blog)
TRACK B
Chris Williams (JSConf co-creator)	How I Pulled off JSConf
Brian Mitchell	JavaScript's Twin (Lua for JavaScript developers)
Jeremy Ashkenas	A Cup of CoffeeScript
Paul Irish	Progressive Advancement on the High Seas of Web8
Zach Carter	Build your own programming language with JavaScript
Michael Mahemoff	The Lost Hacks Ridiculous Browser Tricks from the World of Single-Page Applications
Nikolai Onken	The browser controlling hardware real pirate hackery
Nikolai Onken & Tobias von Klipstein	What the heck are HTML5 Apps?
John Resig	Call for a better DOM API
Kevin Dangoor & Patrick Walton	Bespin: the extensible in-browser code editor
Jeffrey Van Gogh	The Reactive Extensions for JavaScript
Alistair MacDonald	WebGL Demo Overload
Matthew Fowle	New Web Architecture *

As of this morning, this is what I could find. If there are slide decks from other talks online that I don't have linked here, please note it in the comments below, and I'll update accordingly.

Footnotes:

This is actually Matthew Fowle's ScruvyConf presentation; he did his Track B presentation slides on the fly.

Updates:

2010/04/20 1:12pm - akahn mentioned in the comments that the title of Aaron Quint's talk was wrong; I took the original published name, but the slides carry a different one. The table now reflects both.
2010/04/20 2:35pm - Looking over this table, I realized I'd left off the entire back half of Track B. It's there now.
2010/04/20 10:13pm - Ray mentioned in the comments that Jed Schmidt's (fab) talk was moved to Day 2 Track A, so I've removed it from the Track B list here.
2010/04/25 - Matthew Fowle sent me his contact info, so I've linked him up above.
2010/04/28 - Chris Williams has provided me more of the slide decks that the presenters gave to the JSConf organizers. I will be putting these online and linking to them as they become available; this morning I've linked up Tobias Schneider's Gordon slides.
2010/05/04 - Guillermo Rauch over at DevThought has posted his list of JSConf slides, and had a few I'd missed; I've added these now.

Cloning Zelda: Meet Canvassa's Little Brother

2010-03-05T01:03:00.001-05:00

I recently received an email from Rune Andreas Grimstad, requesting my permission to use some of the data assets I created for Canvassa (specifically the map data and sprite tiles). You see, he's doing a Zelda clone of his own — for Silverlight (like his blog title suggests, "It should be fun").

Anyway, I'm happy to share... especially since the game design and sprites aren't mine in the first place! ;) But even my code is there to be shared — that's why I put it on GitHub, after all. Anyone else who wants to use that stuff can either fork the Github repo directly, or just grab it and use it. All I ask in return is a quick note like Rune's, to let me know about the project, so I can link back to it and throw a few clicks your direction.

MUGEN plugin for SyntaxHighlighter

2010-02-13T15:33:00.002-05:00

Earlier today, I uploaded my first blog post that needed to include MUGEN source code. Between this site and my MUGEN-centric blog, I suspect it won't be my last. So, I took the time to put together a plugin for Alex Gorbatchev's excellent SyntaxHighlighter, and now I can post blocks of MUGEN code that get auto-magically highlighted, like this:

[State 1000, fireball]
type = Projectile
trigger1 = AnimElem = 1
ProjID = 1010
projanim = 1010
projhitanim = 1020
projremanim = 1020
projcancelanim = 1020
velocity = 6,0
offset = 0,-80
; HitDef
attr = S,SP
hitflag = MAF
guardflag = MA
animtype = medium
priority = 4,Hit
damage = 40,5
pausetime = 4,4
sparkno = S9992
guard.sparkno = 0
hitsound = S2,2
guardsound = S3,0
ground.type = Low
ground.slidetime = 8
ground.hittime  = 8
ground.velocity = -6,0
air.velocity = -2,-2

Anyway, I thought this was worth sharing, so for anyone interested, you can download a copy of the MUGEN brush for SyntaxHighter right here.

Cloning Zelda: Fixing Chrome

2010-02-13T10:19:00.002-05:00

This week, an epic snowfall in the mid-Atlantic states kept me home from work for four straight days, giving me lots of spare time to play with my kids, and work on some side projects. One of these was addressing a long-standing problem with Canvassa: namely, why it was broken in Google's Chrome browser.

The initial impetus for this task came from a comment left by Gaby de Wilde on a recent blog entry, in which he asked if I knew why the project wasn't working on Chrome. I was a bit embarrassed to admit that I wasn't sure, so it drove me to look into why.

Step 1: Get My Feelings Hurt

First stop was to fire up Chrome and open the JavaScript Console. Then I loaded up the main Canvassa URL and examined the error console. Sure enough, after loading several of my class files, it barfed on Game.js. Unfortunately, due to the nature of Dojo's on-demand script loader, the console didn't actually tell me WHY that class didn't load.

Given that the error console wasn't being very forthcoming, my next stop was Douglas Crockford's JSLint code-validation tool. Needless to say, it lived up to its billing and "hurt my feelings," at least a little bit. It turns out I was cutting quite a few corners that Crockford argues shouldn't be cut: omitting semicolons, defining my variables wrong, and not filtering for..in blocks seem to be my most common errors. Firefox and IE don't care about this sort of thing; they just blithely ignore it and carry on with what you intended to say, instead of making a scene in front of the entire classroom, going on about how "rules are for everyone, including you, Mister Potter."

Ahem.

Step 2: Learn Something About Chrome's Canvas Implementation

Once JSLint had issued me 50 demerits and was satisfied with the quality of my Game.js class file, I uploaded the fixed copy to my web server and went back to Chrome to reload the main page. Success... for a few minutes anyway. After playing the game for a few minutes, I began to notice that the game would, at seemingly random times, appear to "freeze up" and stop drawing its sprites. After a few seconds, though, they would all come back and the game would resume. Opening the JavaScript console again, I noticed that the freezeup occurred every time the app generated a flood of these errors:

Error drawing game sprites: DOMCoreException [in game_drawSprites(default)]

I added some additional logging to the game_drawSprites() function, and was able to determine that the exception was occurring in two cases: when Leevers or Zolas went under the ground/water, and when Link killed monsters. Looking for commonalities in those two cases, I found the answer: in both the "digger"-type monsters' animations, I defined the "under water/ground" animation — which should be invisible to the player — by specifying the animation frame's sprite coordinates as outside the boundaries of the source image. Looking in monster/_base.js, the base class for all monsters, I saw that I was doing this same thing in the default monster-death animation:

// /loc/monster/Zola.js: 'underwater' animation definition:
  this._stateDefs[4] = { name: 'underwater', ... anim: [
     [ {x:900,y:900,t:120} ]
  ]};

// note that the monsters.png image is 160x304 pixels, so (900,900) is off the edge

// /loc/monster/_base.js: 'die' animation definition:
  { name: 'die', ... anim: [
    [ {x:64,y:16,t:6},{x:80,y:16,t:3},{x:200,y:16,t:20} ]
  ]}

// again, (200,16) is beyond the 160x304 edge of monsters.png

When I originally set up the sprite animation system, I thought I was being terribly clever to define "invisible" animation frames in this way. My good buddy Firefox just ignored these calls, or at the very least failed quietly, so no sprite would be displayed for that animation tick. Chrome, however, doesn't see this as clever at all: if you try to pass invalid x,y coordinates to Canvas's 2d context object's drawImage() function, it throws a big, loud exception.

Of course, my approach had one other problem as well: if I ever expanded the monster sprite tile image to include more sprites, these supposedly "invisible" animations could suddenly be showing frames of some other sprite's animations! Yeah... bad idea.

Step 3: Go With What I Know

As with my last Canvassa update, the solution to this problem came to me by way of my MUGEN experience. With that game engine, the way you define an "invisible" animation frame is by using a sprite index of -1 (note that MUGEN's animation frame format is spriteX, spriteY, offsetX, offsetY, time):

; teleport: disappear and reappear behind my opponent
[Begin Action 1200]
1200,0, 0,0, 5
1200,1, 0,0, 5
1200,2, 0,0, 5
-1,-1, 0,0, 20  ; invisible for 20 ticks before re-appearing
1200,3, 0,0, 5
1200,4, 0,0, 5
1200,5, 0,0, 5

So, adopting this convention, I made the following, small changes to my code:

// /loc/Sprite.js: added this single line to draw():
   if (cut.x === -1 || cut.y === -1) { return; } // (-1 means "don't draw me")

// /loc/monster/Zola.js: changed the 'underwater' animation definition to:
  this._stateDefs[4] = { name: 'underwater', ... anim: [
     [ {x:-1,y:-1,t:120} ]
  ]};

// /loc/monster/_base.js: 'die' animation definition:
  { name: 'die', ... anim: [
    [ {x:64,y:16,t:6},{x:80,y:16,t:3},{x:-1,y:-1,t:20} ]
  ]}

Once I made those changes and uploaded them to my server, I reloaded the game url in Chrome, and it ran without a hitch. Go on, see for yourself.

So MUGEN saves the day (again). I'm always pleasantly surprised when experience in one realm helps me solve problems in another, but considering how often it happens, I really shouldn't be. Experience is experience... no matter what language or platform it comes from.

Why data transformations are hard (part 2)

2010-02-01T10:03:00.002-05:00

Previously, on Palagpat Coding...

In Part 1 of this post, I talked about how I was going to attack my task of converting an XML-based format for file transcription (XCES) into the flat-but-structured EFR-segfile format. At the end of the day, I'd gone with a quick-and-dirty solution in Visual Basic 6, as both XSLT and my Bat'leth tool seemed to fall short. Here's a sample of the input and output of that effort:


  
    
    Lunchtime
    !

// EFR-segfile output:
0-1164 (00:00:00:00 - 00:00:38:24)
Scene 1: T1S
//T: Lunchtime!

As I mentioned last time, I took this EFR-segfile output and loaded it up in my EFR authoring software to test the segment boundaries, and found that it was off... not hugely off at the outset, just a few seconds... but things very quickly went off the rails. For example, by the end of Chapter 2 (just 13 minutes into the film), my segfile segments were already off by over 7 minutes!

37020-37231 (00:20:34:00 - 00:20:41:01)
Scene 417: T303S
//T: Come on, before you catch a real cold.
//N: actual film time: 00:13:27-00:13:30

Clearly, this won't do.

What happened?

Looking things over, I realized a couple of mistakes right away: First, I had assumed the XCES files covered the full film, so I started at frame 0. However, the first dialog in the film doesn't occur until about 40 seconds in, so my output started off wrong by that much. Secondly, I started each subsequent clip from the endpoint of the previous one, thus ignoring any segments of the movie that didn't involve spoken dialog, so as the film progressed, the timestamps got more and more wrong.

At this point I took another look at my original XCES file, and it hit me that there are actually two, overlapping data structures at play:

  
     
    Get
    down
    ,
    guys
    .
  
  
    Get
    down
    .

The <s> tags, which I thought represented segments, instead appear to represent individual sentences. (with the <w> tags representing individual words... seems rather obvious in retrospect). When I looked at the format last time, I didn't give any thought to why the <time> elements sometimes came at the beginning of a sentence and sometimes at the end, but in my review I noticed a consistent trend: the instances that occur as the first child of an <s> element have an id ending in S, and those that are the last child of an <s> element have an id ending in E... S for "Start", and E for "End." So the XML structure of <s>entences and <w>ords has a sort of a superstructure that is made up of T(ranscript?) blocks of one or more sentences each. I'm guessing XCES doesn't support this kind of 3-tier structure, hence the ad-hoc markup, but as a long-time user of XML, I really would have preferred something like this:


  
    Get
    down
    ,
    guys
    .
  
  
    Get
    down
    .

But, beggars can't be choosers, and anyway, my parser isn't a pure-XSLT solution anyway, so in the long run it doesn't matter all that much, even if it does make the data purist in me cringe a little.

Shadow data

As the title of this post asserts, it's been my experience that data transformations are only rarely as straightforward as they look. Several years ago, I worked for a B2B e-commerce company that handled a lot of EDI data, both reading it and writing it. In theory, this should be a standard format: if you know the specification, you know what the data will look like. In practice, however, we found that every new company we brought on the system had their own "shadow" data structures hidden in the standard fields, just like the invisible <t>ranscript blocks in this XCES data.

The takeaway is this: when you're writing a parser for a new-to-you data format, no matter how "standard" it professes to be, never take your data's structure at face value. There may be hidden complexities, just waiting to be tripped over.

Why data transformations are hard (part 1)

2010-01-25T09:33:00.001-05:00

Per my plan for January, last Friday was the day I'd planned to have several EFR segmentation files ready for use later on in testing the software I'm going to build for my Linguistics MA capstone project.

My task for that week was to take several XML movie transcripts (in segmented, time-aligned XCES format) and spit out text files in a rather simple format I'll call EFR-segmentation (or segfile for short), which can be parsed by other pre-existing tools in the EFR toolchain. Here's a sample of the input and target formats, so we can clearly define our start and end points:

XCES format (the source):

  
    
    So
    ,
    you
    do
    like
    it
    ,
    don'
    t
    you
    ?

EFR-segfile format (the target):

2460-2520 (00:01:20:20 - 00:01:22:11)
Scene 20: T14S
//T: So, you do like it, don't you?

Since the starting point was an XML format, my first thought was to use XSLT transformations to accomplish the reformatting. I created a stylesheet, segfile.xsl, to transform the XCES data files into something closely resembling the EFR-segfile format... but it was lacking in a couple of minor-but-not-insignificant ways. Observe:

Almost-but-not-quite-segfile format:

00:01:20,664
Scene 20: T14S
//T: So , you do like it , don' t you ?

The major problem with this output is the timestamp, which in XCES is formatted like hh:mm:ss,ms. EFR-segfile's timestamp format, on the other hand, is start_frame-end_frame (hh:mm:ss:frame - hh:mm:ss:frame). The milliseconds-to-frames part is easy:

var old_format = "00:02:36,532";
var parts = old_format.split(',');
// X ms * (1 sec/1000 ms) * (30 frames/1 sec) = Y frames
var new_format = parts[0] + ':' + Math.round(parseInt(parts[1]) * 0.03);
// new_format == "00:02:36:16"

... but the rest of that format change is not so simple. We're lucky in the above segment, because there are two timestamps: one at the beginning and one at the end. This seems to be the exception, however, and not the rule, so we'll still need to keep some kind of "current timecode" variable on hand while our parser works its way through the file. Once this is addressed, a second task is to convert the segment start and end times from the hh:mm:ss:ff format into raw frame counts, since EFR segfiles require both in order to have a valid timestamp line. This is a simple enough calculation, but again, doing it in XSLT is like trying to cut a 2x4 with a hammer, when we have other tools in our toolbox.

Besides the timestamp-formatting issues, there was another glitch: the punctuation characters in the transcript line spit out by the XSLT are padded by unnecessary whitespace. For sentence terminators and splicers (periods, commas, etc), this doesn't present a huge problem. But inter-word apostrophes, indicating contractions, split up a word in such a way that any downstream term lookup routine will fail to match it properly. This kind of minor text cleanup would be a snap with my Bat'leth tool; it's designed with text parsing in mind, and has a lot of flexibility. But unfortunately, the timestamp conversion is more complex than Bat'leth's search-and-replace regular expressions can handle, so even if I used it for transcript cleanup, I'd still need another tool to do the timestamps.

Given these shortcomings, I ruled out both XSLT and Bat'Leth as monolithic solutions, although each could contribute a step to the overall parsing workflow. I really wanted to have a single piece of software that could do both parts, however, so I decided to try doing it in Javascript. Then, I fell down the hole that is cross-browser XML — which is a whole different blog post I'll have to write soon. (executive summary in one word: complicated). Given the difficulty of that approach and the pressing deadline, I ended up writing something quick and dirty in Visual Basic 6. Not my first choice, but it got the job done.

The story doesn't end there, though. One of the movies I wanted to treat was 1985's The Goonies, something of a cultural touchstone for my generation. I found an XCES alignment file for the movie in the OPUS OpenSubtitles corpus that I'm using, fed it through my parser, and got this EFR-segfile. Looked pretty good, I thought... so I fired up my EFR authoring software to verify the transcript alignment. And.... it didn't match up! Tune in later this week for part 2 of this post, when we try to figure out why.

Updated download: Bat'leth 3.1

2010-01-17T21:44:00.003-05:00

This weekend I've been working with Bat'leth, a tool I wrote a number of years ago for text processing and data format manipulation, on a project for my Computational Linguistics graduate work that I'll be blogging about soon. As I worked with it, I noticed that it was looking quite dated. It didn't support XP-style controls, some of the button images were inconsistently styled and not properly masked, and so forth. (I also found a bug or two!)

As I wrote a few days ago, I have a love/hate relationship with my old Visual Basic code: I love how easy it is to hack together a "quick and dirty" tool when I need one, and I hate how hard it is to make it actually look polished and modern when finished. Then I stumbled across an add-on for VB called vbAdvance. It extends old-school VB in some very welcome ways, including the ability to compile an XP manifest file into your apps so that they support the newer visual styles (other cool features include the ability to create DLLs with function exports, console apps with no GUI, and several other nifty bits). Though originally commercial, it's now classed as "unsupported freeware," so if you or anyone you know does any work in classic VB, this is well worth your time.

Anyway, thanks to vbAdvance and a little surplus time this weekend, I've updated Bat'leth to version 3.1, now available on my downloads page as both an install package and full VB6 source code. Enjoy, and let me know if you find this at all useful.

Dear Visual Basic: It's not you, it's me

2010-01-14T12:31:00.002-05:00

I just read a great article over at O'Reilly, 7 reasons I switched back to PHP after 2 years on Rails. It's a few years old, and the comments thread is practically a flamewar between pro- and anti- Ruby on Rails people, but the article itself raises some great points — not about how awesome PHP is, but about the art and science of software design. The author, Derek Sivers (founder of CD Baby) had this to say about a developer's perennial urge to rewrite old code:

But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now! You look back at your old ugly PHP code, compared to your new beautiful Ruby code, and think, "God that PHP is ugly!" But don’t forget you wrote that PHP years ago and are unfairly discriminating against it now. It’s not the language (entirely). It’s you, dude. You’re better now. Give yourself some credit.

I love that! This week I've been re-visiting a lot of my old Visual Basic code to get some things freshened up for my Downloads page, so I can absolutely relate. Looking over the code, it's easy to dismiss it as simplistic and over-reliant on hacks to accomplish its aims. So Sivers' article was a nice reminder to me that the language itself isn't the problem (well, mostly), it's just the way I wrote in it. So if time allows, I'll be revisiting a few of these tools in the coming weeks with an eye to make them better.

Downloads: now with source code

2010-01-13T19:58:00.002-05:00

I've fixed the broken links on my Downloads page. So far there are mostly only zip archives with the VB6 source code, with only one app that actually includes an installer. I intend to upload more binaries and/or installers soon; tonight I'm working on an update to Bat'leth that will help me do some work on my grad school project (I'll post more on that effort on my root blog in a day or two)

Broken downloads

2010-01-13T07:47:00.004-05:00

So a few days ago I posted an update, in which I discussed moving the ancillary pages here on the site to PHP. Part of that update included a link in the titlebar to a refreshed version of my Downloads page, which includes a handful of tools of various levels of usefulness I've built over the years. Well, apparently I made the changes too late at night or too early in the morning, because I forgot to update the links to the actual downloads themselves! I'm at work now and can't access my FTP server, but I'll make the necessary changes tonight so that anyone who wants to download my tools... can actually do so.

Minor update

2010-01-11T23:16:00.004-05:00

Just like I did with my MUGEN blog a few days ago, I've updated this site to use PHP instead of static HTML pages. Not a huge thing, but at least now the site's subsections (currently Canvassa and Downloads) have a prominent location in the toolbar, and all pages on the site (except the blog index, since Blogger can't generate PHP) can reuse the same header/sidebar/footer resources.

View-Source is Good?

2010-01-08T09:48:00.005-05:00

Alex Russell, founder and president of the Dojo Foundation, recently wrote on his blog about the importance of "view source" to the evolution and growth of the World Wide Web:

Web developers get started by taking some code, pasting it into a file, loading it in a browser and switching between editor and browser between even the most minor changes. This is a stark contrast with other types of development, notably those that impose a compilation step on development, in which the process of seeing what what done requires an intermediate action. In other words, immediacy of output helps build an understanding of how the system will behave, and ctrl-r becomes a seductive and productive way for developers to accelerate their learning in the copy-paste-tweak loop. The only required equipment is a text editor and a web browser, tools that are free and work together instantly. That is to say, there’s no waiting between when you save the file to disk and when you can view the results. It’s just a ctrl-r away.

As I read the above quote, it hit me: this is exactly why I love developing in old-school Visual Basic, and why even now VB.NET doesn't feel natural to me. For almost 10 years, my work was primarily done in Visual Basic 5 (and later 6), where the normal process of development runs something like:

Design something in the UI
Write an event handlers for the UI component
Run the app in debug mode and test the new feature
Break program execution and tweak the event handler
Continue program execution and test the revised code
Repeat steps 1-5 as necessary

This is precisely the same reason why I love web development so much: the immediacy of the feedback loop, the ability to see your changes almost as you make them, and to, essentially, evolve the code to achieve your end goals. Tools like Firebug have made this process even easier, allowing me to actually poke and prod UI elements in runtime without having to change and refresh the underlying code. And I absolutely love the ability to see a cool effect coded by someone else, and do the old "right-click, inspect element" to see how they did it.

Interestingly, the parallels between VB and the web don't end there. From time to time you hear developers of languages like Java and C++ pooh-pooh both Visual Basic and Javascript as being somehow "inferior". The simple syntax, lack of a compiler and need for a runtime are somehow seen as negatives, even though the trend from the beginning has always been towards more, not less, abstraction.

Now, do I use VB6 for all of my Windows desktop development? No, I also code in C++, C#, and sometimes even batch scripts. Do I use JavaScript for all of my web development? No, all of my back-end and template code is typically written in Python, PHP, and the like. But for when I need a simple tool to do a simple job, simple code wins every time.

Happy Birthday, Canvassa

2010-01-01T17:31:00.003-05:00

I just realized it's been a year since my first post detailing my efforts to re-create The NES Legend of Zelda in Javascript and HTML5/Canvas. I'm currently on hiatus, recuperating from minor sinus surgery earlier in the week, but I have an update in mind for later this month.

Until then, enjoy the current version here, and have a happy 2010.

Cloning Zelda: Harmful Changes (and a Christmas Miracle)

2009-12-24T08:56:00.002-05:00

Yesterday's post, which I called "Harmless Animations", led to me making a stupid – and harmful – change that I should have known better. It's worth talking about what happened, and why.

When I first implemented the loc.Explod class and the four SwordFlash elements, this is what the code that added them to the game screen looked like:

terminate: function swordProj_terminate() {
    game.insertProjectile(new loc.SwordFlashNW({'pos':this.getPos(),'owner':this.owner}));
    game.insertProjectile(new loc.SwordFlashSW({'pos':this.getPos(),'owner':this.owner}));
    game.insertProjectile(new loc.SwordFlashNE({'pos':this.getPos(),'owner':this.owner}));
    game.insertProjectile(new loc.SwordFlashSE({'pos':this.getPos(),'owner':this.owner}));

    this.inherited(arguments);
}

When I was blogging about the new code yesterday, I "streamlined" that function a bit to look like this:

terminate: function swordProj_terminate() {
    var myPos = this.getPos();
    game.insertProjectile(new loc.SwordFlashNW({'pos':myPos,'owner':this.owner}));
    game.insertProjectile(new loc.SwordFlashSW({'pos':myPos,'owner':this.owner}));
    game.insertProjectile(new loc.SwordFlashNE({'pos':myPos,'owner':this.owner}));
    game.insertProjectile(new loc.SwordFlashSE({'pos':myPos,'owner':this.owner}));

    this.inherited(arguments);
}

Do you see what I broke? It's probably not at all obvious... it certainly wasn't to me. I thought that I was optimizing the code by only running getPos() once and passing its value to all four child explods. But last night, I went to change the live code to reflect the blog post, in case anyone wanted to examine the new bits in context. When I did so, my sword flashes stopped behaving right! If the sword hit a monster, all four explods sat still in the exact spot where they were inserted, and if the sword made it to the end of the screen, two of them would come straight back, rather than at their proper angles. What the heck did I do?!?

I really should have known better, since this has tripped me up before. To explain what the difference is in these two code blocks, you need to know what the getPos() method (which is inherited from loc.Sprite) actually does:

getPos: function sprite_pos() {
    return dojo.clone(this.pos);
}

dojo.clone() is a cool little function. In a nutshell, it creates deep copies of JavaScript objects, which is tremendously useful if you want something approximating a struct datatype. This is exactly how I'm doing (x,y) pairs in Canvassa, which I use for both sprite position and velocity:

dojo.declare("loc.Sprite", null, {
    pos: {x:0, y:0},
    vector: {x:0,y:0},
...
})

The problem comes when you try to reuse one of these position values, which is precisely what the second code block tried to do, and is precisely why I created the getPos() method in the first place! Since a sprite's position is an object and not a struct, I need to dojo.clone() it to get a copy of its contained values instead of a copy of its pointer reference (see Jonathan Snook's explanation of why JavaScript works this way). Now, I'm not a n00b programmer. I've been around the block a few times, and have coded in nearly a dozen different languages in my time, and in many of them I was well aware of this Pass-by-Reference/Pass-by-Value distinction. And yet, in an effort to clean up my code, I managed to instantiate four separate SwordFlash explods and give all four of them the same position object! So when the game told them to update their positions, each in turn would modify its position object relative to its personal velocity:

// let's assume the starting position is {x:32, y:64}

// in SwordFlashNW.updatePosition():
this.pos.x += -3;  // {x:29, y:64}
this.pos.y += -3;  // {x:29, y:61}

// SwordFlashSW.updatePosition():
this.pos.x += -3;  // {x:26, y:61}
this.pos.y += 3;  // {x:26, y:64}

// SwordFlashNE.updatePosition():
this.pos.x += 3;  // {x:29, y:64}
this.pos.y += -3;  // {x:29, y:61}

// SwordFlashSE.updatePosition():
this.pos.x += 3;  // {x:32, y:61}
this.pos.y += 3;  // {x:32, y:64}

// end position for all four: {x:32, y:64}

So when all four explods were operating on a single, shared position object, the net result was no movement at all! And when, in the edge case, two of the explods went off the screen and were removed, the other two combined forces to push the position in a single direction. D'OH!

So, hopefully this time I've learned the lesson well enough that it'll sink in: my sprites' pos and vector values are objects, and I need to call getPos() EVERY time I want a non-interfering copy. Sure, it's not as profound a December lesson as "I will honour Christmas in my heart, and try to keep it all the year," but it'll do.

Happy Christmas to all, and to all a good night!

Cloning Zelda: Harmless Animations

2009-12-23T12:41:00.002-05:00

So.

Long time no update, eh? (at least, it's been a while since a substantial update)

A few weeks ago, I added something new and kinda cool to Canvassa. We've had sword projectiles for a while now, but it felt like something was missing... in the original game, when a thrown sword hits an enemy or a wall, you get this cool effect that the above screenshot shows off: a handful of flashing shards that fly off in 4 different directions. I'd been missing these, and wanted to add them to Canvassa, but I was afraid I had a "painted into a corner" situation on my hands: the game engine I'd built up so far had a couple of different types of sprites it handles, and the sword shards don't really fit any of them:

Player
- used for: player main sprites
- movement: user-controlled
- attributes: can be hurt if touched by a monster or projectile
Monsters
- used for: octorocs, tectites, etc.
- movement: autonomous (via AI)
- attributes: can be hurt if hit by player's weapon or projectile
Items
- used for: small hearts, rupees, etc.
- movement: none (except for fairies)
- attributes: can be picked up if touched
Projectiles
- used for: throwing sword, octoroc rocks, etc.
- movement: pre-determined
- attributes: can do damage if it touches a player or monster

Sword shards don't neatly fit into any of these boxes: they aren't controlled by the player or an AI, and while they do move in a predetermined way and can't be picked up (like projectiles), they don't hit obstacles or do damage to anything the way projectiles do.

As I mulled over the problem of how to implement these shards, inspiration struck: the MUGEN Explod construct! For the past several years I've developed something of a name for myself as a programmer (and occasional graphic artist) of custom characters for the open MUGEN fighting game engine. In my time working with that programming model, I've become familiar with its 4 tiers of sprite object hierarchy:

Player
- used for: the character's core sprites
- movement: user-controlled
- attributes: can do damage and be damaged
Helper
- used for: extensions of the character such as weapons, clones, etc.
- movement: user-controlled or autonomous
- attributes: can do damage and be damaged
Projectile
- used for: things thrown/shot/expelled by the player
- movement: pre-determined
- attributes: can do damage and be blocked (but not hurt, per se)
Explod (no, I didn't misspell it)
- used for: used for visual effects such as dust or hit sparks
- movement: pre-determined
- attributes: cannot do damage or be damaged

The above 4-way distinction between MUGEN sprite types seems to map pretty well to the engine I'm building, and it's a metaphor I'm familiar with, so I determined to apply it. For my purposes, Explods act almost exactly like Projectiles, except for two things: they don't do damage to anyone (or anything), and they have a time limit, after which they get removed from the screen. So the simplest thing to do is to subclass the loc.Projectile class and override the default behavior for these two differences:

dojo.declare("loc.Explod", loc.Projectile, {
    timeout: -1,
    constructor: function(args){
        /* required args: 'pos' and 'owner' (inherited from Projectile)
           optional args: 'timeout' (defaults to -1, meaning it never gets removed) and 'vel' (movement velocity) */
        dojo.mixin(this, args);
    },
    hit: function explod_hit() {
        // do nothing when making contact with another sprite
    },
    updatePosition: function() {
        if (this.timeout-- == 0) {
            this.terminate();   // when timeout runs down, tell the game to remove me
        }
        this.inherited(arguments);
    },
    _animateCurrent: function explod_animateCurrent() {
        return true;  // override default behavior to animate even if motionless
    }
});

View the code

Simple, right? Now, when I need an Explod-type effect, I simply subclass loc.Explod and add the necessary animation details. For the shattering sword, I defined four SwordFlash subclasses, one for each of the four shards created when a SwordProj projectile is terminated (NW, SW, NE, and SE, for the direction they move). In each, I specified the initial velocity and timeout values to be used (though I could also specify these during object instantiation, if I wanted to override the defaults):

dojo.declare("loc.SwordFlashNW", loc.Explod, {
    constructor: function(args){
        dojo.mixin(this, args);
        this.width = 8; this.height = 10;
        this.vel = {x: -3, y: -3}; this.timeout = 10;
        this._stateDefs = [ { faceted:false, nextState: 0, canMove: true,
            anim: [ [{x:152,y:11,t:1},{x:160,y:11,t:1}] ] }];
    }
});

View the code

With these four classes now defined, all I had to do was add a custom terminate() function to the loc.SwordProj "throwing sword" class, using it to insert a new instance of each explod into game.projectiles:

terminate: function swordProj_terminate() {
    var myPos = this.getPos();
    game.insertProjectile(new loc.SwordFlashNW({'pos':myPos,'owner':this.owner}));
    game.insertProjectile(new loc.SwordFlashSW({'pos':myPos,'owner':this.owner}));
    game.insertProjectile(new loc.SwordFlashNE({'pos':myPos,'owner':this.owner}));
    game.insertProjectile(new loc.SwordFlashSE({'pos':myPos,'owner':this.owner}));

    this.inherited(arguments);
}

View the code

You can see the results here.

If you clicked the above link and tested out the new feature, one thing you likely noticed is that the sword only works if you have full health; get touched by a monster, and suddenly you can't attack anymore... lame! Next time, we'll look at how the MUGEN Helper construct can help us fix this problem.

Blogger is Busted (or, Hacking your Template to Eliminate the "a[...] is null or not an object" Error)

2009-12-03T12:08:00.006-05:00

Earlier this morning, I posted a quick test to see if backlinks are working with Blogger-powered blogs posting to FTP, as I'm doing. Turns out that they're not (note the absence of backlinkage on that page I just linked to).

Now, this isn't a huge problem for me. Would I like the ego-stroking that comes with having backlinks, showing that people like what I'm doing enough to share it? Well, sure I would. But is it worth the pain and hassle? No. So I went into my blogger settings panel, and disabled all the bits pertaining to backlinks, and removed the backlink scripts from my custom template.

Unsurprisingly, this didn't solve the underlying problem -- my site was throwing JavaScript errors! I already knew what was causing the errors: as I said in my previous post, Blogger is auto-inserting some invalid-in-my-context JS code after every post, precisely where the </Blogger> tag lies in my template. Searching around a bit more, I found a solution at Google's Blogger support forum:

Kham
Level 1
8/29/09
This has done the trick for me.

Wrap all instances of <blogger> and </blogger> with both the HTML and JavaScript comments.
<!--/* <Blogger> */ -->
<!--/* </Blogger> */ -->

Stupid, stupid, stupid! Since I can't get Blogger to stop inserting the offending code, I have to force it to be commented out! Maybe it's time to take another look at alternative blog engines...

Blogger Backlinks

2009-12-03T11:17:00.004-05:00

The following link is to my previous post; I'm testing to see if that post recognizes it as a valid backlink: Palagpat Coding: Cloning Zelda: And Lo, There Came... an Archive!

A little background: I publish via Blogger's "post to FTP" option, rather than using the apparently-more-kosher Blogspot hosting. Apparently, in late June of this year, other bloggers doing the same thing began seeing mysterious blogs of javascript getting inserted into their published files, most frequently showing up in people's <title> tags, and thus in search results (see for yourself in a Google search for the offending string). If backlinks aren't actually functional in my blog configuration, then I'm going to try turning them off to see if it solves the problem.

Cloning Zelda: And Lo, There Came... an Archive!

2009-12-02T00:14:00.003-05:00

Short update tonight. Bullet points, because I love 'em so much:

I've added a few pretty keen new tidbits to Canvassa, and will be blogging about them soon.
Speaking of Canvassa, I've revamped the Canvassa Archive page with a more up-to-date (and relevant) development roadmap, including links to all related blog posts on each finished task.
Updated and cleaned up the navigation toolbar; it should now degrade better for IE and mobile users.
New favicon / site logo. Whaddayathink?

Javascript Snippet: Flip Text Upside-down

2009-11-06T13:21:00.006-05:00

This week I was playing with my Google Analytics account to see what was happening with my blogs; it turns out that my MUGEN blog is about a bajillion times more popular than this one. Guess I'm learning, as Arthur Conan Doyle did, that you don't get to pick what you're known for (sigh). That said, the most popular post here on the ol' Coding blog was this one, where I talked about my home-grown tag cloud generator. So, although Canvassa isn't going to be dropped, I'm going to pepper in more of these "snippets" types of articles from time to time... like today!

Back in April of this year, YouTube did an April Fool's joke where they turned their site upside-down by means of a sneaky little code snippet that swapped out all alphanumeric characters with characters that looked like upside-down versions of themselves (for example, 6 became 9, M became W, etc). Later, Paul Irish adapted the code into a jQuery plugin. Still later, I followed his lead and adapted the code as a Dojo plugin, and posted it on Twitter. But I never blogged about it here.

In fact, it's even been in one of my Github repositories for months now, completely undocumented save its internal code comments. Surprise!

Click here to flip all the posts on this page, re-arranging them from top to bottom, or click here to flip their text in place without moving it around.

I wanted to go back re-implement the code as a bookmarklet, but it's currently dependent on (and namespaced in) Dojo, so that didn't get done. Maybe for the next snippet.

Oh, also of note: I've re-arranged my site template a bit, moving navigation from the sidebar to the header, adding more social networking links to my profile, and pushing it further down the sidebar. This is part of my effort to harmonize all three of my blogs into a single site, and there will likely be more changes before that effort is complete.

Update, 11/30/2009: Some recent template changes to the blog have broken the dynamically-loaded code in this post; I'm working on a fix.

Cloning Zelda: 0.5.x

2009-10-26T08:25:00.003-05:00

I'm not exactly sure what release number this is, or if such things really even apply to an experimental web game I operate on "live." But anyway, I wanted to give a brief "State of Canvassa" update on my recent changes.

A couple of my recent changes are completed tasks from my recently posted bug list for version 0.5:

Add text to the page describing the game controls
Fix projectile management (I wasn't tracking them correctly, especially the sword)

The other changes are things I added because I felt they were necessary and/or appropriate to be done at this time:

Added a "please wait" text blurb and animation to indicate game loading state
Re-encoded the music at lower bitrates: smaller file sizes, and more accurate to the original sounds.
Added a preliminary savegame screen; for now it just lists the available quest(s)
Added a few of the missing sound effects to the game (bombs boom, Link grunts when hit, etc)

As always, there's plenty to work on, and more coming soon.

Cloning Zelda: Adding a Title Screen

2009-10-14T10:54:00.007-05:00

First, a note on the server move: you may have noticed that my domain was offline for a few days last week; this was because I flubbed the domain transfer to my new server. Anyway, all was eventually straightened out, and I've successfully migrated all of my content from the old server to the new one. If you see anything here on the site that's broken, post a comment and let me know.

Now, on to today's subject: in trying to add several new states to the Game class for Canvassa, I've learned something interesting about Javascript's in operator: it doesn't really work for arrays! More specifically, it does in fact work, just not the way one would expect.

I do a lot of work in Python. In that language, you can do something like the following, and have a reasonable expectation of success:

>>> myList = [5,10,15,20]
>>> print (10 in myList)
True

So in a nutshell, you can define a list of values, and then check a reference value for membership in that list. Simple, and useful. I was doing this in Canvassa's Game class to test for the existence of a caller-specified game state before actually changing to the new state:

    this.constants.states = { overworld: 0, inventory: 1, 
                              dungeon: 2, map: 3, 
                              dying: 4, gameover: 5, cheat: 99, 
                              enum: [0,1,2,3,4,5,99] };
    ...
    changeState: function game_changeState(newState) {
        if (newState in this.constants.states.enum) {
            this.currentState = newState;
            this.drawBG();
        } else {
            console.log("Game.changeState() -- invalid state:", newState);
        }
    }

So basically I was using game.constants.states.enum as a list to keep track of the valid state values that changeState() should accept. Since the states I was using were all 0-based and sequential (except for the "cheat" state, which I haven't tested since Part 2 or so), this worked just fine. But in truth, it wasn't actually doing what I thought it was doing, as I was about to find out (dun-dun-DUN!)

I've been bothered for a while now about how I was loading the quest data (which handles map layouts, item and monster placement, and so on). Basically I was using the dojo.require() function to lazy-load the _quest1.js file, which doesn't actually contain a dojo class definition, but simply assigned the quest data to a namespaced variable, loc.gameData, which my classes could then refer to as a global. All kinds of poor, hackish behavior going on there. Plus, I'm building this game engine to support multiple (and, eventually, user-created) quests, so hard-coding one into the game bootstrapping logic is stupid and short-sighted. In order to correct this egregious flaw in the least destructive way possible, I reasoned, I should add several new states to the Game class, using negative integers to represent these meta-states that exist outside the regular game loop:

    this.constants.states = { title: -1, menu: -2, loading: -3,
                              overworld: 0, inventory: 1, 
                              dungeon: 2, map: 3, 
                              dying: 4, gameover: 5, cheat: 99, 
                              enum: [-3,-2,-1,0,1,2,3,4,5,99] };

In theory, the game engine could now start in the title state, and when the player presses start, change to the menu state, then allow quest selection from there. (for now, I'm simply XHR-loading _quest1.js when the user presses start, and will add the menu state later). But instead of working as I expected, this is when everything started to fall apart. I made the above change and a few others that would direct the game to load the necessary image resources, and then call game.changeState(game.constants.states.title) to display the title screen. BOOM! JavaScript error:

Game.changeState() -- invalid state: -1

Spending some time testing various expressions in the Firebug console, I eventually figured it out: the 'in' operator, when applied to JavaScript arrays, tests for the existence of a given index, not value! Observe this little exchange from my Firebug console:

>>> game.constants.states.enum
[-3, -2, -1, 0, 1, 2, 3, 4, 5, 99]
>>> -1 in game.constants.states.enum
false
>>> 8 in game.constants.states.enum
true

Like I said on Twitter when I discovered this: Freaky! I spent a few minutes looking at ways to get around this apparent misbehavior on JavaScript's part (I've since come to terms with why it works the way it does, but it's totally counter-intuitive to my way of thinking), and found this method, suggested by JavaScript rockstar Jonathan Snook.

In JavaScript, there's an in operator that tests whether a property is in an object. We can actually use this to mimic the PHP function in_array.
if(name in {'bobby':'', 'sue':'','smith':''}) { ... }
If the value of name matches any of the keys in the object literal, it returns true.

Jonathan then offers a refinement via a small function that takes a string array as input, and returns an object literal that can then be tested for membership via in. A reasonable approach, but not really one I wanted to pursue, if something simpler would work. This is what I came up with:

    this.constants.states = { overworld: 'overworld',
                              inventory: 'inventory',
                              dungeon: 'dungeon',
                              map: 'map',
                              dying: 'dying',
                              gameover: 'gameover',
                              title: 'title',
                              menu: 'menu',
                              loading: 'loading',
                              cheat: 'cheat' };
    ...
    changeState: function game_changeState(newState) {
        if (newState in this.constants.states) {
            this.currentState = newState;
            this.drawBG();
        } else {
            console.log("Game.changeState() -- invalid state:", newState);
        }
    }

Et, voila! Simple and elegant. I still have my pseudo-enumeration of valid game states, but I've eliminated the unnecessary "enum: [1,2,3...]" construction, and changed the state values from meaningless integers into strings that matched their own keys. Now my code can still refer to states via their game.constants.states.* enumeration values, and in works as expected, since those strings resolve as properties of the game.constants.states object literal.

There was a little more code cleanup necessary to support this change (for instance, I had to define a list of "unpausable" states so that the user wouldn't be able to put the game in pause mode from the title screen), and there are still a few lingering, unrelated problems in the 0.5 codebase, but we now have a title screen, and the ability to add new game states and check for their existence. All in all, a good night's work.

Cloning Zelda: Progress and a Change of Methodology

2009-10-02T09:00:00.004-05:00

So those of you who are hitting the work-in-progress Canvassa build may have noticed that I've added sound support back in. It's not very Dojo-y at the moment, but I got tired of not hearing anything as I tested, so it's in. I've also got the bug about predefined items (e.g. the sword on screen 1) reappearing after you pick them up.

The other major change in the Canvassa effort is how I'll be measuring progress. I started out treating it almost as a tutorial of how to build a game like this in JavaScript+Dojo, and to a certain extent I'll continue to do so, but the posts will stray from the "Part 1 / 2a / 2b..." format that I've been using, and go to a slightly more traditional "dot release" approach: right now I'm working on version 0.5, and when it's finished and the Github repository is updated, I'll move to v0.6. All development will be done in the work-in-progress Canvassa location, so no more Part 1 / Part 2 / etc. subfolders. Hopefully this will be easier for me to work with and stay on task, and will be more in line with what you, my faithful reader, would want to see anyway. (of course, if I'm wrong in my estimation, feel free to let me know in the comments).

Beyond that, not much else has progressed this week; I'll be moving this blog and my others to my new host soon, and I'm still trying to decide how exactly I want to set things up (one of the main points of uncertainty is whether to keep the three blogs separate, or merge them into a single stream with tags/categories to differentiate them. If I do merge the blogs, I'll keep my RSS feeds the same (I'll re-orient the FeedBurner links to point to the appropriate places), so those of you reading me through a feed reader probably won't notice much of a difference. Hopefully, I'll be able to get the buyog.com domain transferred over smoothly to my new host as well, but if not, the buyog.net domain will get you to the new content. When the move actually happens, I'll make a note of it here so you're all aware.

Canvassa 0.5 Bug List

2009-09-24T18:15:00.000-05:00

Thought I'd peel back the curtain a little tonight. Here's what's left to do with my Canvassa Zelda clone before I can call version 0.5 (i.e. Part 5) done and ready to move on to 0.6:

Add text to the page describing the game controls
Fix projectile management (I'm not keeping track of them correctly, especially the sword)
Add the sword projectile "flash" effect when it hits something
Limit the blue candle to a single use per screen
Make Link & the monsters get knocked back when hit
Fix the number of hits required to kill monsters (esp. Zola)
Permanently remove predefined items from the map when picked up (e.g. the wooden sword on the start screen -- grab it, leave the screen, then come back: it's there again!)
Make killed monsters leave behind hearts and rupees (fairies and clocks come later)
Split Items.js file into multiple subfiles, parallel to what Peter Higgins did to Monsters.js for me last week

I'll be working on a few of these things tonight; maybe even have a more verbose blog post to go along with it (hope springs eternal, anyway)

Cloning Zelda: With a Little Help from my Friends...

2009-09-16T13:25:00.002-05:00

My Twitter friend Peter Higgins, who I've mentioned before, has been following my progress on Canvassa for the past several months, and last week he sent me a brief message, asking if I'd be okay with him forking the code on Github to re-arrange the overall structure of the app and make it more Dojo-y. I said sure, because anytime you've got someone with his programming chops offering to partner with you to help make your code better, you don't say no!

So anyway, a few days later, Peter sent me a Github pull request to take a look at his branch, and yes, it's quite different. So different, in fact, that I haven't yet figured out yet how to integrate his changes back into the trunk! But a couple of things jumped out at me:

He moved all of the namespaced code (basically all of my Dojo classes) into a subfolder off the main folder, so now you have /loc/Canvassa/index.html for the main page, but the game classes all live in /loc/Canvassa/loc.
He split up the Monster classes into individual .js files, and put them in a subfolder under the namespaced folder (/loc/Canvassa/loc/Monster)

In the short term, this has resulted in a LOT more http requests when the game is initially loaded. Long-term, though, it'll help since you only have to download the monster classes that have actually changed instead of re-grabbing the entire code glob when I tweak something about, say, the Octorok's behavior. And when the long-awaited day arrives that I put the "it's done" seal on this project, I can use Dojo ShrinkSafe to merge and minify all of the code into a single package, eliminating the multiple-http-requests problem.

For the time being, I've put my working copy of Peter's branch on my site here. It's slightly more functional than the version in my Part 5 working copy, including updates to medicine (it works), bait (it kinda-sorta works, but doesn't affect enemy AI yet), and the bombs and candle (they both more or less work now, but don't destroy scenery yet). But in the process of those updates, I somehow managed to break the boomerang, so I need to fix that before I attempt to merge it back into the trunk and blog about what I did to implement the new item behaviors. Hopefully that'll be a simple fix; I suspect I just broke something minor in the loc.Item base class.

Cloning Zelda: Back-to-School update

2009-09-09T09:49:00.004-05:00

After taking a sanity break from my JavaScript/HTML5/Canvas Zelda clone I've been making for the past several months, I've started banging on it again, but haven't been able to muster the energy to actually blog about it, perhaps because the things I've been doing aren't all that technically interesting, just important to do (case in point: I've had the bow & arrow working for a while, but until yesterday's update, it wasn't tied to your rupee count as it was supposed to be). As of this morning, the sword, boomerang, bow, and magic wand are all working more or less as they should be (you can't throw the boomerang diagonally yet, and the wand produces magic waves without you actually waving it, but those are both minor quibbles like the arrow-rupee thing), and I've implemented a cheat code to grant you all items so you can actually, y'know, test them (hint: it uses the Konami Code, or you can just mash the "ALL ITEMS" button down in the corner of the screen)

A couple of the remaining items, however, promise to be interesting: bombs and candles both behave differently than standard projectiles, and the flute, bait, and letter aren't projectiles at all (well, I suppose you could think of the bait as a projectile in the same way that the bomb is, but still... it doesn't actually kill enemies, just attract them). Each of these has the promise of interesting blog fodder:

bomb: drop a bomb, and after a moment it spawns multiple "explosion" artifacts
candle: spawns a flame projectile, but it only goes a limited distance and not clear across the screen like the others
flute: spawns a whirlwind object that picks up the player and warps them to the location of the dungeons
bait: like the bomb, since you just drop it instead of throwing it -- but it doesn't explode or kill the enemies, it just alters their AI behavior
letter: causes the old lady NPC to sell you medicine
medicine: refills your health and then self-destructs

So as I implement these remaining items, I may jot some notes about why each is interesting to implement, and then I'll have something worth talking about here.

Meanwhile, go see the stuff that's already done here

NES Emulator in JavaScript? No Way!

2009-08-19T21:55:00.003-05:00

Yes way, Ted: JSNES. What this means to me personally: well, I'm going to continue working on Canvassa, because ultimately it's the quest builder that I'm most excited about. But, I've still got to duplicate the existing functionality before I try to rewrite it all. This summer has ended up being much more hectic than I'd anticipated, but the work will progress, and I'll try to be better about my weekly updates here, even if it's just to post to cool stuff like this JavaScript-based NES emulator. Tell me that thing's not inspiring to all you JS hackers out there. At least, it is to me.

Next Cloning Target...?

2009-07-23T00:21:00.006-05:00

I know I owe a Canvassa update, and seriously, it is coming -- I've just been distracted lately. By things like this awesome fan-made MegaMan game being made:

A few months ago I met Ryan McGrath at JSConf 2009 (a Javascript developers conference), and he mentioned to me that he'd been toying with making a web-based MegaMan game. His comment, and seeing what MegaPhilX and N64Mario are doing with this custom MegaMan engine, has put the "bug in my ear," so to speak. So at some point in the future when I'm done working on the Zelda clone... well then, looks like it may be MegaMan's turn.

Hiatus?

2009-07-14T11:27:00.002-05:00

Quick Tuesday post this week, with a request for feedback embedded at the end.

I'm posting this from work while on my lunch break. Last Friday, something of a dam burst here at work, and I'm now flooded with work to do, where a week ago I was a little light on projects from time to time. This has the side effect of giving me less time to think about the content I'll be producing for the site here... although I actually did the vast majority of my blog work "off the clock", there were lulls where I could at least brainstorm solutions to problems (like the whole "Math Wall" thing, for example) -- now, not so much.

On top of this massive shift in my work environment, I spent last weekend moving my family into a new home / state / city / etc. This means a home new internet provider is necessary... and they won't be able to come and hook me up until this coming Friday. So... the big loser in all of this is my blogging. Once my home internet is up and running again I should be back in business, but until then things are, sadly, on hold.

Now, to that request for feedback I mentioned at the beginning of this post: I've recently set up a new domain at buyog.net, and have installed a WordPress-powered blog over there. Here's the question: should I merge my three Blogger-powered blogs (Buyog's World (the root blog), Buyog's Lair (the MUGEN blog), and Palagpat Coding (this web programming/gaming blog) into a single master blog, separated by categories? The content of these three blogs, and presumably the resulting audience for each, seems to me to be so diverse that merging them would be counter-productive. But I'm interested in seeing what people think. Let me know below in comments, or feel free to email me at buyog2099(at)gmail.com.

Watch this space

2009-07-08T17:13:00.002-05:00

I know, I'm late again with my weekly Tuesday update, and for that I apologize. The short explanation is that I'm moving this week, so am very much in the thick of packing right now. I have Part 6A of my "Cloning Zelda" series almost ready to go, but haven't had the time to write it up right, yet. I'm shooting to get it up before the move this Friday, but if that doesn't happen, look for a more-substantial-than-usual update next week.

Firefox 3.5

2009-06-30T23:49:00.002-05:00

Quick post this week; there's too much going on in my personal life (see my root blog for details) for a full update.

After months of anticipation, Firefox finally released version 3.5 today. And I must say, so far it seems very worth the wait. If you're still using Internet Explorer (even the better-but-still-nonstandard version 8), you owe it to yourself to give Firefox a try.

Also, to make this just a tiny bit more related to my blog, I tested the latest Canvassa pages (the game, Bestiary, and Mapper) in FF 3.5, and they all seemed to benefit from the new-and-improved JavaScript engine.

Next week (or sooner), I hope to have a new post up in the Cloning Zelda series... if I can just get the item states / animations resolved.

Simple tag cloud generator in JavaScript

2009-06-22T23:12:00.012-05:00

After having to roll my own tag cloud generator for my blogs (I'm old-school, so I don't have access to a blog layout engine with prebuilt widgets), I thought I'd clean up the code and share it. So, it's in this new repository I just created on GitHub.

Usage is pretty simple; copy the JS (and optional CSS) to your server, and link to them from your blog code like so:

  <style type="text/css">
    @import "http://www.myblog.com/css/tagCloud.css";
  </style>
  <script type="text/javascript" src="http://www.myblog.com/js/tagCloud.js"></script>

Once you've got it loaded, there are only two steps to create a new tag cloud: first, you need to populate a JavaScript object with the tag information structured like an associative array, with the tag names as properties and the instance counts for each tag as its hash value. Ideally this will be retrieved via an AJAX/XHR request, but in a pinch you can hard-code it (but that's not terribly useful, since you'd have to constantly update it whenever you post something new):

    // hard-coded, pure JavaScript version:
    tags = {
      "JavaScript":17,
      "Conferences":2,
      ".NET":1,
      "GeoWeb":1,
      "Site news":1,
      "snippets":1,
      "Dojo":16
    };
    function init_tagCloud(parentId) {
      var parentDiv = document.getElementById(parentId);
      if (parentDiv) {
        var cloud = makeCloud(tags, "http://www.myblog.com/labels/", 0,1,4,' ');
        parentDiv.appendChild( cloud );
      }
    }
    window.onload = function() {
      init_tagCloud('target_div');
    }

    // or, Dojo-powered and XHR-populated (substitute JS lib of your choice):
    dojo.addOnLoad(function() {
      dojo.xhrGet({
        url: "getBlogCategories.php",
        handleAs: "json",
        load: function(data){
          tags = data;
          var cloud = makeCloud(tags, "http://www.myblog.com/labels/", 0,1,4,' ');
          dojo.byId('target_div').appendChild( cloud );
        }
      });
    });

The parameters on the makeCloud() method are:

tags: the object hash mentioned above
baseUrl: the URL that should serve as the base for all tag links
minCount: minimum number of times tag must be used to show up in the cloud (defaults to 0)
minSize: minimum font size for tags in the cloud (defaults to 1em)
max: maximum font size for tags in the cloud (defaults to 4.5em)
delim: delimiter(s) to insert between tags in the cloud (defaults to 1 space)
shuffle: boolean value that controls if the tags get shuffled in random order, or sorted (defaults to false)

That's about all there is to say about it. The basic math for determining the tag size is taken almost verbatim from the Wikipedia page on tag clouds, just slightly tweaked to allow for a minimum font size. Surely there are other customizations that could be made, and ideally this would be implemented as a Dojo/plugd-style plugin. I'll leave that for an exercise at a later date.

--Edit: I inadvertently forgot to strip out the <script> tags from the sample code blocks up above, and they were getting run! D'oh!

Cloning Zelda: Are we done yet?

2009-06-16T19:29:00.003-05:00

Busy with graduate school projects tonight, so this week's Tuesday post (okay, it's Wednesday morning) will be short.

The Overworld map is now implemented in the Canvassa, Part 5 main page, and I've ported the Map Maker utility too, albeit in an optimized way (you have to actually click on a map screen in order to see its thumbnail, instead of having the page draw the entire map. I'm working on ways to draw all the thumbnails without bogging down the machine, but none of them are fully fleshed out yet).

Left to do before I close out the Part 5 code branch:

Port over the rest of the inventory/items code
Implement better map boundary checking (it's currently possible to slightly overlap walls and such)
Post over the hit collision code from the earlier iteration.

Once I've finished the above tasks, I'll consider the rewrite/re-engineering effort a success, write the final "Part 5" blog post, and move forward to Part 6. Depending on my school load the rest of this week, that may happen sometime before next Tuesday. If not... well, I'm sure I'll think of something.

Reminder: the most recent version of the code is also available on GitHub, if you're interested in checking out the full source code.

Cloning Zelda: Sandboxed

2009-06-10T21:25:00.002-05:00

At Peter Higgins's suggestion, I've started a public sandbox on Github, and the latest version of Canvassa is up there for your perusal. Feel free to review / fork / comment the heck out of it, if you so choose.

Cloning Zelda, part 5D: Scaling the Math Wall

2009-06-09T19:24:00.002-05:00

I blogged last week about the strides I've made with refactoring the various monster classes into the new sprite engine, and related how I got stuck, for the second time, trying to make the boomerang work right (I'd had it mostly implemented a while ago when I first decided to do the sprite engine refactoring, in large part because it didn't animate well in the old engine). Well, a few afternoons later, I knuckled down while on my lunch break and got it working. (fair warning for the math-averse: the rest of this post is going to be pretty trigonometry-heavy)

First, I owe a huge debt to a couple of sites that helped refresh my memory of vector geometry. I recalled the old "rise over run" rule for defining the slope of a vector or line, and I knew that the Pythagorean Theorem (a2 + b2 = c2) could be used to figure out the length of a vector c, given its X and Y components a and b. The rest took some memory-jogging: lbackstrom's tutorial at TopCoder.com was a good refresher, and the Slopes and Lines overview at WhySlopes.com filled in the rest (good thing, too, because my daughter is going to need me to help her with her geometry homework before I know it...)

Anyway, the basic math of the boomerang problem works like this: when thrown, a boomerang has an initial vector that determines its movement in the X and Y directions. When it reaches its apogee or hits the edge of the screen, it then reverses course, homing in on its thrower. In order to do this, the boomerang version of the Projectile class had to override the base class's updatePosition() function, which gets called from the game main loop:

main: function game_main() {
...
  // move all active projectiles
  for (var j in this.items) {
      if ("updatePosition" in this.items[j]) { this.items[j].updatePosition(); }
  }
...
}

(Note that we first have to check to see if each item in the game's item list actually has the updatePosition() function, because non-projectile items, like dropped hearts and rupees, won't.) The boomerang projectile's updatePosition() function looks like this:

updatePosition: function boomProj_updatePosition() {
    // move me to the next point on my current trajectory
    this.pos.x += this.vel.x;
    this.pos.y += this.vel.y;

    // check to see if I've gone off the edge of the screen
    var offscreen = true;
    if (this.vel.x < 0) {
        // moving left; check left edge
        offscreen &= (this.pos.x <= game.constants.screenBound.left);
    } else if (this.vel.x > 0) {
        // moving right; check right edge
        offscreen &= (this.pos.x >= game.constants.screenBound.right);
    }
    if (this.vel.y < 0) {
        // moving up; check top edge
        offscreen &= (this.pos.y <= game.constants.screenBound.top);
    } else if (this.vel.y > 0) {
        // moving down; check bottom edge
        offscreen &= (this.pos.y >= game.constants.screenBound.bottom);
    }

    // calculate distance from my owner (set in the constructor via dojo.mixin() args)
    var dx = this.owner.pos.x - this.pos.x;
    var dy = this.owner.pos.y - this.pos.y;
    var distance = Math.sqrt(dx*dx + dy*dy); // thanks, Pythagorus!
    if (this._returning) {
        // if we're already returning, check to see if we're close enough to our owner to be caught
        if (distance <= 8) {
            this.owner.catchItem();
            this.terminate();
        }
    } else if (offscreen || distance >= this.apogee) {
        this._returning = true;
    }

    // calculate return velocity, if we're on the return path
    if (this._returning) {
        // change my vector to match the direction from me to my owner; valid values are -1, 0, or 1
        this.vector = {x: (dx) ? dx/Math.abs(dx) : 0, y: (dy) ? dy/Math.abs(dy) : 0};

        if (dx && dy) {
            // vector is on a diagonal; I need to calculate both x and y components of velocity
            var slope = dy / dx;
            this.vel.x = Math.sqrt((this.speed*this.speed) / (slope*slope + 1)) * this.vector.x;
            this.vel.y = this.vel.x * slope;
        } else if (dx) {
            // dx only: horizontal vector
            this.vel = {x: this.speed * this.vector.x, y: 0};
        } else {
            // dy only: vertical vector
            this.vel = {x: 0, y: this.speed * this.vector.y};
        }
    }
}

A boomerang's return velocity is easy when it's strictly horizontal or vertical: the full measure of speed is devoted to either X or Y, respectively. The complicated part is when the boomerang is on a diagonal offset from its owner; in that case, the speed needs to be divided into X and Y components, in a ratio that matches that of the X and Y portions of the difference between the boomerang's current position, and that of the player (typically referred to as Δx and Δy, but which I called dx and dy in the code):

Subtracting the player's position from the boomerang's gives us the values for length of sides Δx and Δy: in this case, 30 and 43, respectively (note: the image is enlarged for clarity). The slope of the boomerang's velocity vector can be found by dividing Δx into Δy (Rise over run, remember?). That gives us:

slope = Δy / Δx = 30 / 43 ≈ 0.698

Now comes the tricky part: we know the total velocity of the boomerang, Vel_total, as it needs to be equal to the predetermined speed for boomerangs: 3 pixels per frame. But, we don't know either the X or Y components of the velocity, which is what we need in order to do the right thing in updatePosition(). Dredging up an old trick I learned in high school algebra, I remembered that if you have two unknown variables, you can solve them both if you can find two interrelated equations. Fortunately, we have them: the Pythagorean theorem, and the slope ratio. We'll figure out the x-component of the velocity Vel_x first, because that will make the calculation of the y-component Vel_y easy. Solving the Pythagorean Theorem for Vel_x, we get:

Vel_total² = Vel_x² + Vel_y²
         = Vel_x² + (Vel_x * slope)² -- (substituting in the slope formula: Vel_y = Vel_x * slope)
         = Vel_x² + (Vel_x² * slope²)
         = Vel_x² * (1 + slope²)
Vel_x² = Vel_total² / (1 + slope²)
Vel_x = √ Vel_total² / (1 + slope²)
    = √ 3² / (1 + 0.698²)
    = √ 9 / (1 + 0.487)
    = √ 6.052 
    = 2.460

Then, solving for Vel_y:

Vel_y = Vel_x * slope
    = 2.460 * 0.698
    = 1.717

So in this instance, the X and Y components of the boomerang's velocity should be set to 2.46 and 1.71708. Now that we've worked it out, these calculations can be done every time the game calls updatePosition(), and in all but the most extreme cases (i.e. 20 Goriyas in a dungeon room, all throwing boomerangs at the same time) this won't cause any measurable slowdown.

You can see the results for yourself, by loading up the latest iteration of the game, here. The arrow keys control the player's movement, and the Z and X keys throw the boomerang and sword, but the map and inventory screens aren't converted to the new codebase yet, so that's the next order of business. I've also added some preliminary code that should take care of preloading all necessary resources, but it's still a bit buggy, so if nothing happens when you first hit the page, hit refresh and try again. Of course you can also go to the Bestiary if you prefer, and see for yourself how the Goriyas can handle their boomerangs. Collision detection still isn't turned on yet, but I fully expect to have that for the next update.

Cloning Zelda, part 5C: Building Better Monsters

2009-06-03T01:07:00.004-05:00

Last time, I introduced you to the Canvassa Bestiary, a test page I wrote to put the new sprite class hierarchy through its paces. Since then, we've put an offer on a house and I've revised and submitted the prospectus for my MA project to my thesis committee. Plus my time commitments to my full-time job and my awesome family. So I've been a little stressed out distracted.

That said, I have added projectile attacks to the monsters that should have them... so Moblins shoot arrows, Lynels throw swords, Octorocs spit rocks, and so on. I've also stubbed in the dungeon monsters, as I mentioned before (although most of them don't have the right AI yet), so Wizzrobes are in there with their magic x-ray wavy attack... things, and Goriyas have their boomerangs... but then I hit the "Math Wall." (insert scary music here if you're so inclined). I'd intended to re-enable collision detection tonight and blog about all the cool new stuff I can do with the new sprites engine I've built, but instead I got stuck on the math needed to calculate the returning trajectory of a boomerang when its owner has moved. It's a lot more complicated than I expected it to be, mostly because I haven't had Geometry in like 20 years. (yikes!) Anyway, I'm close, but I'm also tired and ready for bed. (ugh, how'd it get to be 2:30am ?!?)

So, collisions will have to wait for the next update, which I'm (perhaps irrationally) hoping will also include the ported map engine and the game inventory screen. Then I'll be back to where I was TWO MONTHS AGO (sigh). Except I'll be cross-platform, projectiles will work, and dungeon monsters will be there. So that'll be a net gain after all.

To check out my handiwork, and fill the screen with monsters, click here.

Cloning Zelda, part 5B

2009-05-24T16:48:00.004-05:00

I haven't yet finished writing up all that I've done for the next installment of my Cloning Zelda series, but in the meanwhile, I wanted to share the test page I've created to evaluate monster behavior, AI, and state management. It's here, at the Canvassa Bestiary.

A few notes on what the Bestiary does: arrow keys allow you to move Link around the canvas. Pushing the first set of buttons and selecting different radio options will change Link's animation and appearance; right now if you push the "Die" button, Link will in fact die, and the game simulation will end; you'll have to refresh the page to start it up again.

The next two sets of buttons will let you spawn enemies into the canvas... the first group is for overworld enemies, and the second group is for dungeon enemies, which I hadn't yet tried to do. Each will spawn in the correct way for that monster type (e.g. Armos enemies start out in their statue state), and all have basic AI that will determine how they move (even Peahats, Zolas and Leevers now work more or less correctly, although Tectites still look strange when jumping). I haven't yet added projectile attacks or sprite collisions; that's why I haven't blogged a full entry about the Bestiary yet (I hope to have that for this week's regular update on Tuesday).

Final technical note: I've tested the Bestiary in Firefox 3.0.10, Chrome, and MSIE 7 (IE is sloooow, but functional). Notably, I've also successfully tested it on my Windows Mobile smartphone, in Opera Mobile 9.5 beta! Again, it's slow, but even seeing it WORK on my phone was pretty frigging cool. Hopefully the Javascript performance war that has been raging on desktop browsers for the past year, will next find its way to the mobile platforms. Ultimately I'd love to be able to develop games and apps in HTML5/canvas and deploy to both desktop and mobile browsers in one click. What a cool step forward that will be.

Mapping headaches

2009-05-19T11:35:00.004-05:00

Note: the next entry in my Cloning Zelda series is still in progress; for now, enjoy the following post on something completely different.

I've been experimenting with Google's KML standard for the past few days, as a sort of a gateway into understanding how map projections work. Remember all that trigonometry you learned back in middle/high school, and you always wondered when you would ever use it (aeronautical engineers excepted, of course: you guys probably do this stuff all the time)? Well, anyway, I ran smack into that wall head-first. The most interesting thing I've learned is WHY the Mercator projection gets so weird and distorted toward the north and south poles (warning, it's rather math-y).

Basically, Mercator's big idea was to shove the Earth into a giant imaginary cylinder, and unfold it onto the inside of this giant invisible tube, then unwrap and flatten the tube. Simple so far, right? Except for two problems: first, if you've ever peeled an orange, you know that the curved surface of a sphere (or nearly-a-sphere) doesn't lay flat unless you split it into fairly narrow strips. This is why some maps get broken into chunks: the Interrupted Sinusoidal and Waterman "Butterfly" are two of the more interesting of these, but there are a lot of others.

The second problem with rectangular map projections involves the poles, and this one was the big revelation to me: the trigonometric formula that Mercator used in his eponymous projection only works until you get close to the poles, at which point the horizontal stretching approaches infinity. No wonder, then, that Greenland looks as big as South America, and Alaska almost as big as Brazil!

Back to KML: in trying to get a handle on Mercator's latitude-to-y-coordinate formula, I realized that I couldn't define the top and bottom points of my map, because they were infinite! So, how on earth was I supposed to calculate the distances in between, if I didn't have a baseline? I whipped up a simple test KML file to plot the main latitude lines in 10-degree steps from -80° to 80° (these are white), and the main circles of latitude (Equator, Artic/Antarctic Circle, Tropics of Cancer/Capricorn) in red. My first test file also included white lines for several latitudes approaching the poles so I could get an idea of what they looked like in Google Maps... surprise! Because of the problem with infinity, Google Maps doesn't actually SHOW you the whole Earth... any lines I tried to draw further north or south than 85 degrees actually broke the map code! If you try to click on the links for N 88°, N 89°, or their south equivalents, you'll be shown a line that plots completely off the map! After some trial and error, I've determined that Google's map appears to extend from 85° north to 85° south, omitting much of the Arctic Sea and Antarctica in the process! Admittedly, this is probably no big deal to 99.99999% of the people using Google's amateur cartography tools, but it's interesting to see how Google's much-vaunted engineers tackle an intractable, literally infinite problem space.

Sticking to a schedule

2009-05-12T16:30:00.003-05:00

For the past month or so, I've been following Chris Guillebeau's blog and Twitter updates thanks to a link from Seth Godin. Even though the stuff these guys talk about has little or nothing to do with my "bread and butter" sources of income (computer and linguistic consulting), I find it fascinating to see how people transforming the collective zeitgeist about what a "career" can and should look like for our generation. Highly inspiring stuff. Case in point: in his recent publishing sensation, 279 Days to Overnight Success, Chris suggested that bloggers who, like myself, aspire to extend their personal reach, should establish a regular publication schedule for that blog. So, that's the main point of this post, which I'm going to cross-post to my root and MUGEN blogs as well.

Moving forward, I'm going to try an experiment, and we'll see if I can stick to it. If so, I may expand it out at some point, but this is probably a good place to start:

Sundays: I will post something on my root blog
Tuesdays: I will post something on my code blog
Fridays: I will post something on my MUGEN blog

I do have a new post brewing for this blog (next in the Cloning Zelda series), but it's not ready yet, so it'll most likely wait until next Tuesday to kick off this new schedule.

Cloning Zelda, part 5: Redefining the Sprite classes

2009-05-05T14:17:00.005-05:00

Too long since my last post. Moving forward, I'm going to establish a schedule for blog updates, and will work to maintain it. More on that soon.

As I've mentioned previously, my sprite classes had become something of a house of cards, which only held together in Firefox and collapsed in every other browser. Clearly, not what I was shooting for.

I also blogged last time that I got the chance to speak with Peter Higgins, the project lead for the Dojo Toolkit, at the JSConf developers' conference a few weekends ago. With his help, I've finally managed to wrap my head around how the Dojo class loader works, and have used my newfound knowledge to rebuild the sprite engine for Canvassa. (whew! that's a lot of links!)

Bottom line, for the short-attention-span crowd: click here to view the new sprite test harness, which shows off a couple of the new engine's features:

True class inheritance and dependency resolution (Player and Monster classes are defined in separate files from the base Sprite class)
Animation state and timing "cooked in" to the base classes (press the number keys to see the animations each sprite class defines)
Selective property overriding in derived classes (note the different walking speeds of the sprites)
Should be much more cross-browser compatible (Safari/Chrome/Opera users: please let me know if it doesn't work for you!)

So, the key to Dojo's load system are three commands: dojo.require, dojo.provide, and dojo.declare. The way it works is pretty brilliant: when dojo.require is called, the loader code looks to see if the requested class name exists yet in the global namespace. If not, it goes out and looks on the server for a path that matches the requested class's namespace, and if found, a JavaScript file named the same as the class in question. For example, this code:

  dojo.require("foo.bar.ClassName");

...will start looking in the location of the Dojo module, trying to find a folder named foo, with a subfolder of bar. If found, it then looks in that folder for a file named ClassName.js. If found, it then uses the DOM to dynamically insert a new <script> block into the current page's header, referencing the path foo/bar/ClassName.js. The ClassName.js file, in turn, begins by calling dojo.provide("foo.bar.ClassName") to indicate its intent, and dojo.declare(...) to actually define the class. The critical part that Peter helped me understand is that, since this is essentially injecting new code into the header at runtime, the class won't be immediately available... explaining why my code kept blowing up when I tried something like this:

  dojo.require("loc.Game");
  var game = new loc.Game();

The way to do what I was trying to do, Peter told me, was to leverage the dojo.addOnLoad() method. This registers a callback function to be executed when all requested classes have been fully loaded. The cool thing about this, Peter told me, was that you could actually chain multiple require() / addOnLoad() calls, and Dojo will do the right thing!

  dojo.require("namespace.Class1");
  dojo.addOnLoad( function() { console.log("Class 1 loaded."); } );

  dojo.require("namespace.Class2");
  dojo.addOnLoad( function() { console.log("Class 2 loaded."); } );

  dojo.require("namespace.Class3");
  dojo.addOnLoad( function() { console.log("Class 3 loaded."); } );

I mean, really: how cool is THAT?!? (answer: very.)

So now, armed with the knowledge of how to make Dojo load my classes in the proper order, I'll be able to move forward again. I should be able to leverage most of the old code from parts 2 through 4 of this series, albeit with slight tweaks to fit the new Sprite class model. And therein lies my love for Dojo: it formalizes things I already intuitively know how to do, and makes them work across all potential platforms, without any additional effort on my part. If you're not using Dojo or any other JavaScript framework or toolkit (e.g. MooTools / jQuery / YUI / etc.), why the heck not? It makes coding for the web a much more rewarding, and productive, experience.

JSConf Wrap-up and Tweets

2009-04-25T21:38:00.005-05:00

Had a fantastic weekend at JSConf here in DC. Huge thanks to my employer, White Oak Technologies, for sending my team & I.

Here's a summary of the messages I sent out from Twitter during the conference yesterday and today:

sitting in a packed conference room learning about Objective-J. No idea yet where my coworkers are at [Original Tweet]
I suppose I shouldn't be as surprised as I am that so many of the webmonkeys here are Mac people... [Original Tweet]
@jsconf track A has some cool topics, the seating is sub-optimal tho... seating in Track B is way nicer [Original Tweet]
@paul_irish just gave a great talk on web typography... awesome to see this guy in person after following his blog for months [Original Tweet]
Awesome demo of Appcelerator Titanium by @jhaynie, gotta find a way to use this.. [Original Tweet]
Despite a few glitches, the JavascriptMVC pres was pretty good. Not 100% convinced that MVC really "works" for web apps, tho [Original Tweet]
urg, stupid phone battery dying from too much wifi usage - and the kicker is that g3 is faster anyway! =P [Original Tweet]
@jeresig Awesome talk on web gaming challenges, thanks for sharing! [Original Tweet]
RT @jhaynie: @jeresig presentation was incredibly awesome. [Original Tweet]
@phiggins rocks. He's a great ambassador for Dojo, and he totally helped me iron out require/declare/provide in the hacker lounge. [Original Tweet]
@jsconf Thanks for an awesome conference. Already planning on JSConf2010. [Original Tweet]

I think the thing I enjoyed the most about this weekend, over and above the awesome food and great demos of cutting-edge advancements in my field, was the opportunity to connect with so many of my peers in the industry at large. It's really easy to get bogged down in the immediacy of the "now", so it's always nice to step back and examine why I do what I do, and why I enjoy it so much.

Oh, and Peter Higgins, the lead guy behind Dojo, gave me a little personal help in getting the Dojo load system working. So, that next article in my Cloning Zelda series is finally progressing. :)

JSConf 2009

2009-04-24T21:53:00.003-05:00

As I mentioned on my main blog, I'm attending a local JavaScript conference today & tomorrow with a couple of co-workers. Some great, great stuff today; I tried to tweet about things as they happened. Yes, as I mentioned a few days ago on the root blog, I've finally taken the Twitter plunge. My tweet stream, or whatever you call it, is here, and I've also added a "latest tweet" widget and a twitter icon to the sidebar to the right. On site-related news, I should have something to post pretty soon, now that my other commitments appear to be winding down a bit.

Cloning Zelda: pulse check

2009-04-08T14:49:00.003-05:00

I still haven't posted my next "Cloning Zelda" article yet; sorry to anyone waiting for that. I have all of the selectable items implemented and working, and had the inventory screen working too, but when I tried to implement the animation on the boomerang, I realized that the frame rate I had chosen, 10 fps, was just too low to make the boomerang work satisfactorily. Link was also slow to respond to keyboard input, because I was responding to multiple keypress events instead of having him walk continuously until the arrow key was released. I've fixed that, but it's led to some wall collision problems that I haven't resolved yet. Grr.

Sooo... "back to the drawing board" in some sense. Bumping the frame rate up to a respectable level fixed the boomerang issue, and let me implement the "flashing" effect for thrown swords (they were plain in Part 4), but now the player and enemy movements are way too fast, looking like some feudal Marvin the Martian knockoff. The solution is to rewrite the movement code for the Player and Monster classes; Monster isn't bad because it was built from the ground up with multiple-animation support built in, but animations were grafted onto the Player class quite a bit later, so it's proving to be pretty much a rewrite. Ugh.

Add to that the big "Scruffyversary" event my MUGEN development team is throwing this month, and the looming deadlines for my next-to-last (hopefully anyway) semester of grad school, and you've the the perfect storm for blogging delays.

Taking all of the above as a given, may I humbly offer a solution: since I publish all of my content via RSS through FeedBurner, I'd suggest just throwing my feed URL (http://feeds2.feedburner.com/PalagpatCoding) in your feed reader of choice. That way when I update, you'll get the new post auto-magically, without having to hit my site directly and be disappointed when there's nothing new to read.

If you don't yet know about feed aggregation, you really owe it to yourself to learn. It'll save you a LOT of time if you follow even a fraction as many web sites as I do, and in the world we live in, who wouldn't want more time?

Cloning Zelda, intermission

2009-03-18T20:47:00.004-05:00

I'm hard at work on Part 5, and I hope to get it done soon so I can put more effort into blogging about it.

Meanwhile, a couple of notes:

In making some changes to the image format for Part 5, I accidentally broke the sword sprites in Part 4. (Oops!) It's now fixed.
I added a new index page of sorts to keep track of the Zelda/Canvassa progress; it's here.
That page also includes a revised tasklist for "Phase 1" of my plans for Canvassa; dungeons and bosses would be a huge undertaking over and above what I've already bitten off, and I'm not yet sure that committing to doing it is wise for my sanity's sake.
I just discovered yesterday that my dumb CSS-based layout still doesn't render right on all browsers/window sizes. I'm about THIS close to just rewriting the whole page template using HTML tables and being done with it.
Yes, I know Part 4 doesn't work in IE or Chrome. I wouldn't be surprised if I broke it in Safari and Opera, too. :( All I can say is, I'm working on it.*

* The culprit seems to be JS-itis... I've been putting each new class heirarchy in its own JavaScript file, but they're all messily interrelated and all live in the global namespace, so it goes BOOM in every other browser besides Firefox 3. (but it works fine in FF!)

I'm considering using Dojo.require() to keep track of loading order and dependencies for me, but on the other hand, maybe I ought to just slap the whole thing into a single .js file and be done with it. Still pondering pros and cons on that one.

Cloning Zelda, part 4C: Combat (finally!)

2009-03-14T23:47:00.004-05:00

First, a technical note: I recently discovered that this blog was completely unreadable in Internet Explorer. I've been using Firefox almost exclusively for some time now, but was at a bit of a loss to explain why this was happening -- anyway, turns out it was because I was using a CSS file that specifies different rendering layouts for different browser platforms (i.e. smartphones, etc) using the @media tag -- which IE ignores! Oops. Anyway, tonight I finally tracked it down with the help of the cool IE Tab add-on for Firefox, and this blog is once again readable to users of Microsoft's wacky browser.

Now, to the subject at hand: I've decided that I'm biting off entirely too much with the original task distribution I came up with for this Javascript Zelda-cloning effort. Part 3 ended up having a Part 3A and a Part 3B, and Part 4 has ended up as 3 sub-sections: Part 4a dealt with the issue of game size, since I actually prefer playing it in its original size, but my son likes playing it in the double-sized version I originally started with. Part 4b came about because I was tired of the game being silent and I discovered a way to implement sound pretty easily. The original goal of Part 4, though, was about making the combat system work. This is now, for the most part, done; at least I'm ready to blog about it and move on to something else.

So, what did I do to finish part 4? Several things:

Added player hearts / hit points
Added player's sword (press the A button, or the Z key on your keyboard)
Added sword projectiles when health is full
Added collision detection, so monsters can hurt the player, and the player can hurt the monsters.

Those were the main points. But in order to make them work reasonably well, I had to also implement several other things:

Added a basic animation state system to the player class, since he now has several different possible animation states (walking, swinging his sword, getting hit, dying, etc)
Added a new "game over" state to the game, for when the player dies
That meant implementing the game's text system as well, because I didn't feel like hacking something temporary that would get replaced soon; my test harness for the text system is here
Started the basics of the item system, since Link needed a way to get (and throw) the sword, plus he needed to be able to pick up hearts dropped by the monsters he killed in order to replenish his health. The basics of the item heirarchy are in the new items.js class.
Plus, the aforementioned scaling and sound updates that came in with parts 4A and 4B.

The most interesting part of all of this new stuff is probably the collision detection. I implemented it by adding a new doHitTests() method to the main game loop in game.js, beautifully rendered here using Alex Gorbatchev's awesome SyntaxHighlighter tool:

this.main = function() {
    // update monster positions (but only if on the overworld/dungeon screens)
    if (this.currentMode == 0 || this.currentMode == 2) {
        for each (var enemy in this.enemies) {
            enemy.think();
        }

        // move all active projectiles
        for each (var proj in this.projectiles) {
            proj.updatePosition()
        }

        // do sprite collision tests
        this.doHitTests();
    }

    // draw everything
    this.drawSprites();
}

this.doHitTests = function() {
    // we only care about collision detection if in overworld or dungeon modes
    if (this.currentMode == 0 || this.currentMode == 2) {
        // do sprite collision tests
        var hits = game.hitTest(player.pos.x, player.pos.y, 12,12);

        // check to see if any monsters are touching the player;
        // if so, he's hurt to the tune of their relative strength
        for each (var attacker in hits[0]) {
            if (attacker.canAttack()) {     // ignore is monster is stunned or dying
                player.getHit(attacker.strength);
                break;
            }
        }

        // see if there is anything in this area to pick up
        for each (var item in hits[1]) {
            player.getItem(item);
            delete game.items[item._index];
        }

        // if there are any projectiles in play, see if they hit anything, too
        for each (var proj in this.projectiles) {
            // player-owned projectiles can only damage enemies, and vice-versa,
            // so check projectile type against hit target type
            if (proj.owner == player) {
                hits = game.hitTest(proj.pos.x, proj.pos.y, proj.width,proj.height);

                for each (var enemy in hits[0]) {
                    enemy.getHit(proj.power);
                }
            }
        }

        // note: player class handles attack collision detection internally
        // by making a call to game.hitTest(x,y,w,h)
    }
}

this.hitTest = function(x,y,w,h){
    // check all active monsters to see if they are within the
    // specified area; return a list of any that are found there
    var enemies = []; projectiles = []; items = [];
    for each (var enemy in this.enemies) {
        var dx = Math.abs(x-enemy.pos.x);
        var dy = Math.abs(y-enemy.pos.y);
        if (dx <= w && dy <= h) {
            enemies.push(enemy);
        }
    }

    for (var i in this.items) {
        var item = this.items[i];
        item._index = i;
        var dx = Math.abs(x-item.pos.x);
        var dy = Math.abs(y-item.pos.y);
        if (dx <= w && dy <= h) {
            items.push(item);
        }
    }


    return [enemies,items];
}

Not too much more to say here. The AI of some of the monsters (most notably the tectites and peahats) is still pretty wonky, and none of the monsters have projectile attacks yet, but that'll be easy enough to adapt from the sword projectiles we gave to the player in this update. The game is finally getting pretty interesting to play, and it's time to move on.

Check out the latest version of the game here: small version or large version

Next time, we'll expand on the Items class heirarchy and get the player's inventory system working.

Cloning Zelda, part 4B: Now hear this!

2009-02-27T23:12:00.007-05:00

A few weeks ago I discovered SoundManager2, a JavaScript library that uses a tiny, invisible Flash applet to enable audio playback directly via JavaScript! Awesome! But I had a heck of a time actually making the durn thing work with my data files.

First, I grabbed some WAV files for the original Legend of Zelda sound effects and music from a great LoZ resource site run by a good soul named HelpTheWretched ("Aren't online monikers fun?" says the guy who named himself after a Philippine bumblebee). I then used CDEX and its bundled LAME mp3 encoder to convert the WAV files to mp3 format. (this is a limitation of the current version of SoundManager: it can only play mp3s. No wav, no aac, no ogg. Bummer.) Finally tonight, after fiddling with SM2's troubleshooting page for a while and utilizing my mad copy/paste-fu skills, I got it to work! So if you go back to either of the Part 4 versions of the game (1x or 2x), you'll now hear the overworld music, as well as the slash of your sword!

As for the rest of the stuff that's actually supposed to be part of Part 4, namely the monster-killing stuff: I've fiddled with a couple of different options for collision testing, none of which I'm really very happy with yet. At first I thought maybe the getImageData() method on the Canvas 2d context object would be useful, and even roughed up a test to poll the sprite canvas for image data. But even though it would be pretty efficient at telling me about collisions in a particular coordinate location, I'd still have to back and figure out exactly what sprites those pixels represented. So I may just have to stick with a close approximation based on sprite sizes, positions, and velocities. I should have something worked out by next week.

Man, if "Part 3" had 2 parts, and Part 4 looks like it's going to have 3... sheesh, I think I'm going to have to rethink my original task list... =P

Cloning Zelda, part 4A: Size is(n't?) Everything

2009-02-24T22:40:00.004-05:00

As many of my half dozen readers have correctly deduced, Part 4 was another case of me biting off more than I could chew. I'm not quite done with what I set out to accomplish in this part, hence the "4a," but here's what I've done so far:

Implemented sword and heart inventory for player
Added the ability to swing your sword (alas, it doesn't hurt the monsters yet... but then again, they don't hurt you yet, either)
Added initial "spawn" state to enemies
Coded up the scaling functionality that I've been building

The full writeup will come soon; for now, check out part 4a: see 1x size, 2x size

Cloning Zelda, part 3B: Monster-think

2009-01-22T19:57:00.011-05:00

As I mentioned last time, part 3 ended up being too much work to describe all in a single post. Here's part B.

When I worked up the map schema in part 2, I had to decide how to handle the non-static portions of the scenery: walls that can be blown up, trees that can be burned, and statues that can get up and walk around. We'll deal with the walls and trees in a subsequent entry, but the statues , called Armos, were better treated as monsters since they can be woken up (), move around, attack, get killed, and respawn when you come back to the screen later (a burned bush or exploded wall, on the other hand, stays that way for the rest of the game). So I figured it was time to decide how to deal with the game's sprites.

As I mentioned in part 2, the original implementation of the game drew the map and Link on a single canvas, which had to be completely repainted for every game tick. One way around this is to use multiple Canvas elements, layered one on top of the other:

The "background" canvas gets painted first, on the bottom, then the game's sprites are all painted transparently onto the sprite canvas above the background, so it truly only needs to be repainted when it changes. Accomplishing this in HTML code is as simple as defining a CSS selector that applies to all canvas tags, like so:

canvas {
  border: 6px double black;
  position: absolute;
  top: 20px;
  left: 20px;
}

The canvas tags themselves are declared one right after the other, bottom layer first then working upwards (this keeps them in the proper z-order):

<canvas id="map" width="512" height="480"></canvas>
<canvas id="sprites" width="512" height="480"></canvas>

With the canvas layers properly set up, I modified the game code to paint each layer only when appropriate: redrawing the background layer when it changes, and redrawing the sprite layer on every iteration through the main game loop. That loop, then, becomes responsible for painting Link, the monsters, and any items/loot lying around on the ground. I usually try to do things in an object-oriented way if at all possible, so the map, player, and enemy classes each take care of painting themselves. That makes the main game loop's "redraw" section quite succinct:

this.drawSprites = function(){
   ...
    // draw any enemies
    if (this.enemies) {
        for (var i=0; i<this.enemies.length; i++) {
            this.enemies[i].draw(spriteCanvas);
        }
    }

    // draw link
    player.draw(spriteCanvas);
    ...
}

(Incidentally, I am indebted to the sprite gallery at ZeldaDungeon.net for most of my enemy sprites, although I did rip a few from an old NES emulator I had lying in a musty old corner of my hard drive). Aside from a few other bits of code to take care of things like the game header, that's the heart of the game.drawSprites() method, which is one-half of the game's main program loop (we'll talk about the other half in a minute).

As I noted in the last paragraph, the game is now structured to include an array of "enemy" objects at all times. This array gets re-initialized whenever Link enters a new screen, based on the data encoded in the gameData structure for each map screen. Here, for example, is part of the entry for overworld map screen 4,3 (the one shown in the first image in this post):

enemies: [
    {type:'armos',color:0,position:{x:40,y:72}},
    {type:'armos',color:0,position:{x:72,y:72}},
    {type:'armos',color:0,position:{x:104,y:72}},
    {type:'armos',color:0,position:{x:40,y:104}},
    {type:'armos',color:0,position:{x:72,y:104}},
    {type:'armos',color:0,position:{x:104,y:104}},
    {type:'leever',color:1,position:{x:72,y:40}},
    {type:'leever',color:1,position:{x:104,y:40}},
    {type:'leever',color:1,position:{x:152,y:40}},
    {type:'leever',color:1,position:{x:152,y:72}},
]

The gameData definition for monsters consists of three parts: a type, a color, and a starting position. The type indicates the type of monster object to be spawned, and color and position are passed along to its constructor so that it knows how and where to draw itself when asked to do so (many enemy types have a a red/orange and a blue "subspecies", as it were; the color attribute specifies which to draw). The Game class contains a large switch() block that uses the type value to determine which Enemy subclass to instantiate.

Yes, enemy subclasses. When you consider all of the different types of monster in the Zelda overworld (and even in the dungeons), there are shared traits. For instance, some monsters (namely Octorocs, Moblins, and Lynels) can throw things at you (rocks, arrows, and swords, respectively): it makes sense to define an abstract base class, let's call it "Thrower", for enemies that throw things. We can then put the specific code that implements the throwing into the base class, and just override the function that draws the sprites for each respective type of enemy derived from that class. (note: I am using the excellent Javascript library Dojo to handle my classes now; it does all of the heavy lifting for me in terms of polymorphism, class inheritance, etc.)

dojo.declare("Enemy", null, {
    constructor: function(position, color){},
    draw: function(ctx){},
    canMove: function(direction){},
    move: function(direction){},
    think: function(){}
});

dojo.declare("Thrower", Enemy, {
    // (moblins, octorocs, lynels)
    attack: function(){ // todo: launch projectile object }
});

dojo.declare("Octoroc", Thrower, {
    constructor: function(position, color){ // override base class to store correct sprite drawing info, etc }
});

I omitted a lot of the implementation details in the above example; indeed, not everything is even implemented yet! Nevertheless, the basic framework is now in place so that enemies appear in their proper places on each map screen, and all know how to move, more or less: I haven't yet fixed the Diggers subclass for Leevers and Zolas so that they go below the ground/water and pop up in a new position, nor have I implemented the pseudo-"jumping" movement that Tectites use. Both of these enemy subtypes just use the base type's movement algorithm at the moment. Likewise, I also haven't implemented the attack() method on the Thrower subclass; that's part of what I'll be doing in Part 4 of this series. But at the very least, all enemies can take advantage of the think() method, which we call from the main game loop (see? Told you I'd talk about the other half), which I can now show in its entirety:

this.main = function() {
    // update monster positions
    if (this.enemies) {
        for (var i=0; i<this.enemies.length; i++) {
            this.enemies[i].think();
        }
    }

    // draw everything
    this.drawSprites();
}

If you'd like to look at the implementation of the Enemy class and its many subclasses, they're all contained in the enemies.js script file (The updated game.js is here)

So, now we have enemies, and they know (kinda-sorta) how to move around. The game is finally (almost) starting to get interesting to play, now: when my son saw it, it engrossed him for 15 minutes or more as he walked around exploring the whole overworld and all of its ecosystems. Feel free to do the same, here.

Next time, we'll finally get around to giving Link a sword and the ability to swing it. He'll need it, because we're also going to implement hit points and the ability to kill (and be killed)!

Cloning Zelda, part 3A: Coordinated

2009-01-19T10:34:00.013-05:00

Last time I said we'd be fixing the walk code so that Link can't walk through walls/water/etc anymore, and adding in the missing Armos statues to the map. I should've known that was a bit ambitious to tackle both in a single chunk, and indeed it was. So Part 3 will be split into two sections; this is the first.

The first thing I needed to figure out was how to restrict Link's movement on the map. I had a vague idea involving the map data's use of tile coordinates to the overworld tile image I used... I tried to keep all of the "walkable" tiles in that first column, but since I used decimal digits instead of hex digits to address the tiles, I was limited to a 10-tile column, which meant I would be leaving out the dock and stairs tiles if that was my only criteria. Nevertheless, I tried to keep all of the walkable tiles confined to a small space on the image, and figured I'd deal with it in the code.

The code side, in fact, turned out to be fairly straightforward: I added a new routine to the mapScreen class to report on whether a particular (x,y) space on the map screen is walkable. I called it, oddly enough, cellIsWalkable(). It was pretty straightforward... given the x,y coordinates to test, I first had to figure out the 16x16 cell containing those coordinates by dividing x and y each by 16. Once I knew the specific cell containing the target point, I could then check the tile it was using to see if it met "walkable" criteria. Here's the updated map.js file with the new function.

In the process of coding up this whole movement-restriction thing, I realized something else: the original game isn't strictly top-down. In a kind of a stab at a pseudo-isometric interface, Link can kind of "sidle up" to unwalkable cells from below, like so:

As you can see, it lends a bit of a sense of layering to the game, enhancing the illusion of a 3-dimensional playing field. I decided the best way to accomplish this overlap was to relocate the main y-position from the top of Link's head, to his middle. Then all "can I go up?" type requests are made from that center point--not from the top of his head--and the overlap works as it should.

Once I'd relocated Link's y-position, I decided to move his x-position to the sprite's center as well, to better handle movement restriction along the x-axis (I wanted to be able to block Link from walking into walls on both his sides, not just on the left). I then modified the cellIsWalkable() tests along the x-axis to account for an 8-pixel offset on either side, and the work was done (Refer to the image at the top of this entry to see how the axis relocation was done). Or, refer to the modified player.js file for more details of how it all fits together.

I'll get to monsters in the next entry.

Zelda task list

2009-01-13T01:00:00.002-05:00

Working on part 3 of the "Cloning Zelda" project, and since I don't Twitter, I need a place to put this "to do" list:

Part 3: Monsters

Implement class hierarchy for all overworld monsters (done)
Encode monster spawn location info in the game's defining data structure (in progress)
Finish map movement restrictions: no more "boss mode" movement (in progress)

Part 4: Fight!

Implement player hit points
Implement player sword attack
Implement monster:
- artificial intelligence,
- collision detection,
- hit points / damage,
- and projectile attacks

Part 5: Grottos and non-player characters

Implement grotto entrances/exits
Implement "conversation" mode (so old men can give us swords and such)

Part 6: Currency and stores

Implement rupees (and make enemies drop them)
Implement inventory screen / item selection
Implement stores

Part 7: Map interactivity

Implement bush-burning
Implement wall-bombing
Implement hidden grotto entrances (under bushes, behind walls, and the waterfall)
Implement whistle-warping
Implement Lost Woods and Lost Hills special map movements
Implement the Secret Pond (Dungeon 7 entrance)

Once the above stuff is done (IF I ever get it all done!), I'll be at a reasonable transition point: the Overworld will be all but finished, and I'll be ready to decide if I want to tackle the dungeons or not. We'll see how long it takes me to do all of this (and any other things I'm forgetting, too)

Cloning Zelda, part 2: Tile thing

2009-01-09T00:21:00.007-05:00

Last time, I talked about how I had started working on a clone of the Legend of Zelda in a pure-JavaScript aesthetic. When I started researching and brainstorming solutions to the challenge of hit detection, not to mention the game's overall memory footprint, I realized I had a problem. My first stab at the game used a single, huge (4096x1408) PNG image (downloaded from here, forgot to mention that last time) as its map, and I kept track of an offset to the current screen's position on the huge image, which the main program loop would repaint on the canvas every single game tick! Eeek!

Needless to say, upon reflection, that looked like a really bad idea. So I went back to the drawing board, and came up with several design considerations:

Only repaint the background image when it changes (not every game tick!)
Use two canvas layers to separate background from sprites (so player and enemy movement won't trigger a background redraw)
Use a "tile" approach to limit image size in memory

Overworld map tiles*

So, armed with my trusty copy of Paint Shop Pro 7, I started slicing up the map. What I discovered was that the game overworld uses a surprisingly sparse number of tiles to do its job... in fact, these 79 tiles cover all the bases! As I said before, the full map of Hyrule is 4096 pixels wide by 1408 pixels high. We can reproduce the whole thing by using a 2-dimenional array of 256x88 tiles, 16 pixels square. I chose to go one step further, subdividing the map into individual screens, and each screen into its component tiles. This gave me a 3-level map structure:

1 map of 4096x1408 pixels
= a 16x8 matrix of map screens,
each of which = a 16x11 matrix of 16x16 tiles

Now came the long & tedious part: encoding the map as a data structure! I let the above structure inform my design decisions, creating a Map class with: a current property to contain an x/y pair representing the currently visible screen within the map, and a 16x8 two-dimensional array containing MapScreen objects. Each MapScreen object knows its (x,y) position within the larger map, and contains a 16x11 array of cells, each an (x,y) coordinate pair representing that cell's source tile in the global "tiles" image. Map and MapScreen both contain draw() methods that take an HTML Canvas 2d drawing context as a parameter, and which take care of drawing themselves when requested. The code for both Map and MapScreen is here: map.js, and the data file is here: mapData.js

Once the code for the new map was done, there was still the matter of encoding the map data in a way the Map/MapScreen classes could use. I started out hand-coding the map data myself, but this soon proved to be the gateway to madness, and I decided that I needed to build a map editing tool. This would be useful, I reasoned, not only in terms of saving me time now, but also because it would allowing for custom map creation in the future (assuming I live long enough to get this beast fully running!).

At any rate, after a few days of spare-time coding, I came up with this Mapper tool. Two caveats, though: 1, the user interface is pretty terrible, since I built this for myself, not for the average user, and 2, performance is pretty sluggish. The large map on the editor page is drawn in the same way as the map in the game itself, only repeated (16x8) 128 times in rapid succession, once for each individual screen. A good CPU helps a lot, and so does having a good browser: Google Chrome runs it about 10 times faster than Firefox 3.0 (which complains with the "unresponsive script" dialog box on my home PC... but will finish soon thereafter if you click "continue"). That said, the latest nightly build of Firefox 3.1, aka Shiretoko, is quite a bit better... probably owing to its revamped TraceMonkey JavaScript engine). Code for the mapper tool is here: mapper.js

Anyway, after a few days of spare-time work and referring often to the original overworld map image, I've finished encoding the map, and the new version of the game is here. Basically the same functionality as from Part 1, but with a much smaller footprint. I've also started to implement collision detection, which the tiled map makes quite a bit simpler, but considering how long it took me to encode the map tile data, that task kind of took over this step of the process.**

Next time, we're going to finish implementing collision detection, and introduce the missing Armos statues (hint: they're not part of the current map for a reason)!

* Footnote: Some of you may have no doubt noticed that there is quite a bit of duplication in the map tiles I chose to use, as many tile designs are represented three different times in three different colors (brown, green, and gray). Some of you may even point out that I could have accomplished this same thing with a smaller tile palette, if I implemented the idea of multiple palettes at the same time (the downloadable Zelda clone Zelda Classic does it this way, for example). Well, yeah, but I didn't want to even think of the performance hit I would have to take to do image re-coloring in JavaScript/canvas, so intentionally avoided that road. Maybe I'll try it out later on when Canvas has had a chance to mature a bit more in the modern browsers.

** Footnote 2: You may notice some blurring and visual artifacts in this new version of the game map; these appear to be due to the fact that I'm scaling the game up to 2x its original size, so I'm going to have to experiment with resizing it differently, or keeping it in its original 256x240 size. As with the Mapper performance, Chrome seems to handle this much better than Firefox, but a new solution is probably in order.

Cloning Zelda in JavaScript: Part 1 of ?

2008-12-19T02:34:00.004-05:00

Inspired by all of the HTML 5 Canvas-powered JavaScript games that have been popping up, I wanted to see what all the fuss is about. Now I know... it's 2:30 in the morning, I've been working on this for the past 5 hours, and I'm forcing myself to blog my status and go to bed.

Anyway, I've noticed that, despite all of the dozens and dozens of online Super Mario clones (all of which my 6-year-old has on the main tab of his iGoogle page, but that's a story for another day), there aren't any webby Zelda clones! So I decided it was up to me to take up the challenge... as a programming/learning exercise, I've started writing a pure JavaScript (no Flash/Flex/Java/etc) clone of the original NES game "The Legend of Zelda".

So far I've got the overworld map in, and the player character (Link) can move from screen to screen (albeit without being constrained by things like mountains and oceans, because I haven't implemented collision detection yet!) Keyboard support is in, but there's also a set of buttons duplicating the NES controller which you can use as well: The Legend of Canvassa (yeah, I know, stupid name... =P)

Since this uses the <canvas> tag from HTML 5, it currently only runs in Firefox 2+, Webkit and Opera 9; IE users are out of luck. (Yes, I know there are hacks that enable IE to emulate Canvas... but so far I haven't been able to make them work with my code). I've successfully tested it in Firefox 3 and Chrome, so in theory at least it should work in Safari (Chrome and Safari are both Webkit-based, after all). Opera I don't know.

Anyway, this is only Part 1 of what could potentially be a lengthy project, and I suspect I'll continue to scratch this itch over the coming weeks, so look for more updates as they come.

Electronic Film Reviews: Customize your viewing!

2008-09-20T22:44:00.000-05:00

Long time no blog posts in this corner of my domain. I'll try to do better. Tonight I finally got around to watching Speed Racer with my car-obsessed 6-year-old son, since it hit RedBox earlier this week. The story dragged in a few places and a couple of the scenes were a bit too intense for him, plus the script was a bit too free with cuss words I'd rather not have him repeating: enter the EFR project! I've been working on this software for several years (on and off) with good friend, mentor, and professor Alan Melby at BYU Provo. In a nutshell, it gives you the ability to take any off-the-shelf DVD and make your own, totally customized playback experience: you can skip scenes, blank or mute bits you don't want to see and/or hear, flip between different audio tracks and subtitles on the fly, or even play clips out of order if you want! I did all the editing for Speed Racer in the space of about 2-1/2 hours last night after he was in bed, only just slightly stretching the 2-hour runtime of the movie as I edited while pre-screening it with my son's needs in mind. (In retrospect, I should have cut more of the talking-head parts and just left in the mind-blowing race scenes. But I digress...) Anyway, if any of this sounds intriguing and you wanna "kick the tires" and give the software a test drive, hit the URL up above for the download package. A couple of things to bear in mind, however:

the authoring system isn't included in the above link -- if you're interested, email me and I'll send it to you. Eventually there will be a full installer for the authoring suite, but we're not quite there yet.
it doesn't yet support Windows Vista (or non-Windows operating systems for that matter. Sorry, Mac & Linux folks.)
You need to already have a working DVD decoder on the machine you're going to use this on -- the EFR applications simply build on top of them.
This isn't a plug-and-play system like ClearPlay and others of that stripe -- you need to either create an EFR (Electronic Film Review) for a film yourself, or acquire one from someone else and create a playlist from that, customizing it to your tolerances

That last bullet point bears expansion: this software isn't for people who just want to put in a DVD and have a set-top player decide what to show or not show. It requires a bit more forethought and effort, but ultimately I would choose this approach even if I wasn't personally involved in the effort - it gives you the ultimate control and flexibility, because after all, who knows your viewing preferences better than you yourself? ;) Enjoy, and please feel free to leave me feedback if you like it, don't like it, can't make it work, etc. Things like this always get better the more they're used, and the more reports / feature requests we get from people. Happy viewing! Oh, one final note: here is the EFR and associated playlist (CDL) that I made for Speed Racer, just in case anyone wants to use it as the starting point for their own.