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.