Jangaron 0.71: fix for IE9 beta

Another new browser version needs another patch.
This time, it's IE9 beta: alas, it became too standards-compliant! Thus, a typical crude workaround needed for IE6/7/8 did not work anymore. I fixed it, so you can now enjoy Jangaron in Internet Explorer 9 (beta)! It's fast and it's fun!

Evaluation
In IE < 9, you will run into problems when trying to dynamically create an input field by code like this:

  var input = document.createElement("input");
  input.setAttribute("type", "radio");

Old IEs refuse to interpret the type, also if you set it as a JavaScript attribute. Thus, you are forced to use a proprietary, IE-specific API extension that allows to hand in HTML fragments instead of the element name:

// only works in IE < 9:

  var input = document.createElement("<input type='radio'>");

Unfortunately, the usual way to do feature detection instead of browser detection does not apply here, since the function createElement() is defined in any browser, only old IEs provide additional semantics. So I did browser detection (shame on me), which of course failed when IE 9 (note: only in IE 9 mode, not in any backwards-compatibility mode!) became standards-compliant.
The only way out was to use the anti-pattern programming by exceptions and simply try the extended API and catch the error for standards-compliant browsers. To avoid recurring runtime penalty, I only do this once and store the result in a feature flag:

  var SUPPORTS_CREATE_ELEMENT_WITH_ATTRIBUTES = function() {
    try {
      window.document.createElement("<input type='text'>");
      return true;
    } catch (e) {
      return false;
    }
  }();

Instead of SUPPORTS_... I should maybe call that flag REQUIRES_..., since I do not use this feature because it is supported, but because the way the standard suggests does not work in old IEs.

Jangaron mini: Isn't it Cute?

Noticed the new box on the left-hand side? I thought, when blogging about a browser game, why not put the game right into the blog? But in order not to spoil the surprise completely and not to distract you too much from the blog itself, I included a "minified" version of Jangaron that provides instant action without any configuration, allows only one user versus one program, and leaves out most head-up display information (only the speedometer remains).
The tricky part was that I wanted the game to start when the iframe receives focus. In any browser but IE, window.addEventListener("focus", ...) does the job. Even when using the IE equivalent window.attachEvent("onfocus", ...), nothing happens. My next attempt was to use a googled-up solution where they put the event listener on the iframe element, not on its contentWindow. I won't quote the source, since this solution didn't work, either, at least not for my case: Believe it or not, IE does have some security features and won't allow any script to access its window.frameElement if it comes from another domain than its container page, in order to prevent cross-site scripting / phishing.
At last, I found this post by Hemchand Thalanchery about JavaScript and cross-browser window focus, and this was exactly what I had been looking for -- thanks, Hemchand! I think it is perfectly okay that when you build a workaround for a certain browser, you use proprietary functions of that browser. In this case, the IE-proprietary events "onfocusin" and "onfocusout" are the counterparts to "onfocus" and "onblur", respectively, and the listeners have to be attached to the document, not the window.
Too bad that I only encountered the cross-site scripting problem after having already uploaded the change, and too bad my provider didn't let me in until right now... wait a minute... here we go! Now, IE users won't get this annoying "permission denied" anymore like during the last four hours. Sorry for the inconvenience.
Feel free to add Jangaron mini to any of your Web-pages (some more hits for Jangaron, too :-) )! You can copy the code from the source of this page or from here:

<iframe width="360" width="180" src="http://www.jangaron.net/jangaron0.5/jangaron-mini.html">
</iframe>

To make it behave better than on my own page, you can add some markup inside the iframe element that informs the user that she or he has a browser that does not support frames, and add a link to the page (but then I'd suggest the full game page!).
Of course, since Jangaron is a vector game, you can change width and height any way you like!
Enjoy!

From C-64 Till Dawn

I just joined the Tron Sector forum to create some promotion for Jangaron and was about writing a really long post, but then I thought, "hey, why did you just start a Jangaron blog? Spare Tron Sector a couple of bytes to host and blog it!" So I just posted a short introductory text and links to the game and this blog.
When browsing through their light cycle games list, I found several justifications for creating yet another one of these. My justification is that I wanted to start a game software project that feels like back in the 80s: Try to do something amazing with very limited technologies. So I got into my head to implement a 3D light cycle race not only as a browser game, but also (mainly to make it harder) without using any plug-in or proprietary browser features like filters or canvas. It had to be a challenge close to impossible.
Moreover, writing a light cycle game is something I failed to finish back when the Tron movie was new (I was young but didn't need the money). I started to implement the game, but my computer graphics skills were as inadequate as the C-64's, so it got buried in oblivion.
Well, in the meantime, things changed: I have a Ph.D. in computer science now, which makes me a perfect candidate to re-implement a 25 year old game idea in JavaScript.
I have been using and getting to love JavaScript at work for years. It features a unique combination of functional and object oriented programming that leaves the impression of an independent congeniality. To overcome some limitations of the language design and to make things more interesting, already in 2003, on of my colleagues (and co-founder of the company!) anticipated ECMAScript 4 by creating a compiler from a subset of the specification (as it was then) to JavaScript 1.x as it can be executed in browsers. I continued his work and built a second version that moved a bit more complexity to a run-time library for the sake of even better readable and debuggable compiler output. This left me in a situation where I had all the tools to create awesome JavaScript frameworks and applications, so I needed some excuse to use them even in my spare time.
Until half a year ago, I was totally convinced that it is impossible to do any ambitious graphics with (D)HTML. But I am a UI guy, meaning that software without a face is a no-go for me, so I didn't give up. In one of my never-ending CSS-DHTML-JavaScript-google-sessions, I stumbled across CSS border slants (at the latest then I started to be proud of my danish ancestors!), which opened up unbelievable possibilities and kept me from sleeping quite some time. I don't want to deprive you of one quote from the border slants page:

For a dynamic example, see the Rotating Star demo. Also proves that DHTML and JavaScript are not fast enough to do wire-frame games.

Ha!, I thought, I will prove you wrong! Despite the fact that Jangaron is not exactly a wire-frame game, but uses a lot of filled trapezia, I guess what you can see by now does prove them wrong. The trick is that I chose a game that quite coincidently has such a limited perspective and so simple game objects that the restrictions of border slants do not apply.
Furthermore, there are many things you have to bear in mind to end up with efficient DHTML (and which the creator of the Rotating Star demo probably was not aware of). One anecdote is that while I learned a lot from some Opera "efficient JavaScript" page, my game ran unbearably slow only in Opera, until very recently -- I still don't know which code change caused the sudden performance change. In many cases, trial and error is your friend. After all, I was surprised that at least on my hardware, the frame rates do not really vary tremendously between different browsers. One browser can treat transparency more efficiently, another delivers smoother animations (less jerking -- better garbage collection?), but the overall frame rate is almost equal. Even most-hated Internet Explorer is not bad when it comes to JavaScript and DHTML execution speed. And believe me, I did not implement browser-specific performance optimizations (the browser-specific workarounds for bugs to get it to run at all were sufficiently complicated).
What is said to be true for a Web-site seems to be true for a cross-browser game, too: If you do the right thing, it will be best played with any browser!
I hope we can use this blog to discuss more about what the right thing is in JavaScript browser game programming, but now, the daylight-savings-time-bastards have already stolen another hour of my life, Dawn has almost cracked and I have to sleep.
Good night.