window.performance

One of the latest release of Chrome broke the code of my HTML5 porting of Space Invaders.
Suddenly, the game was lacking few animations (background starts, for instance, or aliens moving in the main game screen).

The problem was due to the implementation of the high resolution timer draft: a new sub-millisecond accurate timestamp (a number of milliseconds accurate to a thousandth of a millisecond, since the page was opened). And, of course, to the way I use the timestamp callback input parameter in “requestAnimationFrame”.

A small “polyfill” solved the problem:

Well, not completely, I suppose. The behavior of “window.performance” seems to be related to the OS the browser is running in.

By the way it is available in Chrome stable, Firefox 15+, and IE10.

I also updated the cross browser implementation of “requestAnimationFrame”, using the polyfill described by Paul Irish.

code

references

13th oF fAmE – an entry for the Js13kGames contest

Js13kGames is a JavaScript coding competition for HTML5 game developers.

The main theme of the compo is number 13 (even though not mandatory), file size limit set to 13 kilobytes (when zipped), with a start on 13th August 2012, at 13:00 CEST, and the end at 13:00 CEST, 13th September 2012.

Because of the limited size of submissions, and the possible use of minification and/or “uglyfication” of javascript code, it was indeed interesting the requirement to provide also a well commented, descriptive and readable version of the code on a public GitHub repository, to learn from each other.

Check out rules, entries, prizes, and judges on Js13kGames website.

code

Space Invaders: a HTML5 porting

Space Invaders is one of the most famous arcade games. Released in 1978 by Taito, it made its developer, Toshihiro Nishikado, one of the most successful videogames programmers of all times.

This tutorial aims at being a tribute to this great game using HTML5, javascript and CSS.

It works completely in Chrome, some minor bug in Firefox and Opera with CSS3 animation, different problems in IE8+…

Well, tutorials will come from time to time… I am a little bit busy and lazy now!

Related tutorials:

code

Sequential typing animation using CSSOM, CCS3 and javascript

I was looking for a way to emulate typewriting on multiple paragraphs inside a list, char by char, to solve a problem in my HTML5 implementation of “Space Invaders” (see the tutorial series which deals with its implementation).

The only requirement was use CSS3 (for personal research and fun).

Because of conflicts with my code or browser rendering, I was not satisfied with solutions found online (although really interesting, especially those described by Lea Verou and mayyan14), so I developed my own.

Basically, what we are doing here is strechting the paragraph width through a simple transition, from “0px” to its “offsetWidth”. To emulate the effect of type writing, we split the transition into a discrete number of time steps, equivalent to the number of characters composing the paragraph element. The number will help us also in setting the animation delay on each paragraph.

HTML

HTML is fairly basic: an unordered list of <p> elements, identified by a precise id.

CSS

CSS defines a basic and shared set of properties, which will be applied to the page before any javascript customization.
1. We are using a “Consolas, monospace” font family on <body> to have fixed width for each character.
2. On each <p> we set “display”, “white-space”, and “overflow” properties in order to let the paragraph hide part of its content while animation is running, showing letter by letter.
3. Finally, we set the initial width to “0px” applying the “startTypewrite” class.

Javascript

Now to the interesting part. Basically, we need to add few CSS rules to start the animation. Using the cryptic CSSOM API, we are able to customize them on each paragraph, before we add the rules to the page.

Step 1 adds a “@keyframes” rule to the paragraph, specifyng that the animation should transform its width from “0px” to its “offsetWidth”. For instace, we are declaring the rule “@keyframes text1_typing {from {width: 0} to {width: 110px}}”, associated to first paragraph.

Step 2 sets an “.end” class to stop the animation after each letter, in each paragraph, has been shown. It force the paragraph to retain the width declared by the “to” directive in the previous step.

To obtain a typing animation, we need to show one letter on each animation iteration. Step 1 defines the first (how the animation should starts) and the last (how the animation should stop) states. Consequently we need a way to split the overall animation into a sequence of discrete steps, each of which will add on screen one letter at a time. The css “steps()” function helps in defining the “animation” rule: for instance, we are declaring the rule “animation {text1_typing 2s steps(11, end) 0s}”. This rule asks the browser to apply, for paragraph with id “text1″, the animation named “text1_typing”, run the animation with a 2 seconds duration, split the animation into 11 frames, start the animation after a 0 seconds delay (this delay will be incremented on each paragraph, in order to sequentially show all the paragraphs).

Step 5 defines an event handler to stop the animation and persist the final width on paragraph after the animation has reached its end.

The solution has few drawbacks: it requires monospace fonts, but this was ok with me, because I was working with a retro arcade font; additionally, browser should implement support for CSS3 animations and keyframes.

references

HTML5 game demo contest by Wooga: my entry

Here it is: my entry for the HTML5 game contest held by wooga.

The initiative by Wooga was great, combining a funny competition with a brilliant prize: hack a game, made only of web browsers technologies (HTML5, javascript, CSS, WebGL…), and we will give the winner one ticket to join the European Javascript Conference (JSConf.eu), October 1-2 in Berlin, and up to 1000€ for trip and accomodation!

WOW! Impossible to give up the contest! Unfortunately I heard about it the day before deadline, while I was joining the onGameStart conference in Warsaw. No time to develop the next best seller game, but time enough to have fun and say I was here. 

So, do not expect a “World of Warcraft” like stuff. It is just a small, and maybe not so fun, puzzle game, where you have to memorize shape and colors of a retro looking alien (actually inspired by the old school original Space Invaders) while it is moving. Suddenly the alien will be remixed into an “alien multicolor salad”. You are call to glue together again the right alien’s pieces.

Technically speaking, everything is about classic DOM manipulation, except for the use of requestAnimationFrame, a relatively new API which has been thought to be the right way to implement an animation (or whatever interactive application) in javascript.

Due to rush (and actually a lack of knowledge on how to set the speed of the animation), I implemented it clumsily. I repeatedly make a dummy call to the animation API, incrementing a counter on each call, in order to activate my (re)drawing function only after a certain number of cycles. Something like the following:

Although this first solution seems to be easier, it loses a lot of the benefits you can derive from the use of requestAnimationFrame in a better and “frame aware” way.

Basically, you define the speed you desire, namely how many frames per second, using the time delta (in milliseconds) between “now” and last call you made to your requestAnimationFrame implementation. You thereafter use the resulting number to calculate how and when to update objects, leaving the browser the task to optimize execution by taking web application visibility and display’s refresh rate into account. Like in the following basic template:

See links in the references section below for further investigations.

code

references