<p>transition of two parametric spirals repeated twice with different displacement. Fountain pen with &#39;Aurora Borealis&#39; on white bristol A4. The beginning of the spiral is not yet changing in radius to make a bolder border, this is a subtle but important aspect.</p>
<img src="/images/plots/137zoom1.jpg" width="100%">

<p>The zoom is quite interesting here. let&#39;s also zoom at the center too:</p>
<img src="/images/plots/137zoom2.jpg" width="100%">


transition of two parametric spirals repeated twice with different displacement. Fountain pen with 'Aurora Borealis' on white bristol A4.

Alien planet

<p>Here is &quot;White Protozoa&quot; my third <a href="https://greweb.me/2021/05/plot-loops">&quot;plot loop&quot; (see article)</a>. The main digital art is a 1920p video loop of 8 frames available as a <a href="https://www.hicetnunc.xyz/objkt/82974">Tezos hicetnunc NFT</a>. The physical art is 8 frames of A4 size, plotted with white Sakura gen pen on black card paper (210g), and offered when <a href="https://www.hicetnunc.xyz/objkt/71006">buying the NFT</a> (8 editions, assigned in buy order).</p>
<img width="100%" src="/images/plots/136zoom.jpg" />

<p>like in <a href="/plots/135">plot#135</a>, this is an exploration of domain warping and marching squares algorithms.</p>
<img width="100%" src="/images/plots/136full.jpg" />

<p>The ending of #1 being plotted, speed x5:</p>
<img width="100%" src="/images/plots/136plot.gif" />

<p>If you like bonus, I had considered many different animations, and they are viewable as GIF (digital black on white) on <a href="https://github.com/gre/gre/tree/master/plots/examples/136">https://github.com/gre/gre/tree/master/plots/examples/136</a></p>
<p>You can also find the full source code, open sourced as 99% of my work. I essentially have a generator of plot loops and I ran it to generate 500 gif and chose among them! It was very hard to decide!</p>
<p>Enjoy!</p>


8 frames plotted making an animated loop. A 1920p video and A4 physical art is available as an NFT.

White Protozoa (8 frames)

<p>Domain warping meets marching squares algorithms. Fountain pen on A4 canson.</p>
<p>I have many other candidates. I also tried this one:</p>
<img width="100%" src="/images/plots/135bis.jpg"/>


Domain warping meets marching squares algorithms

topographic warp

<p>A simple experiment with randomly connected curves.</p>


A simple experiment with randomly connected curves.

wool ball

<p>A simple experiment with crosses and sine waves. Fountain Pens with Pink and Turquoise ink on Bristol A4.</p>
<p>also tried with brush pens to try what happens with a 45° slope &amp; unpredactibility:</p>
<img src="/images/plots/133bis.jpg" width="100%"/>


A simple experiment with crosses and sine waves. Fountain Pens with Pink and Turquoise ink on Bristol A4.

Cross sines

<p>A stable parametric spiral transition. Fountain Pen and Turquoise ink on Bristol A4.</p>


A stable parametric spiral transition. Fountain Pen and Turquoise ink on Bristol A4.

Turquoise trispiral

<p>Yet another spiral transitioning between two parametric functions. &#39;Bloody Brexit&#39; ink from Diamine with brush pens on A4 Bristol.</p>
<img width="100%" src="/images/plots/131.gif" />


Yet another spiral transitioning between two parametric functions. 'Bloody Brexit' ink from Diamine with brush pens on A4 Bristol.

hexa flower noise

<p>Exploring a spiral transitioning between two parametric functions to create an hexagonal fold effect. Addition of perlin noise to offset a bit two similar spirals. Fountain pen on A4 Bristol.</p>
<img width="100%" src="/images/plots/130_zoom.jpg"/>


Exploring a spiral transitioning between two parametric functions to create an hexagonal fold effect. Addition of perlin noise to offset a bit two similar spirals. Fountain pen on A4 Bristol.

hexafold planet

<p>Here is &quot;Jumping blob&quot; my second <a href="https://greweb.me/2021/05/plot-loops">&quot;plot loop&quot; (see article)</a>. The main digital art is a 1920p video loop of 8 frames available as a <a href="https://www.hicetnunc.xyz/objkt/71006">Tezos hicetnunc NFT</a>. The physical art is 8 frames of A5 size, the square of the drawing is 12cm by 12cm and they are offered when <a href="https://www.hicetnunc.xyz/objkt/71006">buying the NFT</a> (8 editions, assigned in buy order).</p>
<p>There are 8 frames plotted recreating the &quot;jumping blob&quot; animation (shader implemented in <a href="https://greweb.me/shaderday/67">https://greweb.me/shaderday/67</a>). Each frame is plotted with two fountain pens (Diamine inks: Pink and Turquoise) on Canson Bristal (A5 format), and takes about an hour to plot.</p>
<img width="100%" src="/images/plots/129_all.jpg" />

<p>Each frame revisit a specific technique that I explored in the past months:</p>
<ul>
<li>Frame 1: Voronoi distribution + samples spiral</li>
<li>Frame 2: Voronoi distribution + samples sorted</li>
<li>Frame 3: Voronoi polygons</li>
<li>Frame 4: Voronoi distribtion + TSP</li>
<li>Frame 5: sampling points and starting lines with vector field (low frequency)</li>
<li>Frame 6: sampling points and starting lines with vector field (aligned horizontally)</li>
<li>Frame 7: sampling points and starting lines with vector field (more curvy)</li>
<li>Frame 8: circles plotting</li>
</ul>
<p><img width="50%" src="/images/plots/129_zoom1.jpg" /><img width="50%" src="/images/plots/129_zoom2.jpg" /></p>
<p>The generator was completely reimplemented, including the &quot;scene&quot; itself which is a port of the GLSL code into Rustlang with some adjustments (two different colors are spread on different areas):</p>
<pre><code class="language-rust">fn jumping_blob(f: f64, o: (f64, f64)) -&gt; Vec&lt;f64&gt; {
    let mut p = o;
    let bezier = Bezier::new(0.0, 0.1, 1.0, 0.9);
    let x = bezier.calculate(f as f32) as f64;
    let t = x * 2. * PI;
    let radius = 0.18;
    let smoothing = 0.15;
    let dist = 0.2;
    p.0 -= 0.5;
    p.1 -= 0.5;
    p.1 *= -1.0;
    p = p_r(p, PI / 2.0);
    let q = p;
    p = p_r(p, -t);
    let s = f_op_difference_round(
        f_op_union_round(
            q.0.max(0.1 + q.0),
            length((p.0 + dist, p.1)) - radius,
            smoothing,
        ),
        length((p.0 - dist, p.1)) - radius,
        smoothing,
    );
    let v = smoothstep(-0.6, 0.0, s).powf(2.0)
        * (if s &lt; 0.0 { 1.0 } else { 0.0 });
    vec![
        v * (0.001 + smoothstep(-0.5, 1.5, p.0)),
        v * (0.001 + smoothstep(1.5, -0.5, p.0)),
    ]
}
fn p_r(p: (f64, f64), a: f64) -&gt; (f64, f64) {
    (
        a.cos() * p.0 + a.sin() * p.1,
        a.cos() * p.1 - a.sin() * p.0,
    )
}
fn length(l: (f64, f64)) -&gt; f64 {
    (l.0 * l.0 + l.1 * l.1).sqrt()
}
fn f_op_union_round(a: f64, b: f64, r: f64) -&gt; f64 {
    r.max(a.min(b))
        - length(((r - a).max(0.), (r - b).max(0.)))
}
fn f_op_intersection_round(a: f64, b: f64, r: f64) -&gt; f64 {
    (-r).min(a.max(b))
        + length(((r + a).max(0.), (r + b).max(0.)))
}
fn f_op_difference_round(a: f64, b: f64, r: f64) -&gt; f64 {
    f_op_intersection_round(a, -b, r)
}
</code></pre>
<img width="100%" src="/images/plots/129_zoom3.jpg" />

<p>It&#39;s one of the first time I try to work on the &quot;scene composition&quot; and I&#39;ve also used a pattern filled with &quot;+&quot; for the background. I want to explore more of these in the future.</p>

8 frames plotted making an animated loop of a jumping blob. A 1920p video and 12cm square physical art is available as an NFT.

Jumping blob (8 frames)

<p>Parametric flower plotted with two brush pens. It is challenging to get the correct pen height when working with brush pens. I used two parametric functions with a slight displacement to reveal some moiré patterns created by the divergence.</p>


Parametric flower plotted with two brush pens.

Pentaflower

<p>another parametric plotted with a brush pen and &#39;Bloody Brexit&#39; ink by Diamine.</p>


another parametric plotted with a brush pen and 'Bloody Brexit' ink by Diamine.

Parametric brush

<p>yet another parametric spiral perturbated by perlin noise!</p>


yet another parametric spiral perturbated by perlin noise!

Parametric shield

<p>parametric function and perlin noise. Brush pen with Bloody Brexit ink on A4 bristol.</p>


parametric function and perlin noise. Brush pen with Bloody Brexit ink on A4 bristol.

Parametric spiral on fire

<p>Revisiting my classical &quot;Jumping man&quot; <a href="/plots/060">plots#060</a> with combination of Fibers exploration (<a href="/plots/112">plots#112</a>). It uses an image as a lookup for noise amplitude and reveals the shape of the Jumping man. Fountain pens. A4 on Bristol.</p>


Noisy fibers

<p>Sakura Gelly Roll on dark red A4 card.</p>


Flower parametric stack

<p>stacking multiple parametric functions with 3 stops. playing with moiré effects. STA pigment liner on A4 bristol.</p>
<pre><code class="language-rust">let size = 90.;
let f1 = (8., 8.);
let f2 = (5., 40.);
let amp1 = 1.0;
let amp2 = 0.05;
let samples = 100000;
let spins = 200.0;
let splits = 4.0;

let parametric = |p: f64| {
  let p1 = (splits * p).floor();
  let p2 = splits * p - p1;
  let t = (p1 + 0.8 * p2) / splits;
  let scale = 1.0 - t;
  let mut p = (
    scale
    * amp1
    * ((spins * 2. * PI * t).cos()
      + amp2
      * mix(
        (spins * f1.0 * PI * t).cos(),
        (spins * f2.0 * PI * t).cos(),
        t,
      )),
    scale
    * amp1
    * ((spins * 2. * PI * t).sin()
      + amp2
      * mix(
        (spins * f1.1 * PI * t).sin(),
        (spins * f2.1 * PI * t).sin(),
        t,
      )),
  );
  let noise_angle = 2.
    * PI
    * perlin.get([
      0.02 * p.0,
      0.02 * p.1,
      100.0 + opts.seed,
    ]);
  let noise_amp = 0.1
    * perlin.get([
      0.01 * p.0,
      0.01 * p.1,
      opts.seed,
    ]);
  p.0 += noise_amp * noise_angle.cos();
  p.1 += noise_amp * noise_angle.sin();
  p
};
</code></pre>


stacking multiple parametric functions with 3 stops. playing with moiré effects. STA pigment liner on A4 bristol.

Growing parametric splitted

<p><a href="/2021/05/plot-loops"><strong>✍️ See also: Plot loops</strong> article</a>.</p>
<p>This first plot loop is called &quot;Triplanet&quot;. It&#39;s a transition of two parametric functions with many perlin noise displacements. This is a continuation of <a href="/plots/100">&quot;Planet Holes&quot;</a> series as well as recent <a href="/plots/111">&quot;Parametric stack&quot;</a> explorations.
Every frame is generated with a Rust script I wrote.</p>
<p>16 frames has been plotted with fountain pen on bristol paper (ink: Red Dragon by Diamine). With a back and forth effect, this produces a 30 frames animation loop.</p>
<img width="100%" src="/images/plots/121_walled.jpg"/>

<p><strong>The animation is released as a NFT video</strong> on <a href="https://www.hicetnunc.xyz/">hicetnunc</a>. There are 16 editions, as many as there were frames plotted. The NFT video is an art in itself.</p>
<p>By buying a frame (by order of buy), the first buyer also chose what happens to the physical plot: either I keep it OR you can claim it (contact me on Twitter) and have me sending it anywhere in the world!</p>
<img width="100%" src="/images/plots/121_zoom.jpg"/>

<p><strong>Plotting with fountain pen is challenging</strong> as it requires many search on the ink, paper and many fail and retry. Plotting all these frames took an afternoon.</p>
<img width="100%" src="/images/plots/121_plot.jpg"/>

Triplanet is my first plot loop, physical animation of 16 plotted frames. transition between parametric functions and perlin noise.

Triplanet (16 frames)

<p>This is a pretty simple technique, which is almost like a spiral filling, except it&#39;s a parametric (a simple one that is close to a spiral). The idea to render something monochrome with a parametric is interesting, I would like to dig more in future. I also tried it on typography (for a family gift).</p>
<p>This plot is done with fountain pen and ink &quot;Amber&quot; by Diamine, which I really like.</p>
<p>When you look closer, there are high frequency noise used to make it more fuzzy.</p>
<img width="100%" src="/images/plots/120_zoom.jpg">


a parametric spiral, similar to recent exploration, allows to fill the color of the Bitcoin logo

Bitcoin

<p>This is, like <a href="/plots/114">plot#114</a>, yet another parametric &quot;stack&quot; (using parametric at different scales).
This time, the parametric is very noisy. There is a desired effect to make a blur illusion. It&#39;s very fuzzy. I have some glitches on the signature but it&#39;s part of the art now!</p>


Yet another parametric stack, noisy one this time! white uniball on black A4.

Blurry waves

<p>Continuation of <a href="/plots/113">plot#113</a> with different parametric functions.</p>
<ul>
<li>Sakura Gelly Roll white on black. (clairefontaine 210g)</li>
<li>STA pigment liner 0.05mm on white. (canson bristol A4)</li>
</ul>
<p>The black plot have an interesting precision which makes it smooth from a far look but the details of this plot are interesting as well. I&#39;m not yet sure what creates the vertical line glitch we see on both plots, is it the paper? is it my robot? It is part of the art now.</p>


concentric parametric flowers

<p>Another exploration of <a href="/plots/112">plots#112</a>, more delicate than <a href="/plots/115">plots#115</a>, with a centered noise of fibers. It uses two fountain pen inks for different color tones (Aurora Borealis and Writer&#39;s Blood from Diamine). I could try with even more lines in future but these are already almost 2 hours of plotting time! A4 on Bristol.</p>


Exploration of fibers with a centered noise. two color tones.

<p><strong>Exploration of perlin noise triangle planets. various fountain pen on A4 bristol.</strong></p>
<p>These are taking almost one hour to plot, with 2 passes of 2 different spirals. Each spiral varies a bit with different offset and displacement noise which creates a desired effect of bolder areas, caveats and craters.</p>
<p>The displacement noise is a simple perlin noise, only one harmony is used but the noise is split into two 2 different perlin noises: the angle noise (like a vector field, different angle of displacement) and the amplitude noise (how much does the displacement move the point).</p>
<p>The triangle is made with a parametric function, reusing technique explored on <a href="/plots/114">plot#114</a>.
There is an important effort on finding a good balance between noise and distribution of lines (it&#39;s not linear, it&#39;s closer on edges).</p>


Exploration of perlin noise triangle planets. various fountain pen on A4 bristol.

Triangle planet

<p>This is a continuation of exploration started at <a href="/plots/112">plot#112</a>.
Had a great try of ink &quot;Amber&quot; by Diamine. Fountain pens on A4 bristol card.</p>


Yellow fibers

<p>Another parametric functions. Inspired from <a href="/plots/111">plot#111</a> idea: stacking multiple parametric functions. The parametric used is</p>
<pre><code class="language-rust">let parametric = |t, p| {
  (
    (0.2 + 0.7 * p) * (2. * PI * t).sin()
        + 0.1 * (14. * PI * t).sin(),
    (0.2 + 0.8 * p) * (2. * PI * t).cos()
        + 0.2 * (20. * PI * t).cos(),
  )
};
</code></pre>
<p>Sakura Gelly Roll on black A4, revealing artifacts of the paper.</p>


stacking multiple parametric functions. Sakura Gelly Roll on black A4, revealing artifacts of the paper.

Growing parametric 14-20

<p>Another parametric functions. Inspired from <a href="/plots/111">plot#111</a> idea: stacking multiple parametric functions. The formula is <code>(0.3+0.7p)f(2πt)+0.05f(8πt)</code> where p is the growing factor, t is the parametric value and f is a cos for x and sin for y. Sakura Gelly Roll on black A4, revealing artifacts of the paper.</p>


Growing 8πt

<p>This is a continuation of exploration started at <a href="/plots/109">plot#109</a>.
There is an increase amount of perlin noise and a subtle use of two different ink tones: &quot;Pink Glitz&quot; and &quot;Red Dragoon&quot; by Diamine. Fountain pens on A4 bristol card.</p>


Pink fibers

<p>Parametric functions are classical entities that i&#39;ve explored many times (from first day!)...</p>
<ul>
<li>...in classical forms: <a href="/plots/001">plot#001</a>, <a href="/plots/003">plot#003</a>, <a href="/plots/007">plot#007</a>, <a href="/plots/013">plot#013</a>, <a href="/plots/038">plot#038</a>, <a href="/plots/096">plot#096</a>, <a href="/plots/096">plot#096</a>,...</li>
<li>... in more funky forms: <a href="/plots/071">plot#071</a>, <a href="/plots/073">plot#073</a>, <a href="/plots/080">plot#080</a>, <a href="/plots/082">plot#082</a>, <a href="/plots/084">plot#084</a>, <a href="/plots/087">plot#087</a>, <a href="/plots/095">plot#095</a>, <a href="/plots/090">plot#090</a>, <a href="/plots/097">plot#097</a>,...</li>
</ul>
<p>This is however the first time I think about stacking parametic functions: It might not be very perceptible but it is basically 150 parametric functions projected on different scales. The idea comes a bit from the &quot;Planet holes&quot; idea (<a href="/plots/100">plot#100</a>), circles with different radius.</p>
<p>I might not have taken the best parametric for this plot but it&#39;s still fun. Indeed, the pen digged a bit too much in the paper and I might try again with other parametric functions in future.</p>
<p>The ink used is &quot;Bloody Brexit&quot; by Diamine, like on <a href="/plots/109">plot#109</a>, which produces interesting reflection in combination with a good paper (A4 Canson 250g/mm Bristol) and lamp.</p>
<img src="/images/plots/bloodybrexit.jpg" width="100%" />


stacking multiple parametric functions, fountain pen with 'Bloody Brexit' ink which produces an interesting reflection. A4 bristol.

Growing parametric

<p>This is a continuation of <a href="/plots/107">plot#107</a>, but this time it projects it with polar coordinate, essentially making it a disc.</p>
<p>Still using fountain pen, main ink is &quot;Amber&quot; by Diamine. It has interesting properties.</p>


Gold disc

<p>This is a continuation of exploration started at <a href="/plots/107">plot#107</a>, but this time alternating between horizontal and vertical lines. As before, it uses a tiny bit of perlin noise to diverge a bit the lines. The randomness distribution has been customized to approach more the edges.</p>
<p>I switched to fountain pen for better precision. Only using one ink... But what an ink! <em>&quot;Bloody Brexit&quot; by Diamine.</em></p>
<img src="/images/plots/bloodybrexit.jpg" width="100%" />


Clothes

<img width="100%" src="/images/plots/108.gif" />

<p>It took me 107 previous days of plotting to come up with an elegant idea: searching the best plot among many different variants can easily be done by working instead on a video of that plot! Then you can chose a frame to plot, it is both practical as well as you get a nice animation for free!</p>
<p>Some code snippet for video generation.</p>
<pre><code class="language-bash"># generate all .svg in results, then:
cd results
mkdir pngs
for f in *.svg; do convert $f pngs/${f%.*}.png; done
ffmpeg -r 24 -i pngs/%d.png -pix_fmt yuv420p -vf &quot;pad=ceil(iw/2)*2:ceil(ih/2)*2&quot; out.mp4
</code></pre>


Perlin mountains

<p>Inspiration came from work from <a href="https://twitter.com/mellogood">@mellogood</a> who made these: <a href="https://twitter.com/mellogood/status/1376565566283120645">https://twitter.com/mellogood/status/1376565566283120645</a>.</p>
<p>I&#39;m starting from this idea here and trying to add some Perlin noise displacement on the polar coordinate.</p>


Planet Holes #1

<p>Photo of a jumping man. Implemented with k-means clustering, tsp and parallelization. Plotted with with a brush pen. There is a slight gradient thanks to some slope on the plotting table!</p>


Jumping man


<img width="400" src="/images/2021/05/relics.gif" />

# Releasing **Relics**, my first curated NFT collectible series, on Tezos blockchain and platform [_hicetnunc.xyz_](https://hic.link/greweb).

**Collection:** There are 28 curated visual loops that will be shared on the 7 days of this week. 4 NFT a day. I will use French day names as well as French seasons to name them all.

**Technical:** Relics collection are unique animation made with Perlin noise, cellular automaton and GLSL. The generator is fully open source and available on my website here: https://greweb.me/shaderday/63 as I strongly believe in open sourcing literally everything I do even as an artist. That said, I curated carefully the 28 unique NFTs myself and it's the only official collection of that generator.

> Contact me if you are the buyer to obtain the parameters of your NFT. Unfortunately it's not possible yet to "unlock" content as part of buying a NFT but I would be glad to give you the parameters of your NFT! I can also generate high resolution versions on demand (but also, the open sourced code allows it, once you have these parameters!).

_Lundi d'hiver, Lundi de printemps, Lundi d'été, Lundi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/61391"><img src="https://cloudflare-ipfs.com/ipfs/QmSbZ7iK1S2aDKtTM4HLkzjZrMCwgyDhNbqum8kQTfF44N" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/61403"><img src="https://cloudflare-ipfs.com/ipfs/QmbGrg2mckEbz5u6ShuQi5SbRcUKkEiY9S8irExUiJLizS" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/61410"><img src="https://cloudflare-ipfs.com/ipfs/QmZSQduPnXvmWvFo8JdC3WrxjzU9MbaKGD2JtywtWRq6C8" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/61413"><img src="https://cloudflare-ipfs.com/ipfs/Qmb2qS5Vp7YPfW5KqqgEm4aFqeTaGv2RXb81j1mG9dcLqL" width="25%"/></a>

_Mardi d'hiver, Mardi de printemps, Mardi d'été, Mardi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/63131"><img src="https://cloudflare-ipfs.com/ipfs/QmQHcBZ18wYDMq2B2i7AfQFC1e5CJytgsYxYzuanJ8Zxuy" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/63126"><img src="https://cloudflare-ipfs.com/ipfs/QmZRfP9fNKWRizNzHEiB4yHFPTSAuij53XJzXdeqz2qqNu" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/62848"><img src="https://cloudflare-ipfs.com/ipfs/QmT4xPg39PyVDEYGSi1BRce62jJnt2w8SmCDxEYJaZ47cQ" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/62839"><img src="https://cloudflare-ipfs.com/ipfs/QmXrWE4csSkPXYRg3BqhFmKVCzbXGDtNLRkku6Gc2PCY2Y" width="25%"/></a>

_Mercredi d'hiver, Mercredi de printemps, Mercredi d'été, Mercredi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/64885"><img src="https://cloudflare-ipfs.com/ipfs/QmcwpMrbg3n3iNo1TgQUS5LarKwFwz6kK9wexkc38ybRgT" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/64874"><img src="https://cloudflare-ipfs.com/ipfs/QmeDzVu5G1wLJxEsDXJXtdiJpMWAiRDfJnRgx16VmGH96X" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/64863"><img src="https://cloudflare-ipfs.com/ipfs/QmZuJcvNG2T7sCn959CWEuHZxi1C2Nr5H5JzbV6Sp5Pz3p" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/64852"><img src="https://cloudflare-ipfs.com/ipfs/Qmcomh1sD8L6wewENSWnqLT4akpRwrDpgABy8viu68b9Ua" width="25%"/></a>

_Jeudi d'hiver, Jeudi de printemps, Jeudi d'été, Jeudi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/66703"><img src="https://cloudflare-ipfs.com/ipfs/QmRe8RwPjLhatKbSMV5YGf3TDBKdB8W7xVnM8zQzNqe3dM" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/66686"><img src="https://cloudflare-ipfs.com/ipfs/QmNpPhofb4eJJq7YCDpjba8t3fNFQkY8W9ryM2iSreWkwB" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/66683"><img src="https://cloudflare-ipfs.com/ipfs/QmRN9L8PhKmfb4uM2LsFb2C2Gxa3YHZ7KQFZsSbSAUAMZ6" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/66674"><img src="https://cloudflare-ipfs.com/ipfs/QmXh2RAdgP841oJWdyMtBSQ78XnYQwHzEkTF8qze6hnbCn" width="25%"/></a>

_Vendredi d'hiver, Vendredi de printemps, Vendredi d'été, Vendredi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/68578"><img src="https://cloudflare-ipfs.com/ipfs/QmTXdtycdrp4v6UWymCeDJCamxHqUdHdy99XfK7vmVqqtx" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/68575"><img src="https://cloudflare-ipfs.com/ipfs/QmVyxcykCS8f1vpriReyedAfdP1M9wHq8pwyKtWtoUgXRb" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/68572"><img src="https://cloudflare-ipfs.com/ipfs/QmY1HcgrX7S5wxaYxRoFuxUWEdG6W6gAApDpzc1oYHSUDt" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/68522"><img src="https://cloudflare-ipfs.com/ipfs/QmSc8Q5ozk8nhLvzF6jry613WDhvFX6PjbqnKbyb97smhy" width="25%"/></a>

_Samedi d'hiver, Samedi de printemps, Samedi d'été, Samedi d'automne._

<a href="https://www.hicetnunc.xyz/objkt/69282"><img src="https://cloudflare-ipfs.com/ipfs/QmasrfTskgzSj48gG62xFyWvXrJXWznyPakMB7GtYwgcY3" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/69280"><img src="https://cloudflare-ipfs.com/ipfs/QmdvFEWzkbK2yPNSNURPNNJTkGf55MoDfboXboCvYwVUob" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/69276"><img src="https://cloudflare-ipfs.com/ipfs/QmZhD4pwmRB43CN7hXKouGHMgCdwuFfnBweJfNBeSJeTBt" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/69275"><img src="https://cloudflare-ipfs.com/ipfs/QmdgVW9CnMY1P6o41EEaiwsJMDQdgxhPzo4xmrV8YLLJ66" width="25%"/></a>

_Dimanche d'hiver, Dimanche de printemps, Dimanche d'été, Dimanche d'automne._

<a href="https://www.hicetnunc.xyz/objkt/70994"><img src="https://cloudflare-ipfs.com/ipfs/QmbTE4QGptyHGYsyemttEXSDoydapMuBiT94kooD3zLHc9" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/70991"><img src="https://cloudflare-ipfs.com/ipfs/QmXMUCZmptV4MyXJ8zUMM9ZoAfmWMLCTr5toPH99YLo6LY" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/70973"><img src="https://cloudflare-ipfs.com/ipfs/QmfVNN6bfzhsEK5fx45DwQTQ6hMrbASxgGzQnSgTwJEbJd" width="25%"/></a><a href="https://www.hicetnunc.xyz/objkt/70967"><img src="https://cloudflare-ipfs.com/ipfs/QmU1VEYV7zyyN3LhES4mgAm8qdgjgvDERDRqu7GJnKtVQL" width="25%"/></a>

_published on [hic.link/greweb](https://hic.link/greweb)_


Relics collection are unique animation made with Perlin noise, cellular automaton and GLSL.

Relics NFT collection


I am thrilled to release my first **"plot loop"** and plan to release one every week. Let me explain simply the idea:

- an animation is generated with code, (SVG plottable files)
- Each frame of this animation is plotted physically,
- photographed back into a digital picture,
- and post-processed back into a video that makes it an artistic creation by itself as well as each physical plot being one "edition" of that plot loop series.

> This concept recently came to me with [plot#108](/plots/108) exploration, now it's time to literally plot frames!

**So there are two creations:**

- the animation is itself digital art => it is released as an NFT, with as many editions as there are frames.
- each individual frame is physical art => it can be shipped to first buyer.

### Plots and NFT ?!

**Plot loop animations will be released as [Non Fungible Token (NFT)](https://www.youtube.com/watch?v=Y-i9Jsm95ro)** on [hicetnunc](https://www.hicetnunc.xyz/). It allows anyone with Tezos crypto currency to acquire this video on Tezos blockchain. Digital collectors are collecting one edition of this NFT which adds to their collection: **The NFT video is an art in itself**. On top of this, physical collectors can also claim the shipping of the physical art of the frame corresponding to the collected NFT edition (there is as many editions as there are frames plotted).

**This is a hybrid concept between physical and digital art.** By buying a frame (by order of buy), the first buyer has the possibility to chose what happens to the physical art: either you allow me to keep it OR you can claim it (contact me on Twitter) and have me sending it anywhere in the world!

> I'm writing a bigger article about my recent NFT exploration and my art in general. I've been exploring so many ideas recently. I already sold some plots via NFTs, I am very honored to have found some buyers 😍. They can still be found at [hic.link/greweb](https://hic.link/greweb). I'm currently burning them one after the other to expire the possibility to buy them as I will focus on these new projects.

## First release, the triplanet loop

**hicetnunc NFT: [OBJKT#57902](https://www.hicetnunc.xyz/objkt/57902)**

<a href="/plots/121"><img width="50% " src="/images/plots/121.gif"/></a>

My first plot loop is called "Triplanet". It's a transition of two parametric functions with many perlin noise displacements. This is a continuation of ["Planet Holes"](/plots/100) series as well as recent ["Parametric stack"](/plots/111) explorations.
Every frame is generated with a Rust script I wrote.

**Triplanet was released in [plots#121](/plots/121).** 16 frames have been plotted with fountain pen on bristol paper (ink: Red Dragon by Diamine).

<img width="100%" src="/images/plots/121_walled.jpg"/>
<img width="50%" src="/images/plots/121_zoom.jpg"/><img width="50%" src="/images/plots/121_plot.jpg"/>

**Plotting with fountain pen is challenging** as it requires many search on the ink, paper and many fail and retry. Plotting all these frames took an afternoon.

## What's next?

I plan to release a _plot loop_ every week.

It's taking a lot of time to plot all frames so there are great challenges: first of all is to reduce the number of frames, secondly is to make them worth it, to make them really good: I want every frame to be unique, to include some specific elements, easter eggs, that make it recognizable out of the other frames.

---

# Please also check out other great artists

I believe a lot of this hybrid idea of mixing plot, animation, and NFTs. It was very funny for me to see all coïncidence and convergence of ideas on this topic. It's one of these moments when we have the same ideas at the same time. I'm not the only one exploring this and I want to do a big kudos to these great artists.

### Marion [@atelier_marion](https://twitter.com/atelier_marion/status/1388071908575490048)

who recently released a very similar idea! <del>She has 2 more frames yet to be taken!</del> Not anymore!

<a href="https://www.hicetnunc.xyz/objkt/42546"><img src="https://cloudflare-ipfs.com/ipfs/QmXcAWQTaGHQp4BGy1krER284PoaPCNhKYzDrxp86MaM7b" style="max-width: 300px"></a>

She is also creating impressive drawing work as seen on her website: https://www.marionguy.com/shop

### Maks Surguy [@msurguy](https://twitter.com/msurguy)

who is behind [plotterfiles.com](https://plotterfiles.com/) platform. He also does a lot of great plotting art and thought about similar concept recently! [Checkout this article about his work.](https://medium.com/poptwig/artist-in-focus-maks-surguy-26277c95b197)

### Thomas Lin Pedersen [@thomasp85](https://twitter.com/thomasp85)

who is doing a [stuning work](https://www.hicetnunc.xyz/tz/tz2Pkj2xWJovKKCsABjnr3NbyMVJTMBkpTvb) and very impressive landscapes. Also selling NFT for shipping physical print.

He recently did a very cool NFT in collaboration with **Lionel Radisson** [@MAKIO135](https://twitter.com/MAKIO135):

<a href="https://www.hicetnunc.xyz/objkt/53662"><video style="max-width: 300px" controls autoplay loop src="https://ipfs.io/ipfs/QmaGfhSgWX1UTq6jPX11mfHDxccK5eXGYqi6u71zNLaBhY"/></a>

### ...so many other artists!

Let's chat! You can join us on [hicetnunc's discord](https://discord.gg/jKNy6PynPK) on channel #phygital-objkts which explore very similar idea and where other artists will be active!

I'm also available for collaboration.


Releasing my first 'plot loop', generative animation plotted and published as an NFT.

'Plot loops' concept


[main]: /2021/04/cryptoaliens

> See also [CryptoAliens: Genesis][main] main article.

This article explains how [CryptoAliens: Genesis (ethblock.art)][main] works in technical depth.

<img src="/images/posts/cryptoaliens/032_px.png" width="50%" /><img src="/images/posts/cryptoaliens/036_px.png" width="50%" />

First of all, I would like to point out the [source code is available here on Github](https://github.com/gre/gre/tree/master/blockarts/CryptoAliens).

This whole idea was kicked off on [Twitch](https://twitch.tv/greweb). A recording is [available on Youtube](https://www.youtube.com/watch?v=WUzOlLq0IAo). Apart from the many glitches this 3 hours session had remained to be solved, the main part of this was implemented that night. Indeed I had to work countlessly on polishing the shaders, lighting and post-processing. I also spent a lot of time using the block data in a meaningful way because it's what [EthBlock.art](https://ethblock.art) really is about.

## EthBlock.art revolutionary idea

Before going further into the technical details of CryptoAliens, I would like to point out how revolutionary this EthBlock.art idea is.

The project aims to create a virtuous ecosystem of "deterministic art", code visualization of Ethereum blocks. Everything is data: from the ethereum block of transactions, to the code that visualize it, and to the NFTs minted/traded using Ethereum transactions (that themselves are into Ethereum blocks).

**This is a virtuous ecosystem, similar to [Supply Chain Transformation concepts](https://en.wikipedia.org/wiki/Value_chain): each actor in this ecosystem add value and get retributed for it, as I tried to explain in this schema:**

![](/images/posts/cryptoaliens/ethblockart.png)

`CryptoAliens: Genesis` is one possible BlockStyle that I've designed, as a creative coder. It tries to visualize what happened in the Ethereum Block and will take mods into account to try to be as good as possible to deliver interesting possibilities to BlockArt minters.

## Ok, so how is it implemented technically?

Indeed WebGL.

More precisely, it is implemented with [`gl-react`](https://github.com/gre/gl-react) which is convenient to write and compose [_GLSL Fragment Shaders_](https://www.khronos.org/opengl/wiki/Fragment_Shader).

**here is the big picture of the pipeline:**

![](/images/posts/cryptoaliens/graph.gif)

There are 2 main shaders: Mandelglitch (for skin texturing) and Scene (the main raymarching shader). Each of them take a bunch of parameters. `mod1..4` are values from the creator. The rest are inferred from the Block information, they are split into multiple parameters for convenience.

The parameters `s1..9` are coming directly from `mersenne-twister` library, a [PRNG](https://en.wikipedia.org/wiki/Pseudorandom_number_generator) used to get a wide and deterministic variety of shapes, initialized with the block hash. That said, as pointed in the previous section, the main features of the shape are determined by Ethereum block information itself (number of transactions, timestamp, transfers, gas used,...).

On top of these, some other parameters are controling key elements they come from more block information (heavy, head, bonesK, arms info,...).

The technique implemented on the main Scene shader is [raymarching distance functions](https://www.iquilezles.org/www/articles/raymarchingdf/raymarchingdf.htm). The shapes at stake are mostly segments that are merged with a smooth union. There are many loops involved which made it challenging to optimize.
There may be issues on some mobile phone even tho it works on mine thanks to a "pixelated" version. (downscaling the pixels helped)

Because of an heavy usage of this technique, the main scene was really challenging to optimize, it actually runs something like 5 FPS. My choice was to not animate it directly (you can see on the rendering graph that actually the buffer don't need to refresh, except when a "mod" is changed). However, thanks to intermediary framebuffers we can do 60 FPS animation at the postprocessing level. This is what the final user will get as the mods are static.

### Canvas 2D to draw texts

A Canvas 2D element is used to draw the text that will appear on top of everything.

```js
/// canvas used to draw in postprocessing ///
function FrameText({ blockNumber, dateText, width, height, kg, bones }) {
  const onCanvasRef = (canvas) => {
    if (!canvas) return;
    const ctx = canvas.getContext("2d");
    const w = ctx.canvas.width;
    const h = ctx.canvas.height;
    const pad = Math.round(w * 0.01);
    const padX = Math.round(w * 0.02);
    const fontS = Math.floor(0.19 * w) / 10;
    const fontSize = `${fontS}px`;
    ctx.save();
    ctx.fillStyle = "#000";
    ctx.fillRect(0, 0, w, h);
    ctx.font = "bold " + fontSize + " monospace";
    ctx.textBaseline = "top";
    ctx.fillStyle = "#fff";
    ctx.fillText(`CryptoAliens specimen #${blockNumber}`, padX, pad);
    ctx.textBaseline = "bottom";
    ctx.textAlign = "right";
    ctx.font = fontSize + " monospace";
    ctx.fillText(
      `born ${dateText}, ${kg} kg, ${bones} bones`,
      w - padX,
      h - pad
    );
    ctx.restore();
  };
  return (
    <canvas
      ref={onCanvasRef}
      width={String(width * 2)}
      height={String(height * 2)}
    />
  );
}
const FrameTextCached = React.memo(FrameText);
```

### How is Mandelglitch used?

As said, [Mandelglitch BlockStyle](https://ethblock.art/create/17) is re-used in this CryptoAliens BlockStyle. This really is the power of gl-react: it makes such composability really easy to do, the same way you can compose React components.

You can see in the [Youtube recording](https://www.youtube.com/watch?v=WUzOlLq0IAo) the way I have implemented it initially: it is just a simple import of Mandelglitch.js (literally the BlockStyle as-is) that I can just send as a uniform sampler2D.

```
<Node
  shader={sceneShaders.scene}
  uniforms={{
    t: <Mandelglitch block={block} mod1={mod1} mod2={mod2} mod3={mod3} />,
  ...
```

after that, it was simpler to embed Mandelglitch in the BlockStyle.

The way Mandelglitch texturing is used however is that I will only use the "red" component and remap it to CryptoAliens' own palette, in order to have a better control of the coloring.

### Code organisation

React and Gl-React allows to organize the code relatively easily. First of all each pass in the rendering scene is a component, then shaders are organized in the `Shaders.create` usage. I've tried to collocate them (still in same one big file to simplify the upload to EthBlock.art).

I find it pretty convenient to externalize piece of the logic into "hooks" function. Example:

```js
const CustomStyle = (props) => {
  // prettier-ignore
  const { block, attributesRef, mod1, mod2, mod3, mod4, highQuality, width, height } = props;
  // prettier-ignore
  const { kg, bones, theme, background, s1, s2, s3, s4, s5, s6, s7, s8, heavy, head, bonesK, armsLen, armsSpread, armsCenter, armsEndW, dateText, blockNumber } =
    useBlockDerivedData(block, mod1, mod2, mod3, mod4);

  useAttributesSync(attributesRef, kg, bones, theme);

  return (
    <LiveTV
      text={
        <FrameTextCached ... />
      }
      ...
    >
      <NearestCopy width={w} height={h}>
        <Scene
          t={<MandelglitchCached ... />}
          ...
        />
      </NearestCopy>
    </LiveTV>
  );
};
```

`useBlockDerivedData` internally uses `useMemo` in order to cache the computation of block data interpretation.

In order to make **only** one part of the tree to actively re-render, i've used a local `useTime` that would re-render only that part (the LiveTV final shader). It's implementation is trivial:

```js
function useTime() {
  const [time, setTime] = useState(0);
  useEffect(() => {
    let startT;
    let h;
    function loop(t) {
      h = requestAnimationFrame(loop);
      if (!startT) startT = t;
      setTime((t - startT) / 1000);
    }
    h = requestAnimationFrame(loop);
    return () => cancelAnimationFrame(h);
  }, []);
  return time;
}
```

## Arms joints rotation, GLSL random and determinism

Ok, this is a hard topic. But it's extremely important that every BlockArt reliably produce the same result with the same block data, regardless of the computer used.

That last "regardless of computer used" part has challenged me at the last minute! JavaScript doesn't have this problem because it's stable between implementations (computers, engines). However, **this is not the case with OpenGL / GLSL**: every computer, every hardware (GPU) or possibly the "backend" implementation for WebGL ([ANGLE](https://github.com/google/angle) have different backends) can differ when it comes to float precision and primitive results.

In my shader, I was using the classical `random` function that is documented at https://thebookofshaders.com/10/

```cpp
float random (vec2 st) {
  return fract(sin(dot(st.xy, vec2(12.9898,78.233))) * 43758.5453123);
}
```

It works very well when you need a nice 2D distributed noise for basic effects **but it is very bad if you strongly rely on a stable & consistent noise to generate different shapes**.

Empirically, I can observe that `sin()` yields different results on different computers.

This was impacting me badly because I was able to see very various shapes:

<img src="/images/posts/cryptoaliens/rand1.png" width="33%"/><img src="/images/posts/cryptoaliens/rand2.png" width="33%"/><img src="/images/posts/cryptoaliens/rand3.png" width="33%"/>

What I need to varies a bit here is just the angle at each joint of the arms. This is very important for the uniqueness of the creature. The problem is that if each value changes a tiny bit, the whole thing diverge VERY QUICKLY, as the rotation angle will accumulate.

Worse than that, I had a bad pattern to accumulate randomness like this:

```cpp
float ss1 = s1;
for (int i = 0; i < armsLen; i++) {
  ss1 = random(ss1);
  ...
}
```

Actually I don't need that, first of all it's probably not good for performance, secondly I can just afford taking the fractional part of a simple polynomial:

```cpp
float arm (inout vec3 p, float index, float w, float h) {
  float s = sdSegment(p, h, w);
  float base1 = 305.53 * s1 + 77.21 * index;
  float base2 = 403.53 * s2 + 69.71 * index;
  for (int i = 0; i < armsLen; i++) {
    float fi = float(i);
    float ss1 = fract(base1 + 9.412 * fi);
    float ss2 = fract(base2 + 8.823 * fi);
    pR(p.xy, 8. * s4 * (ss2-.5));
    pR(p.xz, 6. * s5 * (ss1-.5));
    s = fOpUnionSoft(bonesK, s, sdSegment(p, h, w));
    h *= .9;
    w *= .9;
    p.y -= 1.2 * h;
  }
  s = fOpUnionSoft(bonesK + 0.2 * s5, s, length(p) - armsEndW);
  return s;
}
```

Note that here it's very arbitrary numbers, the point is to obtain variety and unpredictability in the results. `fract` is a very simple operation (take the fractional part of the number). Indeed i'm still prone to approximation, but the risk is limited by the fact i don't go too high in values here. Worse case scenario is it varies a bit the rotation but it should be so tiny that it won't be visible.

As said before and as seen in this code, the number will be used to do rotations (that `pR` is transforming `p` with some rotations). I use `s4` and `s5` values to give the magnitude of rotations.

**Let's look at a few cases:**

If both s4 and s5 are very near 0.0, it will be straight arms (it's a rare case therefore).

<img src="/images/posts/cryptoaliens/042_px.png" width="50%"/><img src="/images/posts/cryptoaliens/033_px.png" width="50%"/>

If one of the s4 or s5 are 0.0, it will be only happening on one "plan", or slightly diverging spirals, which I assume also to be rare cases:

<img src="/images/posts/cryptoaliens/017_px.png" width="50%"/><img src="/images/posts/cryptoaliens/020_px.png" width="50%"/>

Otherwise, most of the times, it will be relatively random:

<img src="/images/posts/cryptoaliens/029_px.png" width="50%"/><img src="/images/posts/cryptoaliens/032_px.png" width="50%"/>
<img src="/images/posts/cryptoaliens/028_px.png" width="50%"/><img src="/images/posts/cryptoaliens/026_px.png" width="50%"/>

## going 128px. Last minute decision, hard tradeoff

Due to concerns on the "deterministic rendering" from Ethblock.art folks, I had to make a choice regarding the fact it was too slow on mobile... I've decided to switch to 128x128 rendering for ALL platforms so it's consistent.

All the images on that article were done on 1024x1024 which is slow on computer and not even working on my mobile phone. (OnePlus)

It's hard to have efficient raymarching today when you have many items.

**Ultimately, I like how it finally looks, there were some minimalism / cell shaded styles,.. now it embraces Pixel Art even more!**

<img src="/images/posts/cryptoaliens/r02.png" width="50%" /><img src="/images/posts/cryptoaliens/r01.png" width="50%" />

It's also always possible to make higher quality version of these rendering and I'm excited to experiment more of these in future.

---

My name is Gaëtan Renaudeau, and I'm a noise explorer. **feel free to ping me on Twitter [@greweb](https://twitter.com/greweb)**


Technical aspects of CryptoAliens digital creatures generated with Ethereum blockchain blocks. They can be minted on ethblock.at by anyone, which establishes a limited set of CryptoAliens species.

CryptoAliens: Genesis, a technical look


[create]: https://ethblock.art/create/24
[opensea]: https://opensea.io
[tech]: /2021/04/cryptoaliens-tech

> See also [CryptoAliens: Genesis, a technical look][tech].

<img src="/images/posts/cryptoaliens/021_px.png" width="50%" /><img src="/images/posts/cryptoaliens/001_px.png" width="50%" />

> CryptoAliens: Genesis establishes the first embryonic species. Which CryptoAliens are you going to chose? Each creature gets born on an Ethereum block that nourishes its shape: transactions, ETH value transferred, gas,... their unique skin comes from Mandelglitch's BlockStyle with the same rarity scheme.

## What are CryptoAliens?

CryptoAliens are digital creatures generated from Ethereum blockchain blocks. They can be minted on [ethblock.art][create] by anyone, to establishes a limited set of CryptoAliens species in a decentralized matter. Each block produced on Ethereum have unique elements that can be visualized in creative ways.

<img src="/images/posts/cryptoaliens/014_px.png" width="50%" /><img src="/images/posts/cryptoaliens/017_px.png" width="50%" />

> **CryptoAliens are born and nourished from transactions, transactions are bones, ETH is flesh,... and many other aspects that this article will explain!**

<img src="/images/posts/cryptoaliens/032_px.png" width="50%" /><img src="/images/posts/cryptoaliens/013_px.png" width="50%" />

### So I decide which ones are the CryptoAliens?

**Yes! As a NFT minter, you are the creator and you contribute at establishing the first 'Genesis' series of CryptoAliens.** You decide which creature deserve to live. You are the curator and it is your responsible to do a lot of research and find the most adorable (or the creepiest?) creature!

<img src="/images/posts/cryptoaliens/036_px.png" width="50%" /><img src="/images/posts/cryptoaliens/004_px.png" width="50%" />

### How many CryptoAliens are there?

Every single CryptoAliens species is unique and there are currently 12 millions because that's as many blocks there are today (April 2021). Every 15 seconds, a new block is minted on Ethereum blockchain (with usually hundreds of transactions in it) making a new CryptoAliens possibility.
The block is the DNA, but the creature only starts existing when minted!

**TLDR. CryptoAliens only comes to life when someone mint it as an NFT on the [ethblock.art][create] contract.** They can then be sold and traded on [opensea.io][opensea]. There is **a limited amount of CryptoAliens possible to mint** so be wise at your choice. In this 'Genesis' series, the current supply is set to 100!

<img src="/images/posts/cryptoaliens/002_px.png" width="50%" /><img src="/images/posts/cryptoaliens/003_px.png" width="50%" />

### What is 'Genesis' series about?

The idea of 'Genesis' is that we are collectively going to create the initial species of this universe (with the NFT we chose to mint).

Minting a _CryptoAliens: Genesis_ specimen is giving birth to the creature, therefore the current NFT is visualized on [ethblock.art][create] as a video tape recording of that time of birth (with the block number, time, weight and number of bones). These data are included in the NFT itself and could be reused in future!

## What determines how a CryptoAliens specimen looks like?

There are many information contains in Ethereum blocks that will get used to determine the general shape and gives its rarity.

### Block's timestamp

<img src="/images/posts/cryptoaliens/040_px.png" width="50%" /><img src="/images/posts/cryptoaliens/041_px.png" width="50%" />

When the block happened during UTC night, the visual will be in dark mode.

### Block's transactions amount

<img src="/images/posts/cryptoaliens/007_px.png" width="50%" /><img src="/images/posts/cryptoaliens/008_px.png" width="50%" />

When a block contains a lot of transactions it will impact its general weight. It will be highlighted by this very heavy blobs shapes. That said, the weight can be more or less dense based on amount of bones and also unique for each CryptoAliens specimen.

### Block's heavy transfers in ETH

<img src="/images/posts/cryptoaliens/035_px.png" width="50%" /><img src="/images/posts/cryptoaliens/020_px.png" width="50%" />

As said in the introduction, "ETH is flesh". Even tho most of the time it will impact the general weight of the creature, when a block contains an expectionally high transfer of Ethereum value, it will be highlighted by a big "head" on the creature. ("head" in doublequote because none of our scientist really figured what is this)

### Block's exceptionally low amount of ETH transferred

<img src="/images/posts/cryptoaliens/005_px.png" width="50%" /><img src="/images/posts/cryptoaliens/006_px.png" width="50%" />

On the contrary, when a block contains almost no ETH transfers, the arms will be very thin. Clearly ETH traders didn't nourish enough this poor creature.

### Block's important ratio of gas used (vs ETH value transfer)

<img src="/images/posts/cryptoaliens/023_px.png" width="50%" /><img src="/images/posts/cryptoaliens/016_px.png" width="50%" />

It often appears in combination with the previous criteria, if the ratio `total gas / total eth transfers` is high, meaning that a lot of the ETH is into gas, there will be some blobs at the end of the arms.

### ...and more block rare features

There are a lot of special cases are rare conditions that can happen. I will not disclose and I will let you discover. Some are really rare and some will be discovered in the future (even the author of blockstyle won't be aware of all cases!).

### Block's hash

Finally, the block hash gives variety in the results. It's necessary in order to have truly unique 12 millions species. But it's only complementary to the various other criteria. There are many features that are getting impacted by it, including the skin texturing (see _Mandelglitch BlockStyle_ section).

<img src="/images/posts/cryptoaliens/043_px.png" width="50%" /><img src="/images/posts/cryptoaliens/042_px.png" width="50%" />
<img src="/images/posts/cryptoaliens/012_px.png" width="50%" /><img src="/images/posts/cryptoaliens/038_px.png" width="50%" />

### What controls does the creator have?

At creation time, the minter also have the ability to move a bit the specimen:

- `mod1` is a simple rotation around it.
- `mod2` is a simple climbing and zooming.
- `mod3` will flex a bit the shape to make it torn & twist a bit.
- `mod4` have an impact on the color palette scaling.

**On top of this, mods have the ability to transform the skin texturing** which is actually based on [Mandelglitch BlockStyle](https://ethblock.art/create/17)! That means the rarity elements of Mandelglitch are shared in this new BlockStyle.

### mmh, Mandelglitch BlockStyle?

<a href="https://ethblock.art/create/17"><img src="/images/posts/cryptoaliens/mandelglitch.png" width="10%" /></a> **[Mandelglitch](https://ethblock.art/create/17) is a BlockStyle on [ethblock.art](https://ethblock.art/create/17), derived from Mandelbrot fractal.**

The visibility of Mandelglitch on the skin has been intentionally contained, but sometimes it is more visible. Here are two examples:

<img src="/images/posts/cryptoaliens/031_px.png" width="50%" /><img src="/images/posts/cryptoaliens/022_px.png" width="50%" />

## ...and, What's next?

Who knows what's next! As everything is available on the blockchain, what you mint is saved immutably and forever. Me or other artists could fork the code ([available on Github](https://github.com/gre/gre/tree/master/blockarts/CryptoAliens)) to make animated version of the CryptoAliens that were chosen (as this code is open source). Also we can imagine doing crossover between species or doing "evolution" of these species over time. Everything is possible!

---

See also [CryptoAliens: Genesis, a technical look][tech].

My name is Gaëtan Renaudeau, and I'm a noise explorer. **feel free to ping me on Twitter [@greweb](https://twitter.com/greweb)**


CryptoAliens are digital creatures generated from Ethereum blockchain blocks. They can be minted on ethblock.at by anyone, which establishes a limited set of CryptoAliens species. Each block produced on Ethereum have unique elements that can be visualized in creative ways.

CryptoAliens: Genesis [ethblock.art]

[cookbook]: https://gl-react-cookbook.surge.sh
[github]: https://github.com/gre/gl-react
[jest]: https://github.com/facebook/jest
[headless-gl]: https://github.com/stackgl/headless-gl
[bus]: https://gl-react-cookbook.surge.sh/api#bus

# Happy to release **[https://gl-react-cookbook.surge.sh][cookbook]** containing 43 unique examples and API documentation!

[![](/images/2016/12/gl-react-v3.gif)][cookbook]

> If you don't want to be "spoiled" by this article, go through [the cookbook examples][cookbook]. This article will explore some of them.



## gl-react has been rewritten from scratch

**gl-react v3 is a complete rewrite of the v2 implementation for better performance and compatibility with React paradigm.**

This is not yet published on NPM as it's [still in development][github] (the Web version is pretty ready, React Native version is not implemented).

Most features provided by gl-react v2 are preserved (API haven't changed, [see how similar is the HelloGL example](https://gl-react-cookbook.surge.sh/hellogl)), but v3 fixes most Github issues accumulated for a year.

### The biggest mistake of the previous implementation

If there is one lesson learned from previous gl-react implementation: **"unfolding" / consuming the `children` prop by yourself is (probably) wrong, let React solve this job!** Using React, you can benefit [React reconciliation and diff algorithm](https://facebook.github.io/react/docs/reconciliation.html).
In other words, always prefer to keep users' VDOM tree rather than consuming it with `React.Children.*` functions.

I feel dumb not having discovered this before, but if you are not actually rendering DOM it's an easy path for a library to just map, traverse, consume the children tree and just render what you needs (like just a `<canvas/>`). But this is probably a mistake! First, this makes it impossible to use React Devtools and see the original tree, but more importantly, it breaks interoperability with other libraries (e.g. don't forbid someone to use [react-motion](https://github.com/chenglou/react-motion) or [React Router](https://github.com/ReactTraining/react-router) in the middle of your components!).

A better idea is to preserve the user `children`. Keep your logic in each Component and use the React lifecycle to create and destroy things, and **use [React context](https://facebook.github.io/react/docs/context.html) to connect children to parent**.

> You should better keep user `children`, even if it means rendering it in an empty `<span>`, _current workaround of `gl-react`, looking forward to hearing from you, idea inspired from the great [react-music](https://github.com/FormidableLabs/react-music)_

### What it means for gl-react

The gl-react v3 implementation truly uses React lifecycle: **a React Component update triggers a GL redraw**. That way, `shouldComponentUpdate` allows to do partial GL re-rendering. Each Node holds a [framebuffer object](https://www.opengl.org/wiki/Framebuffer_Object) (created on mount, destroyed on unmount) that only get redrawn when component updates and schedules a Surface reflow.

`<Node>` receives the `gl: WebGLRenderingContext` from the ancestor `<Surface>` thanks to [React context](https://facebook.github.io/react/docs/context.html). There is also a `glParent` context (a Surface or another Node) that is used to make GL components discoverable each other so we can build a dependency graph. This dependency graph allows to implement the correct `draw` pipeline (and it's pretty trivial, see [_Section "under the hood of Surface and Node redraw"_](#under_the_hook_redraw)).

## `<Bus>`, a better way to share computation

[gl-react used to automatically factorize the duplicates elements of the GL tree](http://greweb.me/2016/06/glreactconf/) but **it has been decided to remove this feature**: _This was actually a complex mechanism (a bit too "magic"), hard to implement and a premature optimization that can have slower performance._

The new gl-react embraces the React paradigm: The new way to express a Graph (and share computation) is **using a [`<Bus>`][bus]**...

### The `` `()=>ref` `` pattern

The problem we want to solve is to **express a graph with React**, which, at first glance, only allow to represent trees, not graphs!

The way we can solve this is by using refs and a "ref getter function":

1. **a Bus with a ref:** `<Bus ref="myBus">{content to inject}</Bus>`.
2. **pass a function that resolves the ref** to pipe Bus into another Node. e.g: `()=>this.refs.myBus`.

[blurmapdyn example ![](/images/2016/12/blurmapdyn.gif)](https://gl-react-cookbook.surge.sh/blurmapdyn)
a single ConicalGradient should be used for all blur pass:
![](/images/2016/12/blurmapdynschema.png)

There are a few other good examples of ref usages:

- [blurmapmouse](https://gl-react-cookbook.surge.sh/blurmapmouse)
- [blurimgtitle](https://gl-react-cookbook.surge.sh/blurimgtitle) (same example that was features in 2016 React conf!)
- [behindasteroids](https://gl-react-cookbook.surge.sh/behindasteroids), crazy port of a game I made for js13k.

> The `()=>ref` pattern works only if you call the function after component did update (refs are set at this time).

## The good ol' children function

There is another pattern for more specific needs: instead of composing by giving an element, you can also compose by giving a **Function that returns an element**. Why that? Because, it's a way to nicely give you the redraw function: `redraw => <Video onFrame={redraw} />`:

[Checkout video example ![](/images/2016/12/videoredraw.png)](https://gl-react-cookbook.surge.sh/video?menu=true)

> We really just want to redraw if there is a new video frame.

We have merged the 2 patterns into one: if you provide a function, it's just called with `redraw`, and the returned value is used as a texture. We have a few cases to detect what kind of texture it is (and also an [extensible mechanism](https://gl-react-cookbook.surge.sh/api#textureloaders) used by implementations to load platform specific objects).
[(checkout this if you want to see the code)](https://github.com/gre/gl-react/blob/a33e6aa685479d588646b20dd62e1e25a64a5a47/packages/gl-react/src/Node.js#L704-L783)

## Node backbuffering & Backbuffer symbol

A new feature allows to inject the previous Node state as a texture. This is called backbuffering. One simple usecase is to implement Motion Blur persistence (like the GIF on top of this article).

We can also accumulate a state, for instance, to implement Game of Life!

[Game of life glider example ![](/images/2016/12/gol.gif)](https://gl-react-cookbook.surge.sh/golglider)

And the whole idea of gl-react (and React) is about composition. For instance, doing a rotating effect of that Game of Life is basically just `<Rotate> <GameOfLife /> </Rotate>`.

An interesting part is that you can update the GameOfLife at a rate that is independent from the **Rotate** rendering: just by making GameOfLife a pure component that receives a tick, or implementing shouldComponentUpdate update (you have as many choices as React have to [shortcut the rendering](https://facebook.github.io/react/docs/react-api.html#react.purecomponent)).

[golrotscu example![](/images/2016/12/golrot.gif)](https://gl-react-cookbook.surge.sh/golrotscu)

> See the counters that indicate the number of redraw. (the capture preview in the Box only get snapshot each 100ms, but in the real canvas, it runs at 60 FPS)

Finally, please checkout [ibex example](https://gl-react-cookbook.surge.sh/ibex) (extracted from another JS13K game! xD).

> You can't leave this article before seeing [ibex example](https://gl-react-cookbook.surge.sh/ibex)! I'm serious, this is probably the most accomplished code I ever wrote! xD

## <a name="under_the_hook_redraw"></a> under the hood of Surface and Node redraw

In order to make redraw efficient, `gl-react` have 2 phases: the `redraw()` phase and the `flush()` phase (reflecting the respective methods available both on `Surface` and `Node`). This is a bit like a rendering engine:

- **`redraw()` phase** sets a dirty flag to a Node and all its "dependents" (other nodes, buses, surface). _redraws happen generally bottom-up to the Surface._
- **`flush()` phase** draws all nodes that have the redraw flag. _draws happens top-down from the Surface._

`redraw()` is directly hooked to React update lifecycle (re-rendering a Node will calls `redraw()` for you).
To make this system efficient, **the flush() is by default asynchronous**, i.e. `redraw()` means scheduling a new gl draw.
Surface have a main loop that runs at 60 fps and call `flush()`. This is very efficient because if Surface does not have the redraw flag, `flush()` does nothing.

> In gl-react inspector, clicking on the redraw count will call `redraw()` on the node / bus. We can illustrate that only "dependents" get redrawn using the advanced [blurimgtitle example](https://gl-react-cookbook.surge.sh/blurimgtitle):

[only "dependents" get redrawn ![](/images/2016/12/blurimgtitle-redraw.gif)](https://gl-react-cookbook.surge.sh/blurimgtitle)

This redraw/flush phases allow to prevent and skip rendering multiple times a Node. In some cases, we still want to redraw synchronously: with `<Node/>` `sync` prop. For instance, in Game of Life, we don't want to skip an update (the initial update set the initial GoL state, if it was async it might get skipped).

## Bonus

### Flow types

Flow types has been used for more robust code and better user experience. BTW, [WebGLRenderingContext will soon be released in flow](https://github.com/facebook/flow/pull/2764).

### Atom highlighting

If you are using Atom Editor, you can have JS inlined GLSL syntax highlighted.

![](https://cloud.githubusercontent.com/assets/211411/20623048/0527cce2-b306-11e6-85ee-5020be994c10.png)

_To configure this:_

- add `language-babel` package.
- Configure `language-babel` to add `GLSL:source.glsl` in settings "_JavaScript Tagged Template Literal Grammar Extensions_".
- (Bonus) Add this CSS to your _Atom > Stylesheet_:

```css
/* language-babel blocks */
atom-text-editor::shadow .line .ttl-grammar {
  /* NB: designed for dark theme. can be customized */
  background-color: rgba(0, 0, 0, 0.3);
}
atom-text-editor::shadow .line .ttl-grammar:first-child:last-child {
  display: block; /* force background to take full width only if ttl-grammar is alone in the line. */
}
```

### Tests: almost 100% coverage!

The library is tested directly on the command line, thanks to [Jest][jest] and [headless-gl][headless-gl] _(Big up to [mikolalysenko](https://github.com/mikolalysenko) for [headless-gl][headless-gl]!)_.
**gl-react have 2000 line of tests, involving a lot of gl calls, and readPixels, and it runs... in a few seconds!** _(to Jest devs: you are wizards!)_

```

 PASS  ./all.test.js
  ✓ renders a red shader (75ms)
  ✓ renders HelloGL (15ms)
  ✓ ndarray texture (27ms)
  ✓ renders a color uniform (18ms)
  ✓ composes color uniform with LinearCopy (21ms)
  ✓ no needs to flush if use of sync (24ms)
  ✓ Node can have a different size and be scaled up (18ms)
  ✓ Surface can be resized (32ms)
  ✓ bus uniform code style (17ms)
  ✓ bus example 1 (17ms)
  ✓ bus example 2 (18ms)
  ✓ bus example 3 (17ms)
  ✓ bus example 4 (22ms)
  ✓ bus example 5 (14ms)
  ✓ bus example 6 (24ms)
  ✓ bus: same texture used in multiple sampler2D is fine (14ms)
  ✓ a surface can be captured and resized (16ms)
  ✓ a node can be captured and resized (17ms)
  ✓ Uniform children redraw=>el function (22ms)
  ✓ Bus redraw=>el function (16ms)
  ✓ many Surface updates don't result of many redraws (18ms)
  ✓ many Surface flush() don't result of extra redraws (10ms)
  ✓ GL Components that implement shouldComponentUpdate shortcut Surface redraws (27ms)
  ✓ nested GL Component update will re-draw the Surface (24ms)
  ✓ Node `clear` and discard; (24ms)
  ✓ Node `backbuffering` (32ms)
  ✓ Node `backbuffering` in `sync` (36ms)
  ✓ texture can be null (12ms)
  ✓ array of textures (22ms)
  ✓ Node uniformsOptions texture interpolation (17ms)
  ✓ can be extended with addTextureLoaderClass (70ms)
  ✓ Surface `preload` prevent to draw anything (59ms)
  ✓ Surface `preload` that fails will trigger onLoadError (59ms)
  ✓ renders a shader inline in the Node (15ms)
  ✓ testing connectSize() feature (17ms)
  ✓ handle context lost nicely (43ms)
  ✓ Bus#uniform and Bus#index (25ms)
  ✓ VisitorLogger + bunch of funky extreme tests (140ms)

-------------------------------|----------|----------|----------|----------|----------------|
File                           |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
-------------------------------|----------|----------|----------|----------|----------------|
All files                      |    97.85 |     88.8 |    95.96 |    99.35 |                |
 src                           |    97.82 |    88.95 |     95.9 |    99.35 |                |
  Backbuffer.js                |      100 |      100 |      100 |      100 |                |
  Bus.js                       |    96.15 |    74.29 |      100 |      100 |                |
  GLSL.js                      |      100 |       50 |      100 |      100 |                |
  LinearCopy.js                |      100 |      100 |      100 |      100 |                |
  NearestCopy.js               |      100 |      100 |      100 |      100 |                |
  Node.js                      |    97.65 |    92.71 |    97.01 |    99.01 |    214,216,358 |
  Shaders.js                   |      100 |    76.92 |      100 |      100 |                |
  Texture2DLoader.js           |      100 |      100 |      100 |      100 |                |
  TextureLoader.js             |      100 |      100 |      100 |      100 |                |
  TextureLoaderNDArray.js      |      100 |      100 |      100 |      100 |                |
  TextureLoaders.js            |      100 |      100 |      100 |      100 |                |
  Visitor.js                   |      100 |      100 |       75 |      100 |                |
  VisitorLogger.js             |      100 |    92.59 |      100 |      100 |                |
  Visitors.js                  |      100 |      100 |      100 |      100 |                |
  connectSize.js               |      100 |    85.71 |      100 |      100 |                |
  copyShader.js                |      100 |      100 |      100 |      100 |                |
  createSurface.js             |    97.09 |    83.61 |    94.55 |    99.32 |            361 |
  genId.js                     |      100 |      100 |      100 |      100 |                |
  index.js                     |      100 |      100 |      100 |      100 |                |
 src/helpers                   |      100 |       75 |      100 |      100 |                |
  disposable.js                |      100 |       50 |      100 |      100 |                |
  invariantNoDependentsLoop.js |      100 |      100 |      100 |      100 |                |
-------------------------------|----------|----------|----------|----------|----------------|
Test Suites: 1 passed, 1 total
Tests:       38 passed, 38 total
Snapshots:   4 passed, 4 total
Time:        2.655s
Ran all test suites.
```

One limitation is that all tests need to be in a single file. [I created an issue here](https://github.com/facebook/jest/issues/2029). I think it's either an issue in [Jest][jest] or in [headless-gl][headless-gl].

## Tradeoffs and remaining work

The library tradeoffs are written in [TRADEOFFS.md](https://github.com/gre/gl-react/blob/master/TRADEOFFS.md). We might cover some unexplored direction in a near future and solve some of them.

v3 is still in development, the main unfinished part is the React Native implementation which is now the main priority of the library.
It will probably rely on an awesome initiative: a React Native WebGL implementation started in Exponent by [@nikki](https://github.com/nikki93)!

For more information, see [v3 alpha: development in progress](https://github.com/gre/gl-react#v3-alpha-development-in-progress).

gl-react has been reimplemented from scratch, feedback from previous mistake and overview of new features.

gl-react v3

[Relay]: https://github.com/facebook/relay
[Relay-spec]: https://facebook.github.io/relay/docs/graphql-relay-specification.html#content


[Relay][Relay] doesn't solve for you how you should render your components. Relay is "universal" and doesn't even assume it will be running in a browser context. It focuses only on providing an abstraction to work with GraphQL – the same way React focuses only on rendering. Each library solves one single problem at a time *(and hell, both are complex enough problem to solve already)*.

Because these libraries are very generic, it's now up to the community to solve the "more specific" parts. Just search on NPM and you can find tons of React libraries already, some might help you to solve part of the problem you want to solve.

This article demonstrates one use-case: **implementing a component handling the scroll of a list to pull more data** of a GraphQL connection with Relay.



## Usage

In React you should think in term of components that subdivide individual task to solve. To solve scrolling a connection you should just need this:

```js
<InfiniteScrollable relay={relay}>
  ...
</InfiniteScrollable>
```

Here is a real use-case we have at [projectseptember](https://projectseptember.com).


```js
import React, {
  Component,
  PropTypes,
} from "react";
import Relay from "react-relay";
import List from "material-ui/List";
import Content from "./Content";

class ContentStream extends Component {
  static propTypes = {
    relay: PropTypes.object.isRequired,
    user: PropTypes.object,
  };
  render () {
    const { user, relay } = this.props;
    return (
      <InfiniteScrollable relay={relay}>
        <List>
          {user.stream.edges.map(e =>
            <Content content={e.node} key={e.cursor} />
          )}
        </List>
      </InfiniteScrollable>
    );
  }
}

export default Relay.createContainer(ContentStream, {
  initialVariables: {
    first: 50,
  },
  fragments: {
    user: () => Relay.QL`
fragment on User {
  stream (first:$first) {
    edges {
      cursor
      node {
        ${Content.getFragment("content")}
      }
    }
  }
}
    `
  }
});
```

We don't have to express how to "pull for more data" in that code. In fact, this is delegated to `InfiniteScrollable` and we never have to think again about it.


## InfiniteScrollable implementation

Relay enforces to implement [a subset of GraphQL spec](https://facebook.github.io/relay/docs/graphql-relay-specification.html#content), like the Connection API. It's a good thing because we can also rely on this fact, and what we only need is the `relay` object to implement a generic pull-on-scroll.


```js
import {
  Component,
  PropTypes,
} from "react";
import {findDOMNode} from "react-dom";

const regex = /(auto|scroll)/;

const style = (node, prop) =>
  getComputedStyle(node, null).getPropertyValue(prop);

const scroll = (node) =>
  regex.test(
    style(node, "overflow") +
    style(node, "overflow-y") +
    style(node, "overflow-x"));

const scrollparent = (node) =>
  !node || node===document.body
  ? document.body
  : scroll(node)
    ? node
    : scrollparent(node.parentNode);

const resizeEventOn = n => n===document.body ? window : n;

export default class InfiniteScrollable extends Component {
  static propTypes = {
    children: PropTypes.any.isRequired,
    relay: PropTypes.object,
    style: PropTypes.object,
    loadPixelsInAdvance: PropTypes.number,
    relayVariable: PropTypes.string,
    chunkSize: PropTypes.number,
    // loadMore could even be generalize, this component works if you provide loadMore instead of relay
    loadMore: PropTypes.func, // (can) returns a promise
  };
  static defaultProps = {
    loadPixelsInAdvance: 1000,
    relayVariable: "first",
    chunkSize: 50,
  };

  state = { loading: false };

  resizeBoundOnDom = null;

  componentDidMount () {
    this.syncScrollBodyListener(this.props);
    this.checkScroll();
  }

  componentWillUnmount () {
    this.unbindResizeEvent();
  }

  componentDidUpdate () {
    this.syncScrollBodyListener();
  }

  unbindResizeEvent () {
    if (this.resizeBoundOnDom) {
      this.resizeBoundOnDom.removeEventListener("scroll", this.checkScroll);
      this.resizeBoundOnDom = null;
    }
  }

  getScrollParent () {
    return scrollparent(findDOMNode(this));
  }

  syncScrollBodyListener = () => {
    const resizeBoundOnDom = resizeEventOn(this.getScrollParent());
    if (resizeBoundOnDom !== this.resizeBoundOnDom) {
      this.unbindResizeEvent();
      resizeBoundOnDom.addEventListener("scroll", this.checkScroll);
    }
  };

  loadMoreUsingRelay = () => {
    const { relay, relayVariable, chunkSize } = this.props;
    return new Promise((resolve, reject) =>
     relay.setVariables({
       [relayVariable]: relay.variables[relayVariable] + chunkSize
     }, readyState => {
       if (readyState.error) reject(readyState.error);
       if (readyState.done) resolve();
     }));
  };

  checkScroll = () => {
    if (this.state.loading) return;
    const container = this.getScrollParent();
    if (!container) return;
    const { height } = container.getBoundingClientRect();
    const { scrollHeight, scrollTop } = container;
    const bottom = scrollTop + height;
    const { loadPixelsInAdvance } = this.props;
    const advance = bottom - scrollHeight + loadPixelsInAdvance;
    if (advance > 0) {
      this.setState({ loading: true }, () =>
        Promise.resolve({ advance, bottom, scrollHeight, height, scrollTop, loadPixelsInAdvance })
        .then(this.props.loadMore || this.loadMoreUsingRelay)
        .then(
          () => this.setState({ loading: false }), // technically could recall checkScroll here. in second callback of setState. fork it, try it, adapt it !
          e => (console.warn(e), this.setState({ loading: false }))
        ));
    }
  };

  render () {
    // you might want to render a spinner?
    // children might be a function?
    // etc..
    // these are some variations we could have from this starting point
    return this.props.children;
  }
}
```


This is a **possible implementation** of this problem. You might want to add more things based on your needs. For instance you could automatically render a loading spinner... or a million other things! Please try it, fork it, give feedback :)

It is also possible to implement it as a High Order Component (HOC): [https://github.com/facebook/relay/issues/1377](https://github.com/facebook/relay/issues/1377).

implement a component handling the scroll of a list to pull more data of a Graphql Connection with Relay

Relay, scrolling connections

[twitter]: https://twitter.com/ProjSeptEng
[website]: https://projectseptember.com
[RN]: http://facebook.github.io/react-native/
[graphql]: http://graphql.org/
[scala]: http://scala-lang.org/
[glreactconf]: /2016/06/glreactconf
[glreact]: https://github.com/ProjectSeptemberInc/gl-react
[glreactdom]: https://github.com/ProjectSeptemberInc/gl-react-dom
[glreactnative]: https://github.com/ProjectSeptemberInc/gl-react-native
[RNAnimation]: https://facebook.github.io/react-native/docs/animations.html

 🎉 Hooray! [We][twitter] recently released an iOS app called [Project September][website].

This application is built with nice tech stack including [React Native][RN] and [GraphQL][graphql]. The backend is powered by [Scala][scala], a robust functional language, and we use many other [cool techs][twitter].

This fashion app needed some fancy features: one was demo-ed at last [React.js conference][glreactconf] with the ability to do localized blur on text over images.

We have developed **[`gl-react`][glreact]** to abstract GL in React paradigm – with two companion libraries [`gl-react-dom`][glreactdom] and [`gl-react-native`][glreactnative] that glues React Native with OpenGL.

Let's first see 2 demos of OpenGL usage in our app, and then we'll write a bit about how it's hard to get animations right.



## The Text Over Image blur

### The goal

<img width="50%" src="/images/2016/07/current-1.png" /><img width="50%" src="/images/2016/07/current-2.png" />

### How it works

<img src="/images/2016/07/initial.png" />

**+** ***(layer)***

<img src="/images/2016/07/layer.png" />

**=**

<img src="/images/2016/07/result.png" />


### Under the hood

- The shadow intensity, size, position, is procedurally generated, we can adjust that. The shadow color is the blurry image color
- The text color is determined by the color picked in blurred image at the shadow middle position. **If the `monochrome` value of that color is lower than 60%**, text will be white, otherwise text will be black.

Here is more detail on how the shadow is generated:


<img src="/images/2016/07/under-1.png" />


**\* (multiply alpha)**

<img src="/images/2016/07/under-2.png" />

**=**

<img src="/images/2016/07/under-3.png" />

**+ (layer)**

<img src="/images/2016/07/under-4.png" />

**=**

<img src="/images/2016/07/layer.png" />

### Fragment shader

```glsl
precision highp float;
varying vec2 uv;

uniform sampler2D img;
uniform sampler2D imgBlurred;
uniform sampler2D txt;

const vec2 shadowCenter = vec2(0.5, 0.9);
const vec2 shadowSize = vec2(0.6, 0.2);
float shadow () {
  return 0.8 * smoothstep(1.0, 0.2, distance(uv / shadowSize, shadowCenter / shadowSize));
}
float monochrome (vec3 c) {
  return 0.2125 * c.r + 0.7154 * c.g + 0.0721 * c.b;
}
vec3 textColor (vec3 bg) {
  return vec3(step(monochrome(bg), 0.6));
}

void main () {
  vec4 bg = mix(texture2D(img, uv), texture2D(imgBlurred, uv), shadow());
  vec4 fg = vec4(textColor(texture2D(imgBlurred, shadowCenter).rgb), 1.0);
  float fgFactor = 1.0 - texture2D(txt, uv).r;
  gl_FragColor = mix(bg, fg, fgFactor);
}
```

### Integration

```html
<GL.Node shader={shaders.textOverImage}>
  <GL.Uniform name="img">
    {img}
  </GL.Uniform>
  <GL.Uniform name="imgBlurred">
    <Blur factor={20} passes={6} width={width} height={height}>
      {img}
    </Blur>
  </GL.Uniform>
  <GL.Uniform name="txt">
    <Text style={titleStyle}>{title}</Text>
  </GL.Uniform>
</GL.Node>
```

## Uploading Thumbnail

This is a video record of our app:

![](/images/2016/07/upload.gif)

The uploading spinner effect is implemented with an OpenGL shader. This was not easy to avoid all the blinks we used to have. We have different components to render each step (uploading animation / uploaded final image) and the uploaded image needs to be downloaded again to not render as white. One solution could be to use a monolithic "thumbnail" component that do everything. We wanted to  keep independent components.
Hopefully, everything now works seamlessly with some "double buffering"/swapping mechanism we will explained at the end of this article.

## Animate all the things

### Designing animations

> Fluid, meaningful animations are essential to the mobile user experience.
**[— React Native Animations documentation][RNAnimation]**

It's not easy to design how an application should animate, to define transitions between all the different possible single state and edge-cases of your app. Designing animations, as part of UX design, is a time consuming work but it tends to be underestimated while being essential for moving from a *good app* to a *very good app*. That tends to be the last 20% remaining missing parts of your app that are the hardest but that makes the 80% of a great UX.

### Implementing animations

Not only it's hard to have figured out the animations (to find the optimal UX) but it can also be quite challenging to implement them in a maintainable and robust way. Turns out most of the times, your code is not ready for it and it implies big refactoring.

#### in React Native

React Native [Animations API][RNAnimation] makes it easier: you just have to switch to one of the `Animated.*` component. In `gl-react` we even support Animated values to flow into the shaders uniforms so it's very convenient to animate a GL effect.

That said, React Native Animations is not the ultimate silver bullet. There are things Animations won't solve for you. React Native Animated is still a low level API, it's also imperative and not opinionated on how you should turn it into descriptive paradigm.

I guess what's generally hard with animations in React functional/descriptive paradigm ("always `render()`ing Virtual DOM again" idea) is to figure out **how to not "break" your animations**. For instance, ugly animation interruption could happen if you `render()` a different component: because it forces the component to unmount. If you have an animation happening, you might not want it to stop, or at least you might want to smoothly customize the transition to the new state.

That's something CSS transitions might help solving, but in React Native we don't have them, so it's not so trivial.

##### our current solution

We have built our own abstraction to solve this problem: a Component decorator manages to kill a lot of flashes and blinks cases (e.g. images not ready yet, animation getting interrupted).

> What the decoration solves: when moving from A to B, you want B to be ready (e.g. images are loaded), you also want A to have finish its (animated) work.

**A component can express it needs some time to mount *(e.g. an image to load!)* OR that it needs some time to unmount *(e.g. an "animating out")*. This will basically hold the rendering to happen:**

The decoration can implement "double buffering" on a Component: `render()` function keeps rendering Component with the previous "stable props" but will also render in background another instance of Component with the next props. When that next props Component is ready and loaded, we can successful swap it to be the new "stable props".

You have the basic idea, the decorator is not so trivial to implement as it also needs to handle some edge-cases, for instance if the decorator receives new props during the transition. We also have a minimal way to express "styles transitions" similarly to how CSS Transitions works.

🎉 There are some OpenGL in the Project September fashion app!

Universal GL Effects for Web and Native

<img src="/images/2015/10/gl-react.png" alt="" class="thumbnail-left" /> Last Thursday, my talk at [React Paris Meetup](http://www.meetup.com/ReactJS-Paris/events/226103821/) was about using **the functional rendering** paradigm of **WebGL** in **React**. The library [`gl-react`](https://github.com/ProjectSeptemberInc/gl-react) wraps WebGL in React paradigm with a focus for developing 2D effects, that we need in my current startup, [Project September](https://twitter.com/ProjSeptEng), where I have the chance to develop it.

## [Slides](http://greweb.me/reactmeetup7)

<iframe src="http://greweb.me/reactmeetup7" width="600" height="400" frameborder="0"></iframe>



## Abstract

We can write effects without having to learn the complex and imperative low-level WebGL API but instead composing React components, as simple as functional composition, using VDOM descriptive paradigm.

[gl-react](https://github.com/ProjectSeptemberInc/gl-react) brings WebGL bindings for react to implement complex effects over content.

[gl-react-native](https://github.com/ProjectSeptemberInc/gl-react-native) is the React Native implementation,
therefore allows universal effects to be written both for web and native.

These libraries totally hides for you the complexity of using the OpenGL/WebGL API but takes the best part of it: GLSL, which is a "functional rendering" language that runs on GPU.

This presentation is an introduction to WebGL in React and functional programming concept and showcases made with gl-react and gl-react-native

Introducing gl-react

*^ Sorry guys, you may have notice the blog post date is wrong. I won't change the URL, but thanks to how time works, this will be fixed in one month anyway :-D*

[ReactEurope](https://twitter.com/chantastic/status/616608931037646850) conference
was to me incredibly [inspiring](https://twitter.com/chantastic/status/616670658911715328) and [promising](https://twitter.com/chantastic/status/616995607043903488).
Yersterday got tons of news and tweets from JavaScript community.

One tweet and blog post by the great [@aerotwist](https://twitter.com/aerotwist) got my attention.

<blockquote class="twitter-tweet" data-cards="hidden" lang="fr"><p lang="en" dir="ltr">I often hear claims that “the DOM is slow!” and “React is fast!”, so I decided to put that to the test:&#10;&#10;<a href="https://t.co/M1RZZiyVT2">https://t.co/M1RZZiyVT2</a>&#10;&#10;🐢vs🐇</p>&mdash; Paul Lewis (@aerotwist) <a href="https://twitter.com/aerotwist/status/616934953679458304">3 Juillet 2015</a></blockquote>

I would like to express here my opinion and feedback on using React.

I've been using React for almost 2 years now, and always in performance intensive use-cases, from Games to WebGL.

<a href="http://diaporama.glsl.io/" target="_blank">
<img src="/images/2015/07/diaporama_3.jpg" alt="" class="thumbnail-left" />
</a>

I've created [glsl.io](http://glsl.io/) and I'm working on [Diaporama Maker](https://github.com/gre/diaporama-maker).
Both applications are built with React and combined use of HTML, SVG, WebGL.

Diaporama Maker is probably the most ambitious piece of software I've ever personally done.

<br style="clear: left" />

> In short, [Diaporama Maker](https://github.com/gre/diaporama-maker) it is a WYSIWYG editor for web slideshow (mainly photo slideshows). It is a bit like iMovie with the web as first target. [The project is entirely open-sourced.](https://github.com/gre/diaporama-maker)

Currently, I am able to render the whole application at 60 FPS and this is still unexpected and surprising to me
(press Space to run the diaporama on [diaporama.glsl.io demo](http://diaporama.glsl.io/)).
Well, more exactly, this would not have been possible without some optimizations
that I'm going to detail a bit at the end of this article.



## The point is productivity

I don't think Virtual DOM claims to be faster than doing Vanilla DOM, and that's not really the point. **The point is productivity.**
You can write very well optimized code in Vanilla DOM but this might require **a lot of expertise**
and a lot of time even for an experienced team *(time that should be spent focusing on making your product)*.

When it comes to adding new features and refactoring old ones, this goes worse.
Without a well constrained framework or paradigm, things does not scale far, are time consuming and introduce bugs,...
Especially in a team where multiple developers have to work with each other.

> **See Also:** [Why does React scale?](https://www.youtube.com/watch?v=D-ioDiacTm8) by [@vjeux](https://twitter.com/Vjeux).

## What matters to me

There is a lot of advantages of using Virtual DOM approach before talking about React performances.

Of course, this always depends on what you are building, but I would claim that
**there is a long way to go using React before experiencing performance issues**,
and in the worse cases: **you can almost always find easy solutions to optimize these performance issues**.

### DX

React has an incredible Developer eXperience (that people seem to call DX nowadays!) that can [help you improving UX](https://twitter.com/greweb/status/617258379183005696) and the ability to [measure Performances](https://facebook.github.io/react/docs/perf.html) and [optimize them](https://facebook.github.io/react/docs/component-specs.html#updating-shouldcomponentupdate) when you reach bottlenecks.

You can easily figure out which component is a bottleneck in the Component tree as shown in following screenshot.

> ![](/images/2015/07/diaporama-perfs.png)
With printWasted() you can see how much time React has wasted to `render()` something that didn't change and how much instances has been created. (there is also printInclusive and printExclusive)

This is a bit equivalent of the Web Console Profiler except it emphasis on your application components which is a very relevant approach.

### React data flow

> I can't imagine re-writing Diaporama Maker in Vanilla DOM.

In Diaporama Maker, I have a lot of cross dependencies between components,
for instance the current `time` is shared and used everywhere in the application.
As a matter of fact, dependencies grow when adding more and more features.

> ![](/images/2015/07/diaporama_configure_kenburns.gif)
usages of time in 3 independent components.

**The descriptive Virtual DOM approach very simply solves this problem**.
You just have to pass props in to share data between components:
there is one source of trust that climb down your component tree via "props".

![](/images/2015/07/diaporama-maker-time-props.jpg)

With Virtual DOM approach, the cost to add one new dependency to a shared data is small and **does not become more complex as the application grows**.

> ![](/images/2015/07/diaporama_slide_content.gif)
another more complex showcase of shared states.

Using an Event System like you would do in standard Backbone approach tends to lead to imperative style and spaghetti codes (and when using global events, components are not really reusable).

Moreover, I think that `Views<->Models` Event System approach, if not carefully used, tends to converge to an unmaintainable and laggy applications.

### React is a Component library

React truly offers **component as first-class citizen**.
This means it allows component reusability. I've tried alternative like virtual-dom and I don't think it emphasizes enough on this benefit.

There are [important good practices](https://twitter.com/chantastic/status/616997918155759616) when using React like minimizing states and props and I'm not going to expand more on this subject. Most of these best practices are not exclusive to React but come from common sense and software architecture in general.
One of the important point for performance is to **choose a good granularity of your component tree**.
It is generally a good idea to split up a component into pieces as small as possible
because it allows to separate concerns, minimize props and consequently optimize rendering diff.

#### Diaporama Maker architecture

You would be surprised to know that Diaporama Maker does not even use **Flux** (that might be reconsidered soon for collaborative features). I've just taken the old "callback as props" approach all the way down the component tree. That easily makes all components purely modular and re-usable (no dependencies on some Stores).
I've also taken the [inline style approach]() without actually using any framework (this is just about props-passing `style` objects).

As a consequence, I've been able to externalize a lot of tiny components that are part of my application
so I can share them across apps and also in order to people to re-use them.

What is important about externalizing components is also the ability to test and optimize them independently (the whole idea of modularity).

Here are all the standalone UI components used by Diaporama Maker:

- [bezier-easing-editor](https://github.com/gre/bezier-easing-editor)
- [bezier-easing-picker](https://github.com/gre/bezier-easing-picker)
- [diaporama-react](https://github.com/glslio/diaporama-react)
- [glsl-transition-vignette](https://github.com/glslio/glsl-transition-vignette)
- [glsl-transition-vignette-grid](https://github.com/glslio/glsl-transition-vignette-grid)
- [glsl-uniforms-editor](https://github.com/gre/glsl-uniforms-editor)
- [kenburns-editor](https://github.com/gre/kenburns-editor)

(each one have standalone demos)


## Optimizing performances

<blockquote class="twitter-tweet" lang="fr"><p lang="en" dir="ltr">I&#39;ve been working on crazy projects using React (like <a href="http://t.co/U2oETh5lhZ">http://t.co/U2oETh5lhZ</a> ). most performance issues i&#39;ve met was not because of React</p>&mdash; Gaëtan Renaudeau (@greweb) <a href="https://twitter.com/greweb/status/617210444839809024">4 Juillet 2015</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

Here are 2 examples of optimizations I had to do in Diaporama Maker that are not because of React:

- It is easy to write not very optimized WebGL, so I work a lot to optimize the pipeline of [Diaporama engine](https://github.com/gre/diaporama)
- CSS transforms defined on Library images was for a time very intensive for the browser to render so I am now using server-resized "thumbnails" instead of the full-size images. Asking the browser to recompute the `transform: scale(...)` of 50 high resolution images can be super costy. (without this optimization, the resize of the application was running at like 2-3 FPS because the library thumbnails need to recompute their scale and crop).

But what if you still have performance issue due by React? Yes this can happens.

### Timeline Grid example

In Diaporama Maker, I have a Component that generates a lot of elements (like 1300 elements for a 2 minutes slideshow) and my first naive implementation was very slow. This component is [TimelineGrid](https://github.com/gre/diaporama-maker/blob/b0c6447b127785bea3c2487b0c77037418298b8c/client/ui/TimelineGrid/index.js) which renders the timescale in the timeline. It is implemented with SVG and a lot of `<text>` and `<line>`.

The performance issue was noticeable when drag and dropping items across the application. React was forced to render() and compare the whole timescale grid every time. But the timescale does not change! it just have 3 props:

```xml
<TimelineGrid timeScale={timeScale} width={gridWidth} height={gridHeight} />
```

**So it was very easy to optimize it just by using the `PureRenderMixin` to say to react that all my props are immutable.**
(I could have implemented `shouldComponentUpdate` too).

After this step, and for this precise example, I don't think a Vanilla DOM implementation can reach better performance:

- when one of the grid parameter change, **EVERYTHING** need to be recomputed because all scales are changing.
- React is doing even smarter thing that I would not manually do? Like reusing elements instead of destroying/creating them.

There might still be ways to go more far in optimizing this example. For instance I could chunk my grid into pieces
and only render the pieces that are visible, like in an infinite scroll system *(I could use something like [sliding-window](https://github.com/gre/sliding-window) for this)*.
That would probably be premature optimization for this example.

## Wrap Up

To my mind, generic benchmarks always tends to be biased and does not represent use-cases reality unless you are really covering your application itself.

The TimelineGrid component optimization explained in this article is a very specific and well chosen example,
but it is one counter-example for such a benchmark.

Each application has its own needs and constraints and we can't really generalize one way to go.
Also Performance should not be the main concern to choose a technology.


It is easy to make Virtual DOM library benchmarks,
comparing the performance of rendering and Array diffing,
but does that covers 80% of use-cases?
Is performance really the point?
What tradeoff do you accept to make between Performance and Productivity?

Tell me what you think.

In the meantime, I think we can all continue getting applications done
and [developing amazing DX](https://github.com/gaearon/react-hot-loader).

I would like to express here my opinion and feedback on using React and performance optimization you can do.

Making performant React applications

A talk I did at webglparis to present GLSL.io and GLSL Transitions initiative.

[FR] webglparis talk: GLSL.io initiative and WebGL Transitions

[gamepost]: /2014/09/ibex
 [js13kgames]: http://js13kgames.com/
 [submission]: http://js13kgames.com/entries/ibex
 [github]: http://github.com/gre/js13k-2014
 [cellular]: http://en.wikipedia.org/wiki/Cellular_automaton
 [wolfram]: http://en.wikipedia.org/wiki/Stephen_Wolfram
 [ankos]: https://www.wolframscience.com/
 [gol]: http://en.wikipedia.org/wiki/Conway's_Game_of_Life
 [cavelikegen]: http://www.roguebasin.com/index.php?title=Cellular_Automata_Method_for_Generating_Random_Cave-Like_Levels
 [logicfrag]: https://github.com/gre/js13k-2014/blob/master/src/shaders/logic.frag


<a href="/2014/09/ibex">
  <img src="/images/2014/09/ibex-2.png" alt="" class="thumbnail-right" />
</a>

Last week I finished my [JS13K game called "IBEX"][gamepost],
an apocalyptic game where you have to help some wild ibex to escape from the inferno.

> IBEX received the 16th place (out of 129 games) from the [js13kgames][js13kgames] jury.

This article is a technical post-mortem about the development of this game in JavaScript / WebGL
and how the world is just **ruled with [cellular automata][cellular]**
and computed efficiently in a GLSL shader.

<iframe width="50%" height="220" src="//www.youtube.com/embed/nqD2qIy4auU" frameborder="0" allowfullscreen></iframe>



## Cellular automata ruled world

A **Cellular Automaton** (plurial Cellular Automata) is an **automaton** *(in other words, a state machine)*
based on **a grid (an array) of cells**.
It has been discovered years ago and popularized by [Stephen Wolfram][wolfram]
in his interesting book [A new Kind of Science][ankos].


<figure class="thumbnail-right">
  <img src="/images/2014/09/elementary-automaton.png" />
  <figcaption>
    <a href="http://mathworld.wolfram.com/ElementaryCellularAutomaton.html">
      elementary automata.
    </a>
  </figcaption>
</figure>

The simplest possible cellular automaton is the one where, at each generation,
the cell value is determined from the **previous and the 2 adjacent cells** (left and right)
value and where the value can only be **0 or 1** (white or black / true or false).
The way the cell value is determined is through a set of rules.

> In an elementary cellular automaton, there is a total of 8 rules, which means 256 possible cellular automata.

### 2D cellular automaton

<figure class="thumbnail-left">
  <img src="/images/2014/09/Gospers_glider_gun.gif" />
  <figcaption>
    <a href="http://en.wikipedia.org/wiki/Conway's_Game_of_Life">Conway's Game of Life</a>,
    a well known 2D cellular automaton.
  </figcaption>
</figure>

The kind of Cellular Automaton I focused on for my game is **2D cellular automaton**:
At each generation, the cell value is determined from **the previous value and the 8 adjacent cells**
using a finite set of rules.

It is important to understand that these rules are applied in parallel for __all__ cells of the world.

<br />

<figure class="thumbnail-right">
  <img src="/images/2014/09/ibex-experiment2.png" />
  <figcaption>
    Early version with 4 elements and simple rules:
    Water falls in Air, Fire grows in Air, Water extinguishes Fire, Earth drops Water + creates Fire
  </figcaption>
</figure>

**A 2D cellular automaton rule:**

![](/images/2014/09/ibex-rule-2d.png)

What I've found is that
**the WebGL and the GLSL language works well to implement a cellular automaton**.

The GLSL paradigm is what I like to call [functional rendering](/2013/11/functional-rendering/):
It is, to simplify, a function **`(x,y) => (r,g,b,a)`**:
You fundamentally have to implement this function which **gives a color for a given viewport position**,
and you implement it in a dedicated language which compiles to the GPU.

So we can implement a 2D cellular automaton where each cell is a real (x,y) position in the Texture
and where the (r,g,b,a) color is used to encode your possible cell states, and that's a lot of possible encoding!

In my game, i've chosen to only use the `"r"` component to implement the cell state.
But imagine all the possibilities of encoding more data per cell (like the velocity, the amount of particle in the cells,...).

**Here is a boilerplate of making a Cellular Automaton in GLSL:**

```glsl
uniform sampler2D state; // the previous world state texture.
uniform vec2 size; // The world size (state texture width and height)

/*
 The decode / encode functions provide an example of encoding
 an integer state in the "r" component over possible 16 values.
 You can definitely implement your own. Also "int" could be something more complex
 */
int decode (vec4 color) {
  return int(floor(.5 + 16.0 * texture2D(state, uv).r));
}
vec4 encode (int value) {
  return vec4(float(r) / 16.0,  0.0, 0.0, 1.0);
}

/*
  get(x,y) is doing a lookup in the state texture to get the (previous) state value of a position.
 */
int get (int x, int y) {
  vec2 uv = (gl_FragCoord.xy + vec2(x, y)) / size;
  return (uv.x < 0.0 || uv.x >= 1.0 || uv.y < 0.0 || uv.y >= 1.0) ? 0 :
    decode(texture2D(state, uv).r);
}

void main () {
  // We get all neighbors cell values from previous state
  int NW = get(-1, 1);
  int NN = get( 0, 1);
  int NE = get( 1, 1);
  int WW = get(-1, 0);
  int CC = get( 0, 0);
  int EE = get( 1, 0);
  int SW = get(-1,-1);
  int SS = get( 0,-1);
  int SE = get( 1,-1);

  int r; // r (for result) is the new cell value.

  ////////////////////////////
  // NOW HERE IS THE COOL PART
  // where you implement all your rules (from the 9 state values)
  // and give a value to r.
  ////////////////////////////

  gl_FragColor = encode(r);
}
```

>**The complete game rules are all implemented in a GLSL fragment shader:
[logic.frag][logicfrag]**.
It is important to understand that this fragment shader takes in input
the previous world state (as an uniform texture)
and computes a new state by applying the rules.

On the JavaScript side, you need to **give an initial state to the texture**
(so you need to also encode data the same way it is done in the shader).
Alternatively you can also make a shader to do this job
*(generating the terrain can be intense to do in JavaScript, like it is the case for my game...)*.

Also if you want to **query the world from JavaScript**,
*(e.g. you want to do physics or collision detection like it is also the case for my game)*,
you need to use `gl.readPixels` and then decode data in JavaScript.

I'll explain this a bit later in another article.
Let's now go back to the Cellular Automaton used in IBEX.

<figure>
  <img src="/images/2014/09/ibex-screenshot1.png" />
  <figcaption>
    The different elements gameplay.
  </figcaption>
</figure>

### The elements

The game theme was "Four Elements: **Water, Air, Earth, Fire**", so I've used
these 4 elements as primary elements of the cellular automaton.

Each elements also have secondary elements that can be created from each other interactions:
**Source, Volcano, Grass, WindLeft, WindRight**.

- The **Volcano** is lava growing in the Earth. It creates Fire (when there is Air).
- The **Source** is water infiltrating in the Earth. It drops Water (when there is Air).
- The **Grass** (or Forest) grows on Earth with Water. It is a speed bonus for ibex but it propagates fire very fast. It also stop the water from flowing.
- The **Wind** (left or right wind) is created randomly in Air. It have effects on Water and Fire propagation and also on ibex speed.

**Some constants...**

```glsl
// Elements
int A  = 0; // Air
int E  = 1; // Earth
int F  = 2; // Fire
int W  = 3; // Water
int V  = 4; // Volcano
int S  = 5; // Source
int Al = 6; // Air Left (wind)
int Ar = 7; // Air Right (wind)
int G  = 8; // Grass (forest)
```

<figure class="thumbnail-right">
  <img src="/images/2014/09/ibex-experiment1.png" />
  <figcaption>
    Fun and experimental result accidentally produced in an early development of the rules.
  </figcaption>
</figure>

To summary, there is 9 possible elements,
and rules are determined from the 9 previous cells:
This makes a LOT of possible rules.
However, the rules involved here remain simple and with just a few rules.

> That is the big thing about cellular automata:
very simple rules produce an incredible variety of results.

In general, we can classify my game rules into 2 kind of rules:
"interaction" rules and "propagation" rules.
The first kind describes how two (or more!) elements interact each other.
The second kind describes the way an element evolve.
Some rules will also mix them both.

### Some simple "propagation rule"

**Earth stays:**
an Earth is returned if there was an Earth before.

![](/images/2014/09/ibex-rule-earth.png)

**Water falls in Air:**
a Water is created if there was a Water on top.

![](/images/2014/09/ibex-rule-water1.png)

**Fire grows in Air:**
a Fire is created if there was a Fire on bottom.

![](/images/2014/09/ibex-rule-fire1.png)


These rules produce very elementary result, we will now see how we can improve them.

### Weights in rules

**More powerful rules can also be reached by using weights**:
you can affect a weight for each neighbor cell to give more or less importance to them.

Let's take a look at a simple example:

![](/images/2014/09/ibex-rule-gencave-example.png)

> N.B.: only the "sum" is considered in the rule:
if an element matches, we sum the weight of the cell, otherwise "zero".

**This example is actually a weighted version of [the cave rule you can find here][cavelikegen]:**

<figure>
  <figcaption>
    Result of the rule, with (Air or Earth) random pick for each  initial cell value.
  </figcaption>
  <img src="/images/2014/09/ibex-gencaveresult.png" />
</figure>

### Randomness in rules

**Combine Randomness and Weights and you get a very powerful simulation.**

To avoid seeing some (well known) patterns in the simulation I added some randomness in my rules.
**With randomness, the results are incredibly powerful.**

In the following video, notice how cool the fire propagation can result
by varying the propagation randomness factor.

<iframe width="100%" height="420" src="//www.youtube.com/embed/mF-MNHk7u4s" frameborder="0" allowfullscreen="allowfullscreen"></iframe>

**The code:**

```glsl
#define AnyADJ(e) (NW==e||SE==e||NE==e||SW==e||NN==e||SS==e||EE==e||WW==e)
// ^^^^^^^^ MACRO !
if (
  CC == G &&
  RAND < firePropagation &&
  ( AnyADJ(F) || AnyADJ(V) )) {
  r = F;
}
```

#### Randomness in GLSL ???
GLSL is fully stateless and there is **NO WAY** to have a `random()` function in the GPU.
The trick to do randomness in GLSL is by invoking some math black magic:

```glsl
float rand(vec2 co){
  return fract(sin(dot(co.xy ,vec2(12.9898,78.233))) * 43758.5453);
}
```

**`rand`** is a [popular](http://stackoverflow.com/questions/4200224/random-noise-functions-for-glsl)
function which returns a pseudo-random value (from 0.0 to 1.0) for a given position.

My personal **black magic** was to define a convenient macro to have a "RAND" word which would get me
a new random number.

```glsl
#define RAND (S_=vec2(rand(S_), rand(S_+9.))).x
```

`S_` is a seed which is accumulated when calling this `RAND`.
Because this macro will be inlined in the code, `S_` must be defined in a local variable
(so in summary, `RAND` is doing local side-effect).

```glsl
vec2 p = gl_FragCoord.xy;
vec2 S_ = p + 0.001 * time;
```

Note that **the current pixel position** itself AND **the time** are both used for initializing the seed.
It produces **variable randomness over time and for each pixel**.

Let's now see other examples where randomness can be very powerful.

### The Water and Fire interactions

**Fire grows and diverges**:

![](/images/2014/09/ibex-rule-fire2.png)

- the "left" and the "right" columns in this rule allows **divergence** in the way fire grows:
Instead of growing straight up, **the fire can also move a bit left or a bit right**.
A lower weight for these side columns make the fire diverge a bit less than a "triangle" propagation.

Here is the GLSL code:

```glsl
// Fire grow / Fire + Water
if (
  -0.05 * float(NW==W) + -0.40 * float(NN==W) + -0.05 * float(NE==W) + // If water drop...
  -0.50 * float(WW==W) + -0.50 * float(CC==W) + -0.50 * float(EE==W) + // ...or water nearby.
   0.35 * float(SW==F) +  0.90 * float(SS==F) +  0.35 * float(SE==F)   // Fire will move up and expand a bit.
 >= 0.9 - 0.6 * RAND // The sum of matched weights must be enough important, also with some randomness
) {
  r = F;
}
```

**Water falls, diverges and creates holes**:

![](/images/2014/09/ibex-rule-water2.png)

<figure class="thumbnail-right">
  <img src="/images/2014/09/ibex-rain.png"/>
  <figcaption>The rain in IBEX. Notice how Water diverges a bit and creates holes.</figcaption>
</figure>

- Same as the fire rule, we also have **divergence** in the water.
- However there is one more important thing in the rule:
thanks to the **double inequality**,
Water is created only if there is not already too much Water:
it **results of creating Air between the Water particules**.
This make Water elements to be less compact than Fire elements,
the water does not visually "expand" contrary to the fire.
- The **randomness** helps a lot here to give **no visible patterns** in this job.

<br />

Here are all rules which creates Water:
in this rules you can also notice how **the Water flows on Earth** and how
the **occasional rain** is implemented.

```glsl
if (
// Water drop / Water + Fire
  between(
    0.3 * float(NW==W) +  0.9 * float(NN==W) +  0.3 * float(NE==W) +
    0.1 * float(WW==W) + -0.3 * float(CC==F) +  0.1 * float(EE==W) +
                         -0.3 * float(SS==F)  
    ,
    0.9 - 0.6 * RAND,
    1.4 + 0.3 * RAND
  )

  || // Water flow on earth rules

  !prevIsSolid &&
  RAND < 0.98 &&
  ( (WW==W||NW==W) && SW==E || (EE==W||NE==W) && SE==E )

  || // Occasional rain
  !prevIsSolid &&
  p.y >= SZ.y-1.0 &&
  rainRelativeTime < 100.0 &&
  between(
    p.x -
    (rand(vec2(SD*0.7 + TI - rainRelativeTime)) * SZ.x) // Rain Start
    ,
    0.0,
    100.0 * rand(vec2(SD + TI - rainRelativeTime)) // Rain Length
  )

  || // Source creates water
  !prevIsSolid && (
    0.9 * float(NW==S) +  1.0 * float(NN==S) +  0.9 * float(NE==S) +
    0.7 * float(WW==S) +                        0.7 * float(EE==S)
    >= 1.0 - 0.3 * RAND
  )
) {
  r = W;
}
```

**Source rules**

The Source can be created in the Earth by two rules:
Either there is enough water around,
Or there is source on top.

Note the important usage of randomness.

![](/images/2014/09/ibex-rule-source.png)


### The grass propagation, Limiting the forest height

To finish, the grass needed a special extension to the so-far-used 2D cellular automaton,
the grass cell value is not only being determined from the 8 adjacent cells:

To have more complex structure, **the grass is determined
from the previous cell at position `(x, y-N)`**,
where x and y is the cell position and N is a variable value (random but constant per cell position).
In other word, a forest can grow if the cell at N step under it is not a forest.
This extra rule just adds a constraint on the max height that a forest can have.

<figure>
  <figcaption>A Grass can be created if the (x,y-N) cell is not a Grass.</figcaption>
  <img src="/images/2014/09/ibex-rule-forest-specific.png" />
</figure>


Here is a demo showing the forest propagation randomness:

<iframe width="100%" height="480" src="//www.youtube.com/embed/V_enCKx8XHA" frameborder="0" allowfullscreen="allowfullscreen"></iframe>


### Drawing into the world

**Drawing into the world is also done in GLSL: through uniforms.**
Another alternative way to do that would have be to use `gl.readPixels` to extract it out in JavaScript,
to write into the Array and inject it back to the shader...
but this solution is not optimal because `readPixels` is blocking and costy (CPU time).

```glsl
uniform bool draw; // if true, we must draw for this tick.
uniform ivec2 drawPosition; // The position of the drawing brush
uniform float drawRadius; // The radius of the drawing brush
uniform int drawObject; // The element to draw


void main (void) {
  ...
  bool prevIsSolid = CC==E||CC==G||CC==V||CC==S;

  if (draw) {
    vec2 pos = floor(p);
    if (distance(pos, vec2(drawPosition)) <= drawRadius) {
    // Inside the brush disc
      if (drawObject == W) {
        // Draw Water
        if (prevIsSolid && CC!=G) {
          // Source is drawn instead if there was a solid cell
          r = S;
        }
        else if (!prevIsSolid && mod(pos.x + pos.y, 2.0)==0.0) {
          // We draw Water half of the time because Water is destroyed when surrounded by Water
          r = W;
        }
      }
      else if (drawObject == F) {
        // Draw fire or volcano if solid cell.
        r = prevIsSolid ? V : F;
      }
      else {
        // Draw any other element
        r = drawObject;
      }
    }
  }

  ...
}
```

## World generation is also a Cellular automaton!

The world is generated on the fly when the ibex progress to the right. This is done chunk by chunk.

> More precisely, the world height is 256 pixels and a new part of the world is discovered each 128 pixels –
In other words, the generation is divided into world chunks of `(128 x 256)` pixels.

Each world chunk is generated using a cellular automaton (different from the simulation one).

As shown in a previous example,
we can easily generate "cave like maps" from [this technique][cavelikegen].
I've added to this a [few improvments](https://github.com/gre/js13k-2014/blob/master/src/index.js#L842):

- The [initial random conditions](https://github.com/gre/js13k-2014/blob/master/src/index.js#L881) ensure
that **the bottom of the world is Earth** and that **the top of the world is Air**.
*(that with gradients of randomness)*
- [Randomness](https://github.com/gre/js13k-2014/blob/master/src/index.js#L896-L906)
has been added to the rules to make the terrain evolving a bit more
*(otherwise it creates stable but small caves)*.
- The number of generation step is set to 26. the randomness of the rules is decreasing through steps to produce stable results.
- In an attempt to create **seamless maps**,
the initial random state for x=0 is set to the values of x=127 of the previous world chunk.
[(code here)](https://github.com/gre/js13k-2014/blob/master/src/index.js#L878)
It isn't perfect because you can still notice some edges.
- For **more diversity in generated chunks**, here are the parameters that can [randomly vary](https://github.com/gre/js13k-2014/blob/master/src/index.js#L845-L848):
  - The **amount of Earth** (can create dense areas VS floating platform areas)
  - The **chance of Water Source** in the Earth (will creates a lot of forest)
  - The **chance of Volcano** in the Earth (dangerous world chunk)

![](/images/2014/09/ibex-gen-variety.png)


## More articles to come

Did you like this article?

I'll try to write more about these subjects:

- The **"Pixels paradigm"**, Pixel as first class citizen: How to query and analyze the pixels world. How to do simple bitmap collision detection.
- The **game rendering performed in a GLSL shader** and all the graphics details I've spent hours on.
- **things I've learned from WebGL**, how to solve the bad approaches I've taken,
and how I could have made a much more efficient game.
- **what could have made this game even more interesting**,
and some ideas that was not reachable in a 2 weeks deadline.

IBEX is my game made for js13kgames. This article explains how the game has been implemented with GLSL and cellular automata.

Cellular Automata in IBEX

[js13kgames]: http://js13kgames.com/
 [submission]: http://js13kgames.com/entries/ibex
 [github]: http://github.com/gre/js13k-2014
 [cellular]: http://en.wikipedia.org/wiki/Cellular_automaton

<a href="http://js13kgames.com/entries/ibex">
  <img src="/images/2014/09/ibex.png" alt="" class="thumbnail-left" />
</a>

**I've just [finished and submitted][submission] my game for [js13kgames][js13kgames],**
a contest where you have to make a web game in less than 13 kilobytes of a ZIP archive.

**[PLAY IT HERE][submission]** / [github][github]

**I had a lot of fun making this game and I think it is by far the best game I ever finished.**
It is a bit a continuation of my ["antsim" game](/2014/05/ld29) prototype in the idea
that you don't control directly the entities but you are at an higher level with simple interactions.

The game should be performant enough but however 
require that you have a good hardware to support WebGL and some advanced limits (I used too much uniforms).
I'll talk more about the compatibility and performance issues in a next postmortem article.

If it doesn't work for you, please report me a dump of [http://webglreport.com/](http://webglreport.com/).

## Playthrough

<iframe width="100%" height="440" src="//www.youtube.com/embed/nqD2qIy4auU" frameborder="0" allowfullscreen></iframe>



## The Story

The world is burning, Protect and Escort a group of wild ibex away from the inferno.
On the path there are sleeping ibex to rescue, wake them and they will join the group.

## The Gameplay


You will have to use the **4 elements (Air, Earth, Fire, Water)**
to make the ibex progress safely in the environnment.

The 4 elements are primary elements but there are also secondary elements at play:

- The **Volcano** (creates fire)
- The **Source** (drops water)
- The **Forest** (created by Earth and Water)
- The **Wind** (left wind and right wind is created randomly in Air)


All elements interact with each other and **the ibex also react to elements in different ways**.

- Earth is a platform for the ibex
- Fire scares the ibex
- Water attracts the ibex
- Forest makes the ibex running faster

## The Controls

SPACE to draw an element, ARROWS to move, W/Z + X + C + V to switch between Air + Earth + Fire + Water.

Keyboard is recommended but playing only with mouse is also possible (click on elements and DRAG the inner cursor).


## Some technical notes

This game uses a [cellular automaton][cellular] to simulate a world with different elements (Air, Earth, Fire, Water).
This cellular automaton is technically computed as a texture in the GPU through WebGL and a GLSL shader (`logic.frag`).

While I was writing this game [@42loops](https://twitter.com/42loops) made me buy this awesome book that I'm still reading:

<blockquote class="twitter-tweet" lang="fr"><p><a href="http://t.co/8SiMZ9PWDX">pic.twitter.com/8SiMZ9PWDX</a></p>&mdash; Gaëtan Renaudeau (@greweb) <a href="https://twitter.com/greweb/status/506862098597834752">2 Septembre 2014</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

You can interact with this world by drawing elements with a brush.

However, simulation is not enough to make a game so I mainly focused on the story and the gameplay:
On top of this simulation are living the ibex. They are managed in JavaScript and behaves with an AI.
The pixels collision and the ibex decisions (e.g; react on fire nearby) is based on querying the simulated world (stored in the GPU as a texture).

The rendering of the game is also performed in WebGL through another shader (`render.frag`).
My source code is [on Github][github].

**I will try to write a technical post-mortem to explain you more of this 
and also what went wrong and what could have been more efficient in my usage of WebGL.**

## Bonus

During my early development, I've experimented the fire propagation in deep forest:

<iframe width="480" height="440" src="//www.youtube.com/embed/YU_pYAauFo4" frameborder="0" allowfullscreen></iframe>

IBEX is a game made in 13k of JavaScript code made for the js13kgames one-month contest.

IBEX, my js13k game

[ludumdare]: http://ludumdare.com/compo/
[play]: http://greweb.me/ld29/
[source]: //github.com/gre/ld29/
[entry]: http://www.ludumdare.com/compo/ludum-dare-29/?action=preview&uid=18803
[sunvox]: http://www.warmplace.ru/soft/sunvox/
[wrong]: /2014/05/ld29/#wrong
[right]: /2014/05/ld29/#right

<img class="thumbnail-left" src="/images/2014/05/computer_preset.jpg" alt="">

I **gamejam-ed** last weekend to the [Ludum Dare][ludumdare] 
theming *"Beneath the Surface"* (29th edition).

I enjoyed that time a lot.
What changed from the previous Ludum Dare for me is that 
**I'm now** —and happy to be— **a father**,
and I'm enough trained to wake up at 3am so I could be there attending the beginning!

This article is my diary of this incredible 48 hours past to
develop **"Anthill", a minimalist anthill simulation game**.
This postmortem will explain what [went right][right] and what [went wrong][wrong]
for this compo.


The Game
===

I haven't played any Ant Simulation Game 
but I recently played a lot ["Banished"](http://www.shiningrocksoftware.com/),
an awesome city-building strategy game,
and I was inspired by the "assign jobs to people" gameplay of this game.

- **[Play the Game][play]**
- [Ludum Dare entry][entry]
- [Source code][source]

<iframe width="640" height="360" src="http://www.youtube.com/embed/DBt-5Qmzu1k?feature=player_embedded" frameborder="0" allowfullscreen></iframe>

Timelapse
===

Developing a complete game in 48 hours (including sleeping) is tough,
especially that it is also about making the graphics and the music!

The game resulting of these 2 days is more a **prototype** than a finished game:
the simulation remains minimalist and fastly boring,
the food is the only resource you have to care about.


Here is a **300x accelerated screencast of the developement of "Anthill"**:
<iframe width="640" height="360" src="http://www.youtube.com/embed/VhH7of4gAHk?feature=player_embedded" frameborder="0" allowfullscreen></iframe>



<a name=right></a> What went right
---

### Music

Best achievement of my LD entry was –to me– **making the music**.

<img class="thumbnail-left" src="/images/2014/05/music_preset.jpg" alt="">

I'm not a musician, neither a pianist, but I played a lot with [Audio](/tags/audio/) the past year and I've managed to make a music for this game —and had a lot of fun making it.
I've used my *Yamaha P105* as a MIDI controller for making the game music and connecting it 
to [SunVox][sunvox], a modular tracker software.

#### Play the music - feedback appreciated

<iframe width="100%" height="450" scrolling="no" frameborder="no" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/playlists/32426683&amp;auto_play=false&amp;hide_related=false&amp;visual=true"></iframe>

<img class="thumbnail-right" src="/images/2014/05/playing_midi.png" alt="">

Most of the notes you heard have been **recorded live from my hand**, and I was quite proud of that, because I'm quite a noob on a piano.
Doing that way, you keep some imperfection in the music (little delay on the notes, especially in the intro music) and I think that sometimes makes the music better.

I've talked a few times about SunVox, also [I still want to make my own web version](/2013/07/zound-live/) 
of a **modular audio tracker** that anyone (first myself!) could use 
and also could embed live in the game (and, for instance, having game variable impacting the audio experience).

### Graphics

Also, I'm more a developer than a graphist so I would say this was a success^^

<blockquote class="twitter-tweet" lang="fr"><p>My best <a href="https://twitter.com/search?q=%23gamedev&amp;src=hash">#gamedev</a> graphics ever! <a href="http://t.co/FksRoq1r9x">pic.twitter.com/FksRoq1r9x</a></p>&mdash; Gaëtan Renaudeau (@greweb) <a href="https://twitter.com/greweb/statuses/460558902812086272">27 Avril 2014</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

### Using a library

I've entirely **focused on making my game** rather than making the technical stack.
Usually, I tend to develop my own framework with the game.
It is good to learn and discover some [cool ways of programming a game](/2014/01/promisify-your-games/)
but this time I really wanted to get things done...

### Phaser.io

...so I've used **[Phaser](http://www.phaser.io/)** which is a trendy and awesome framework.
It is also built on top of the **Pixi.js** rendering library (I used in [LD27](http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=18803)) and **p2.js** physics engine,
which are two brillant and performant JavaScript libraries.

Hopefully I started my project with a "Phaser template" I bootstraped during the previous warmup weekend.
I've still lost some time playing with the Phaser API but I could have relied on Phaser features and performance so I think it worth it the second day.

### Google Hangout with Ludum Dare friends

I used Google Hangout during the whole Ludum Dare, as a way to put my webcam in the timelapse, 
but more importantly to have other Ludum Dare friends coming in it!

This was a cool first experiment as an alternative to the "stream my dev" approach.
It was quite fun and social to have [@mrspeaker](http://twitter.com/mrspeaker)
showing me his crazy Metal Meter game advancement.

![](/images/2014/05/hangout.png)

<a name=wrong></a> What went wrong
---

### Achievability 
**My [initial plan](https://github.com/gre/ld29/blob/master/TODO.md) was too ambitious.**
It seems to always happen with me: I get the first day a lot of ideas and motivation, and I tend to underestimate the work to be done. Then at the end of the first day, I'm frustrated to find out I won't have enough time to do all my plans.
Indeed it is good to have a lot of ideas but, next Ludum Dare, I'll try to be sure to have achievable goals.

> Next time, let's **remove half the features** I establish!

So, the second day morning, I've been replanning from scratch and reprioritize my features to basically have something finished and working as a game.
Because of this decision, the result you can see is a game, but far from the one I originally wanted. 
**This version is only about digging, collecting mushrooms and avoiding stravation**.

Also I originally scheduled to work that way **Day 1: developing-only, Day 2: music and graphics + new features**. I'm not sure this approach can really works, especially it doesn't scale, we better work by adding complete features one after the other. That theorically works, but it is however difficult to apply in practice with the stress of the Ludum Dare countdown!

### Path finding performance

**Implementing my own path finding algorithm was fast but not optimal** at all because of performances!
I recently released a bugfixed version which just use an existing [path finding library](http://qiao.github.io/PathFinding.js/visual/) to fix my bad implementation 
and also to avoid an ant to request path finding each frame when looking for a task to be affected on.

### Finding the good simulation parameters

I underestimated a bit the amount of work needed to find the good parameters of the simulation.
Those are very important to **make the game well-balanced** (e.g. not impossible but also not super-easy), I don't think I found the optimal parameter in the released version.

I think I need two important things to make this parameter search easier:

- a framework to maintain parameters presets and change them live.
- make the simulation running at any speed to ease the development. (faster simulation)

### [bug] A task is not always completed by the closest ant

There is a inconvenient **proximity bug** in my game that you may have noticed:
when a new job is created, it may happen that, even if a ant was here nearby, a very far ant is assigned to this job.

I'm using a `foreach ant in noJobAnts { findAntTask(ant,availableTasks) }` loop.
In this first approach, even if a ant will take the closest task in `findAntTask`, the first assigned ant will occupy the task even if a closer ant was after in the noJobAnts list.

Another approach to solve this issue would be to do `foreach task in availableTasks { findTaskAnts(task,noJobAnts) }`.
In this second approach, the `findTaskAnts` should sort the noJobAnts list for the given task proximity.

However it is not that trivial because tasks also have different priorities for a given ant, and `findAntTask` solved that.
In my original plan, there is some basic tasks like "clean the dirt" or "clean the corpse" which can be done by any ant. However, a specialized ant (let's say an Harvester) may have some more important tasks to be done first, so this is why we need this priority.

In other word, fixing this bug is not trivial and I need to find the optimal loop for that!

To be continued...
---

I really wish to continue this game because I enjoyed making it and I would enjoy playing the one I have in mind! 
Time will tell if I can accomplish that wish!

![](/images/2014/05/anthill.png)

You can make games!
---

I strongly think anyone a bit motivated and inspired can participate [Ludum Dare][ludumdare].

Whoever you are, you can make games!

- If you are a developer, you can develop games easily! But that's not enough, you will require graphics and music!
- If you are a graphist, you can make crazy beautiful games! There is tools to help you making the game without coding.
- If you are a game designer or story teller, you can make awesome games too! You could also just make a cool text adventure game?

<iframe width="640" height="480" src="//www.youtube.com/embed/PVbCECjxFds" frameborder="0" allowfullscreen></iframe>

I gamejam-ed last weekend to the Ludum Dare 29 theming "Beneath the Surface" to develop "Anthill", a minimalist anthill simulation game.

48 hours to prototype an Ant Sim Game

[demo]: http://js1k.com/2014-dragons/demo/1790
[source]: https://gist.github.com/gre/9504494
[jscrush]: http://www.iteral.com/jscrush/
[jscrush-npm]: https://github.com/gre/jscrush/
[demojs]: http://demojs.org/
[js1k]: http://js1k.com/
[p01]: http://www.p01.org/

[<img src="/images/2014/03/js1k.png" alt="" class="thumbnail-left" />][demo]

This article introduces my journey into the JS1K world
and a few tricks I've used for my entry ["Panzer Dragoon 1k"][demo] ([source][source]).

Welcome to the world of hacks, tricks and getting-things-done-at-any-price.
You will turn the worst JavaScript practices and ugliest JavaScript facts to your advantage.
Welcome to the world where coding the bad way is satisfying!

Panzer Dragoon 1k
---

- **[Play the JS1K entry][demo]**
- [Source Code][source]

Panzer Dragoon Original Game
---

<iframe width="640" height="480" src="//www.youtube.com/embed/peoRBj9U-jI" frameborder="0" allowfullscreen></iframe>



JS1K
===

**[JS1K][js1k]** is a competition where you have to make a demo (or a game, or anything)
in less than **1 kilobytes** of JavaScript: **less than 1024 characters of source code**.

To reach that goal you will need ideas, JS ninja tricks 
and most important: **patience and perseverance**!
But really, **anyone can participate**.

I recommend that you take a look at [js1k.com][js1k] and browse the existing entries.
There is awesome guys participating to this yearly event,
I had the chance to meet some of them at [DemoJS 2013][demojs] Paris event.
Also checkout [www.p01.org][p01] which contains some very good examples of crazy short demos.

Tools
---

But first things first: you need tools to minimize source code (it can simply be removing comments and spaces, minifiers, or it can be much more crazy tools like crushers).

Personally, I'm using:

```bash
cat source.js | uglifyjs -c unused=false | tee minified.js | jscrush > crushed.js && wc -c *.js
```

This small homemade command (to use in a npm script) results for my game in:

```
    1019 crushed.js
    1756 minified.js
    7241 source.js
```

If you are interested, I've made this toolkit available in a complete boilerplate 
that you can easily fork for your own usage: 
[https://gist.github.com/gre/9364718](https://gist.github.com/gre/9364718).

> **P.S.** [`jscrush`][jscrush-npm] is a npm module that you can directly use from the CLI 
but it is a port of the awesome [www.iteral.com/jscrush/][jscrush].

The beginning: Saving bytes
===

It quickly becomes frustrating to compete in JS1K
because you are basically trying to put a cow in a car (or an elephant if you are ambitious!).
But this frustration actually becomes addictive!

**Saving bytes** is your job - once you get your first working prototype, and inevitably blow your byte limit.

When you reach that limit, a good idea is to practice an **"add feature -> remove code"** development loop 
that really makes you think hard about your ultimate goal, and helps improve your entry.

> **The JS1K-based development:**
> Adding more and more features,
> figuring out how to fill everything in,
> re-thinking your demo to only keep the essential features.
> This will keep making your demo better.

You have to make a very hard choice: ***Which feature to remove?***
It is all about budget, not in term of money but in term of bytes!
A bit like in daily life: making choices with limited resources!

JSCrush
---

***JSCrush*** is a crazy tool you may want to use to go deeper in the bytes reducing.

It basically implements a compression algorithm which is based on substring occurences.
The challenge of such a tool is not only to make a good compression but to make 
a very small decompressor embedded in the result code because 
this decompressor might be an overhead *(~ +60 bytes with small code)*.

If you are using *JSCrush* which I recommend for saving extra bytes,
you may want to use some tricks to go even further with it!

The first time, you usually can save about 20% of bytes with classic 1k minified code.
But if you optimize your code **for** *JSCrush*, you can save much more!
I've achieved about a 40% code reduction in my demo!

Most of the tricks is about finding code patterns (same succession of JavaScript source code characters) 
and trying to duplicate them.

When I say **duplicating code**, it is really about **DUPLICATING code!**

> Once "indexed", a duplicated code is likely to just take one more byte in the final crushed JavaScript!

Some tips and tricks
===

[<img src="/images/2014/03/js1k_2.png" alt="" class="thumbnail-right" />][demo]

This section will share with you a non-exhaustive list of tricks.
I'm not going to talk so much about the basic and classic ones, 
but a few novel ones that I found to work well in my entry.
You may prefer to directly read the [annotated source code of "Panzer Dragoon 1K"][source] instead!
Of course, most of those tricks work closely with the `| minify | jscrush` transformation.

> Careful! Some tricks might be counter-intuitive as first glance, 
> again it ties-in with the way JSCrush is working.

Reduce your language
---

All existing functions and properties are costly in bytes,
each time you use another one, it definitely add bytes.
To save bytes, you have to limit your set of functions/properties to use
or find ways to access them indirectly.

  - **Use as few variables as you can**: this is valid in computer science in general: the best systems are those with the fewest possible variables (states). if one variable can be computed out of others, it should be removed. Also consider allocating some temporary variables to re-use like in an assembly registry (e.g. `i`, `j`).
  - **Reduce the set of functions** you authorize yourself to use! You may just need to use "fillRect" for everything, or "arc". Also don't use both `Math.min` and `Math.max`, one can be implemented with the other.
  - **Minimize the different values / colors** you are using (most of the time digits are fine, but `#RGB` colors are costy).

Duplicated wins!
---

- Generally: try to **duplicate the exact same code everywhere**!

- **Do not use explicit aliasing** like `M=Math` and `C=M.cos`, JSCrush does that job for you.
- **Get rid of intermediary computation.** Prefer inline and duplicated computation over variable assigment.
- Also, `a*(b+c)` might be more bytes than `a*b+a*c` if `a` is an expression. (but doesn't work in all cases)

**A few examples:**

```javascript
a = b+c; translate(a, a); // NOPE!
translate(b+c, b+c); // YES!
```

```javascript
size = a+b+10; fillRect(x-size, y-size, 2*size, 2*size); // no please don't!
fillRect(x-(a+b+10), y-(a+b+10), 2*(a+b+10), 2*(a+b+10)); // YEAH!
```

```javascript
fillRect(10,10,20,20);
...
fillRect(9,9,18,18); // Can you afford to use 10,10,20,20 instead?
```

In my demo, I was able to factorize some code. For instance the way I draw and update the x,y of my opponents and particles are the same duplicate chunk of code:

```javascript
    bga();
    arc(
      // Update
      e[0] += e[3],
      e[1] += e[4],
      e[2],
      0, 9);
    fl();
```

- You sometimes can **save bytes by adding more code**! For instance, if you need `fillStyle` and `strokeStyle`, it may save bytes to always set both color at the same time! `fillStyle = strokeStyle = ...` even if you only need once.
- Always **use the same `function parameters`**. In my game, I use `function(e){` everywhere even if I don't use that `e` in all my functions. This is saving a bunch of bytes with JSCrush.
- **Here's a particularly crazy trick:** If you have different collections of complex objects, you can simply represent each item by a vector (an array) and figure out how you can make use the same indexes for the use-case.

In my game:

```javascript
o = []; // an opponent: [ 0: x, 1: y, 2: health, 3: vx, 4: vy, 5: locked, 6: hitTime ]
p = []; // a particule: [ 0: x, 1: y, 2: size,   3: vx, 4: vy, 5: damage ]
```

- You also may find better way of managing collections. Instead of using `t.push(o)` to add, `t.splice(i, 1)` to remove, and `for(i=0;e=o[i];i++){...}` to iterate. I am using `t[Math.random()]=o` to add, `delete t[i]` to remove and `for(i in o){ e=o[i]; ... }` to iterate. It saved a lot of bytes if you already use `Math.random()` somewhere else! For-in loops are also quite short and can by used for other tricks (e.g. *Programmatical aliasing*).

<blockquote class="twitter-tweet" lang="fr"><p>My <a href="https://twitter.com/search?q=%23js1k&amp;src=hash">#js1k</a> uses `t[Math.random()]=insert`, for-in loops and `delete t[i]` rather than push and splice. Saving bytes with jscrush</p>&mdash; Gaëtan Renaudeau (@greweb) <a href="https://twitter.com/greweb/statuses/439324052403277824">28 Février 2014</a></blockquote>


- Use just **one letter variable names** (mangling variables won't work because they are in window scope, and IMHO it is better for you to write them by hand)
- You will probably need to **initialize some variables**, but do it only if necessary (if you have `ReferenceError`) and **use the multi-assignment syntax**: `A = B = 0` if you can. You should never have constant variables, it saves bytes to directly use the value inline.
- **`with(c){ ... }`** in your main loop may save bytes. It makes all functions and properties of c (the drawing context) in the scope.

Language tricks
---
- **Never use `var`**, just put everything in `window`
- **Programmatically aliasing `c`'s method** may save you a lot of bytes (or may not, you have to check!). You also have to find the code which suit the best your use case. Be careful about collision. Here is mine: `for (e in c) c[e[0]+e[2]+(e[6]||"")] = c[e];`
- Do not waste ANY value returned by assignment and operators (i++, x=.., x+=...). I'm sure you can do it somewhere else!
Typical example:

```javascript
x += vx; y += vy; /* ... */ fillRect(x, y, s, s); // NOPE!
/* ... */ fillRect(x += vx, y += vy, s, s); // YES!
```

- Try to not separate update from drawing logic. Mixing them may save bytes.
- You don't want to use `addEventListener`, just define listeners straight on window! e.g. `onclick = function(){...`

Make your JS1K now!
---

[<img src="/images/2014/03/js1k_3.png" alt="" class="thumbnail-left" />][demo]

I'm really eager to see all JS1K entries 
because I usually enjoy reading people's code and 
especially all the crazy tricks that I can learn from your code :-)

This article was just sharing a bunch of tricks which work for my entry,
but you will find much better tricks for your demo -
so please do it and make your crazy work!


---
*Special thanks to [@mrspeaker](http://twitter.com/mrspeaker) for fixing my English*.

Panzer Dragoon 1k is a 2D remake of Panzer Dragoon in 1k of JavaScript I made for JS1K 2014

Panzer Dragoon 1k

[promise]: /2013/07/q-a-promise-library/
 [ld]: http://www.ludumdare.com/compo/
 [game]: http://greweb.me/ld28/
 [qimage]: https://npmjs.org/package/qimage
 [qajax]: https://npmjs.org/package/qajax
 [submission]: http://www.ludumdare.com/compo/ludum-dare-28/?action=preview&uid=18803
 [zanimo]: https://github.com/peutetre/Zanimo
 [npmjs]: https://npmjs.org/
 [github]: https://github.com/gre/ld28
 [app.js]: https://github.com/gre/ld28/tree/master/src/app.js

One month ago was the [LudumDare][ld] #28 gamejam theming *"You Only Get One"*.

<a href="http://greweb.me/ld28/">
  <img src="/images/2014/01/ld28.png" alt="" class="thumbnail-left" />
</a>

I [submitted][submission] a [mini-game][game] which ranked 105th out of 2064 entries and also 26th in the "theme" category.

This is of-course a web game implemented in JavaScript and using HTML and CSS.

But actually, my main goal was not really making a game done 
but more about technically **making a state-of-the-art Promise-based game**.

I think [Promises][promise] contains very interesting advantages in a game development design:
*Resource loading managment*, *game scenes chaining*, *animations*... are some use-cases.


* Checkout the [source code][github] on Github - [`src/app.js`][app.js] is the entry point
* LudumDare entry is [here][submission].
* [Play the Game][game].




## FP in game development

Using some Functional Programming paradigm in game development is interesting,
and here I'm just talking at least about the basic stuff:
**Avoid globals, Minimize state variables**.

I've written a few games where restarting the game without using `location.reload()` was a challenge
because the game variable states was so spread everywhere!

By doing more FP, you can have this restart feature by design without need to "reset" all variables
because your start function just takes everything it needs in parameter and restarting is just about re-calling that function.

## Promises as first-class citizen

### Game scenes chaining

Like maybe 99% of games, my game has an **intro** (menu), a **main** scene and an **outro** scene (gameover / finish).

When you develop a game with just one big `render()` loop,
it easily becomes a pain when you want to add more steps to the scene,
it doesn't scale and fastly become spaghetti code:
you tend to have to figure out in which state you are (or which part of the animation timeline) from the game state.

Hopefully, scene management is very easy to do with Promises:

```javascript
function start () {
  return Q()
    .then(intro)
    .then(_.partial(runMiniGames, 20))
    .then(outro);
}

Q.all([/*..something to load..*/])
 .then(start/*, ..*/) // start game when ready
 .done(); // just help Q to trigger errors if some.
```

How beautiful to read! Call `intro` then run 20 mini-games then perform `outro`.

#### No game state shared, pure functions

**intro** is the menu screen where you can choose the game difficulty.
**outro** is the game end screen where the final score is displayed.
There is however **no global variables shared**, those are just passed from one function to another.

Let's look deeper in how it works:

* The `intro()` function just returns a Promise resolved when the user made a "difficulty" choice. That Promise actually contains the difficulty (0, 1 or 2).
* The `runMiniGames` function takes 2 parameters: the number of games and the difficulty. `_.partial(runMiniGames, 20)` is just an helper for making a 20 mini-games function which takes the difficulty in parameter. This difficulty is given by the previous Promise. The `runMiniGames` function returns a Promise of Score (integer).
* That score is then fed into the `outro(score)` function which displays this score to the user.

> **TL;DR.** This is just about plumbing 3 functions together!

Checkout also the [`runMiniGames` implementation](https://github.com/gre/ld28/blob/master/src/app.js#L24-L37).

#### Speed up the development

And you know what? It make development easier and faster because you can easily skip some part in any Promises chain:

```javascript
function start () {
  return Q(0)
    //.then(intro) // Directly jump to the games
    .then(_.partial(runMiniGames, 20))
    .then(outro);
}
```

I used that a lot and not only for this part, but for all part during the game development.


### Loading resources

Promises also help you to wait resources before starting the game.
You don't have to make yet another loading library, Promise already are ready for that, 
and you can also have proper error managment or even "progress" loading display (Q has Progress event in a Promise).

Each loading resource is a Promise and you can combine them all using `Q.all`.

Here is an example using [Qajax][qajax] and [Qimage][qimage].

```javascript
Q.all([
  Qajax("music.wav").then(mapToAudio),
  Qajax.getJSON("map.json"),
  Qimage("images/logo.png"),
  Qimage("images/textures.png")
]).spread(function (music, map, logo, textures) {
  
  // Start the game !

}, function (error) {

  // display proper error

}, function (progressEvent) {

  // maybe you want to display a loading progress bar 
  // with that third progress callback.

});
```

Here is a similar example:

```javascript
var musicPromise = Qajax("music.wav").then(mapToAudio);
var mapPromise = Qajax.getJSON("map.json");
var texturesPromise = Qimage("images/textures.png");
Q.all([ mapPromise, texturesPromise ]).spread(startGame, errorLoading);
// because maybe you don't want to wait the music for starting the game:
musicPromise.then(function (a) { a.play(); });

function startGame (map, textures) {
  // ...
}
function errorLoading (e) {
  // ...
}
```

### Mini games workflow

My games is divided into a set of mini-games which are all independent but share a common interface.
This interface was quite a WIP at the end of the weekend development but it does the job.

Here is the template I used for my game: [src/games/\_template.js](https://github.com/gre/ld28/blob/master/src/games/_template.js).

A Game instance has different methods, and especially `enter` and `leave` method which are call on game enter and on game leave. It also has a `.end` Promise which is resolved when the Game end.

* A mini-game when solved gives a score depending on how well the user succeed it (through the `end` Promise).
* A mini-game have a timeout and if the player doesn't terminate it, it passes to the next game without scores.

Those `enter()` and `leave()` methods return Promise in order to be plugged in the game workflow (we can wait them to finish before moving to next state).

For instance, we don't start the game timeout before it actually starts (just wait the `enter()` Promise to be resolved) and also we don't switch to the next game before the `leave()` Promise is done).

Checkout also the [`nextMiniGame` implementation](https://github.com/gre/ld28/blob/master/src/app.js#L51-L76).
The result of that function is the score of the mini-game and that we sum up all scores from the previous score.

#### Composability

The `enter()` and `leave()` methods can be composed of animations which can themselves be composed of animations.

**We can easily subdivided work into different level of Promises chain.**
Here is a little schema to summary that composability:

![](/images/2014/01/ld28_composition_schema.svg)

### Promise Animations

In my game, all the animations are controlled with Promises more exactly using CSS3 Transitions 
via **[Zanimo][zanimo] Promise library** because it fits my game (DOM-based game).
The fact that a Promise can be waited and chained **gives a powerful controls over CSS Transitions for making animations**.

You can easily trigger animations **one after another** for moving an element in multiple places.
You can also perform **multiple animations at the same times** (on 2 different elements) and **wait for both to finish**
before triggering a third animation.

See for instance how `enter()` and `leave()` animations are done in mini-games.

In the animation ending the "memo" game I used concurrent animations:
all memo cards are randomly moved out.

```javascript
/* // FYI
Card.prototype.transform = function (x, y, scale, duration) {
  return Zanimo.transition(this.el, "transform",
    "translate("+x+"px, "+y+"px) scale("+scale+")", duration||0);
};
*/

function animateOut (dispersion) {
  return Q.all(_.map(cards, function (card) {
    if (card.destroyed) return Q(); // no animation because card is destroyed
    return Q()
      .then(function(){
        return card.transform(card.x, card.y, card.number === 1 ? 1 : 0.8, 100);
      })
      .delay(Math.floor((card.number===1 ? 500 : 0)+300*Math.random()))
      .then(function () {
        var x = Math.round((Math.random()<0.5 ? -card.w/dimensions.width-dispersion*Math.random() : 1+dispersion*Math.random())*dimensions.width);
        var y = Math.round((Math.random()<0.5 ? -card.h/dimensions.height-dispersion*Math.random() : 1+dispersion*Math.random())*dimensions.height);
        return card.transform(x, y, 0, 500);
      });
  }));
}

// Usage in Memo.leave() :
return Q.delay(50)
  .then(function(){ return animateOut(0.5); })
  .delay(100);
```


In the calculation game I used a chain of animations subdivided in functions:

```javascript
return Q.delay(50)
  .then(fadeOutInvalids)
  .then(displaySolution)
  .then(displayEquality)
  .delay(500)
  .then(fadeOut)
  .then(hideEquality)
  .delay(200);
```

[Full code here](https://github.com/gre/ld28/blob/master/src/games/calculation.js#L411-L500).

### "Wait for next click"

While my game are just based on click user interaction,
I've made a [`waitNextClick`](https://github.com/gre/ld28/blob/master/src/waitNextClick.js) function
which returns a Promise of click for the given element.

```javascript
var Q = require("q");

module.exports = function waitNextClick (btn) {
  var d = Q.defer();
  btn.addEventListener("click", function listener (e) {
    btn.removeEventListener("click", listener);
    d.resolve(e.target);
  }, false);
  return d.promise;
};
```

This was quite an interesting solution which is just like a jQuery "once" event but in Promise paradigm.

I was able to combine that function with `Q.race` which wait for one of the given Promise to be redeemed.

> `Q.race(_.map(btns, waitNextClick))`

For instance in the cats game, I just wait the first "This one" button to be clicked:

```javascript
var houseChoice = Q.race(_.map(this.houses, function (catHouse) {
    return waitNextClick(catHouse.btn)
    .then(function () {
      return catHouse;
    });
// houseChoice is a Promise of House choosen by the player.
```

### Using the "progress" event

I also used a bit the "progress" event of a Q Promise, which is a way to notify that a Promise is being resolved.

* I used that "progress" event on the `game.end` Promise for notifying that the player is winning some scores in a mini-game while playing.
* I also used it to make a timeout ticking the remaining time before the timeout is reached and that Promise resolved.

See both usages [here](https://github.com/gre/ld28/blob/master/src/app.js#L62-L70):

```javascript
return Q.race([
  gameEnd
    .progress(function (score) {
      stats.setScore(totalScore+score);
    }),
  timeoutWithTicks(gameEnd, timeout)
    .progress(stats.setTimeProgress)
    .then(_.bind(game.submit, game))
]);
```

## Code organization using NPM + Browserify

NPM & Browserify has also been used because I find this stack very productive,
especially when writing a game from scratch.

Browserify has been trendy the last past year, but there is here an interesting way of organizing your code
and especially reusing it.
You can find a lot of [available modules using NPM][npmjs], 
Browserify will just make you able to require them using `require("modulename")`.

a game showcase using Q Promise as first-class citizen and driven with CSS3 Animations via Zanimo.

Promisify your games


[Gamelier]: http://gamelier.org/gaetan-renaudeau-on-procedural-vs-functional-rendering/
[slides]: http://greweb.me/prez-functional-rendering

I've done a talk at **[Gamelier][Gamelier]** last Monday about 
how to think the **rendering** in a more **functional** way.

## Abstract

Most of today 2D graphics libraries restrict us to a set of primitive procedures (`drawRect`, `drawCircle`, `drawImage`,...) but when it comes to bring more interesting features you tends to be stuck with it. Let's see how we can just do things with a function of `(Vec2 => Color)`.

This is the way (*WebGL*) **GLSL** has already took and the presentation examples will be built on it.
Let's see what are the multiple benefits of taking that paradigm of rendering.

## Talk

<iframe src="//player.vimeo.com/video/78804695?title=0&amp;byline=0&amp;portrait=0" width="600" height="337" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>

### [Open the slides][slides]

## Checkout more presentations at Gamelier.org

[![](/images/2013/11/gamelier.png)][Gamelier]


This talk explains how to think the rendering in a more functional way. Let's see how we can just do things with a function of (Vec2 => Color).

Functional Rendering


<a href="http://greweb.me/webaudioapi-introduction">
<img src="/images/2013/09/webaudioapiprez.png" alt="" class="thumbnail-left" />
</a>

<a href="http://greweb.me/webaudioapi-introduction">Open the presentation</a>
/
<a href="http://greweb.me/webaudioapi-introduction?azerty=1">AZERTY version</a>


A presentation overview of the Web Audio API

Slides: Web Audio API, Overview

While continuing to experiment with Web Audio API and GLSL, I've made a game called Timelapse for js13kgames (an HTML5 game competition where entries must be less than 13 kb zipped).

Making a rhythm game with bleeding-edge web

[webaudioapi]: https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html
[zenexity]: http://zenexity.com
[github]: http://github.com/gre/beez
[app]: http://beez.greweb.fr/
[webrtc]: http://www.webrtc.org/
[webrtcapi]: http://www.w3.org/TR/webrtc/
[websocketapi]: http://www.w3.org/TR/websockets/
[fm_article]: /2013/08/FM-audio-api
[playframework]: http://playframework.com/

<img src="/images/2013/09/beez.png" alt="" class="thumbnail-left" />

Here is **Beez**, a web real-time audio experiment 
using smartphones as synthesizer effect controllers.

This is our second [Web Audio API][webaudioapi] experiment made in one Hackday at [Zenexity][zenexity] (now Zengularity).

This time, we were much more focused on having the best **latency performance**:
we used the bleeding-edge [WebRTC][webrtcapi] technology,
which allows you to link clients in Peer-to-Peer instead of a classical Client-Server architecture.

* [The project on Github][github]
* [Test it now!][app] (Chrome)


### Live demo of the Hackday application

<iframe width="640" height="480" src="//www.youtube.com/embed/QwU6IMNLF0o" frameborder="0" allowfullscreen></iframe>

*Bonus for the one who recognizes the melody :-)*



## The Experiment

The experiment consists in controlling an audio stream running on a desktop web page with 
some audio effect pads running on phones via a mobile web interface.
**Our main goal was to make the best real-time experience.**

### Hive and Bees

An **Hive** is controlled by different **Bees**, eventhing connected in Peer-to-Peer (via WebRTC).

#### The Hive

The **Hive** is a web page where the sound is generated and visualized *(Web Audio API)*.
It also shows you in real-time the different effects XY pads and allows you to control them.

![](/images/2013/09/hive.png)

#### A Bee

The **Bee** is a mobile web page which allows you to control the different sound effects with XY pads.
It only works on Android Chrome now *(WebRTC required)*.

![](/images/2013/09/bee.png)

### Audio tech

We used [Web Audio API][webaudioapi] for generating the sound client-side on the Hive:

We have a note sequencer which plays a ***famous melody*** through a [Frequency Modulator][fm_article] and different other effects.
Some controls allow you to change the **BPM**, **gain** of the carrier and the modulator, **finetune**, 
frequency **multiplicator** (0.25, 0.5, 1, 1.5, 2) of the carrier and the modulator,
**reverbation**, **filter** (frequency and resonance).
There is also a delay effect made on both left and right channels to produce a cool stereo effect.

That's quite basic audio stuff so far, I can't wait to experiment deeper and try to generate more complex sounds with that awesome Audio API.
Again, our main goal was to make a P2P connection between the hive and its bees.

### Network architecture

<img src="/images/2013/09/beez_arch.png" alt="" class="thumbnail-left" />
**Every bee are connected to the hive with a bi-directionnal Peer-to-Peer connection thanks to [WebRTC][webrtc].**

Everytime a (bee) user moves an effect controller with his phone, a position event is sent to the hive.

Basically:

```javascript
xyAxis.on("change:x change:y", function () {
  hive.send(["tabxy", this.get("tab"), this.get("x"), this.get("y")]);
});
```

*As you can see, we used Backbone.js models for events.*

However, A lot of Touch events per second can be triggered by an Android device, and it may depends on the device speed. We shouldn't send to the network all of these events because it can saturate it and cause some lags. To avoid that we need to **throttle the touch events before sending the event to the network**.

This is done transparently with the [`_.throttle`](http://underscorejs.org/#throttle) function and we choose to **throttle by 50 milliseconds** which is **about 20 events per second** which is ok for human eye.

```javascript
xyAxis.on("change:x change:y", _.throttle(function () {
  hive.send(["tabxy", this.get("tab"), this.get("x"), this.get("y")]);
}, 50));
```

We use different other events:

- A bee can send `"tabxychanging"` and `"tabopen"` respectively to informs the cursor has been pressed/released and to inform a new tab has been opened.
- When a Hive receive a `"tabopen"`, it will send back to the bee a `"tabxy"` event in order to inform what is the current value of that tab so we can init the cursor to the current xy axis position on the bee interface.

## WebSockets vs WebRTC

<img src="/images/2013/09/websocket.png" class="thumbnail-left" />

Most "real-time" web experiments you see on the Internet today use [WebSockets][websocketapi].
WebSockets are good, it's a significant evolution from the Ajax years.

WebSocket is a protocol on top of TCP, which **links a browser with a server in a bidirectional text communication**.
Getting 2 clients to communicate generally consists in broadcasting messages from the server to all clients 
(see the schema).

**This architecture has some advantages:**

* Simple to understand, Easy to use.
* We can easily implement some server validation.

**But also has some drawbacks:**

* Not always easy to traverse **proxies**. *(e.g. through an nginx front server)*
* Only text communication.
* **bandwith** intensive. *(all the bandwidth goes back and forth with your server)*
* **CPU** intensive. *(e.g. receiving 20 messages per second from 10 clients can be a lot for a small server, especially if you are doing some message processing)*

(The last two "cons" are scalability issues)

<hr style="clear:both" />

<img src="https://upload.wikimedia.org/wikipedia/commons/a/ac/Logo-webrtc.png" class="thumbnail-left" />

[WebRTC][webrtc] (*Web Real Time Communication*), 
is a new web technology which helps to connect browsers in a **Peer to Peer** way.

WebRTC has been designed for transfering binary data like files, audio, video (e.g. a webcam stream).
Of-course, we can still use it for text.

<br style="clear:both" />

<img src="/images/2013/09/webrtc.png" class="thumbnail-right" />

Unlike WebSockets, multiple steps are required to **establish a P2P connection between two web clients**.
It is due to the fact that the two clients must resolve the closest network path to communicate with each other.
That resolving phase requires a communication between the clients, and for that we can use WebSockets as a *"Control Channel"*.

But once the two web clients are connected, they basically don't need the web server anymore and can **communicate directly together**.
If the two clients are in the same local network, they should directly communicate through that local network.
That **reduces the server load** and should significantly **decrease the latency**.

### Playframework / Akka Actors

[Playframework][playframework] has been used on the server side for making that WebSocket Control Channel,
and akka was convenient for handling peer communication and rooms management.

## About the melody

You still didn't guess where does the melody came from?

Well, here is the answer:

<iframe width="640" height="480" src="//www.youtube.com/embed/3rU_ei_x0Ag" frameborder="0" allowfullscreen></iframe>

## Awesome team!

Finally I want to thanks my team-mates: [@mrspeaker](http://twitter.com/mrspeaker), [@etaty](http://twitter.com/etaty), [@NicuPrinFum](http://twitter.com/NicuPrinFum), [@drfars](http://twitter.com/drfars), [@srenaultcontact](http://twitter.com/srenaultcontact)
with who we were able to make that demo from scratch in one day!

Here is Beez, a web real-time audio experiment using smartphones as synthesizer effect controllers. This is our second Web Audio API experiment made in one Hackday at Zenexity.

Beez, WebRTC + Audio API

[zoundarticle]: /2013/07/zound-live/
 [zoundrepo]: http://github.com/gre/zound-live/
 [zoundfm]: https://github.com/gre/zound-live/blob/master/app/assets/javascripts/modules/SimpleFM.js
 [fmwiki]: http://en.wikipedia.org/wiki/Frequency_modulation_synthesis

The main principle of [Frequency Modulation (FM)][fmwiki] is to **pipe an Oscillator (the Modulator)
into the frequency of another Oscillator (the Carrier)**.

This article will explain to you how FM Synthesis works with **interactive demos**.
In the meantime, all demos are implemented with the brand new **Web Audio API**,
so feel free to hack the code for your own purpose.

This article will also introduce some Audio concepts like **LFO**, **Envelope** and **Finetuning**.

I've recently implemented a very first FM in [ZOUND live][zoundarticle] - *a HTML5 collaborative audio tracker*,
giving much more powerful Synthesizers (see in the following video).

<iframe width="640" height="480" src="//www.youtube.com/embed/El4JvaDWQUM" frameborder="0" allowfullscreen></iframe>
[*(here is the implementation of that FM)*][zoundfm]




## Dive into Frequency Modulation Synthesis

As mentioned previously, FM is about **piping an Oscillator (the <u>Modulator</u>) into the frequency of another Oscillator (the <u>Carrier</u>)**.

The Modulator oscillation only affects the oscillation frequency of the Carrier but is not directly an audio signal.

![](/images/2013/08/fm_principle.png)

The result of that modulation differs depending on each oscillator **frequency** and **amplitude**:

[![](/images/2013/08/Frequencymodulationdemo-td.png)](http://en.wikipedia.org/wiki/File:Frequencymodulationdemo-td.png)

***N.B.*** *Our interactive demos in this article will always play a sound and visualize it (waveform / spectrum analyzer).
You will have different kind of controls depending on each specific aspect I want to illustrate.*

*The demos should work on Chrome. __However if you get an AudioContext failure, please reload the page__ (you may not be able to start them all in one row).*

### LFO

**Low-Frequency Oscillation (LFO)** is very used in electronic music for making rythmic audio effects.

LFO is simply a specific subset of a oscillator in a sense that **its oscilation frequency is under
the human audible range (20 Hz)** and is then not generally used as an audio signal but as an effect controller.

For instance the frequency / the amplitude of an oscillator, or in the following example the frequency of the cut-off filter:

<audio src="http://upload.wikimedia.org/wikipedia/commons/e/e4/Lfo-cutoff-frequency-wobble-bass.ogg" controls></audio>

Now, as a first demo,
let's see what happens if our **FM Modulator is an LFO**,
*(i.e. if that Modulator is in low frequency range)*.

<iframe width="100%" height="310" src="http://fiddle.jshell.net/FvnJx/58/show/light/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<a href="http://jsfiddle.net/FvnJx/58/" target="_blank" style="display: block; text-align: right">Open on jsfiddle</a>

Observe in the Carrier graphs how **the waveform is regulary compressed and decompressed**. If you increase the Modulator frequency, it will speed up this effect. A real FM is about speeding up that effect up to the audible range...

***N.B.*** *With _Web Audio API_ (more generally with any modular synthesizers) we can easily control any module parameter with an LFO:*

```javascript
lfo.connect(carrier.frequency);
```

#### Modulator in audible range

Now, if we increase the frequency to the hearing range, here is what happens:
*(in that example you can also change the Carrier frequency)*

<iframe width="100%" height="310" src="http://fiddle.jshell.net/x4CWR/36/show/light/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<a href="http://jsfiddle.net/x4CWR/36/" target="_blank" style="display: block; text-align: right">Open on jsfiddle</a>


It's as if that **once the Modulator reaches that audible barrier, it kind of becomes a second audible synthesizer**,
even if it only modulate the frequency of the actual synthesizer.
However, it's completely different than playing the two synthesizers directly into the output,
again the modulator influence the frequency of the carrier and is not directly piped into the output audio signal.

*There is especially cool sound produced when the Modulator frequency is closed to the Carrier frequency. For more infos, see the <u>Finetuning</u> section.*


### Frequency ratios: harmonic or dissonant sounds

One thing you may also have notice in the previous example is that most of the generated sounds was quite dissonant, non harmonic.

Now, if we add more restrictions and only **snap the possible modulator frequencies**
to a **multiple of the carrier frequency**, here is what happens:

<iframe width="100%" height="310" src="http://fiddle.jshell.net/Euezv/17/show/light/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<a href="http://jsfiddle.net/Euezv/17/" target="_blank" style="display: block; text-align: right">Open on jsfiddle</a>

This harmonic result is due a simple fact in music: **Mutiplying a note frequency by 2 is equivalent to Increasing that note by one octave,** meaning the note has the same tone but is one-octave higher. (and vice versa for the division). *BTW, you may have noticed that fact by repetition of peaks in the previous example Spectrum Visualization.*

Now we can release some restrictions by also allowing frequencies multiple of `carrier frequency / 4`, which means allowing to increase/decrease by an **octave**, a **semi-octave** or a **quarter-of-octave**.

<iframe width="100%" height="310" src="http://fiddle.jshell.net/DFSwN/13/show/light/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<a href="http://jsfiddle.net/DFSwN/13/" target="_blank" style="display: block; text-align: right">Open on jsfiddle</a>


*Eventually you could even allow more freedom using multiple of `carrier freq / 12`, because an octave is equally divided by 12 in the [Chromatic scale](http://en.wikipedia.org/wiki/Chromatic_scale).*

### Mixing the power of the Modulator effect

A very interesting part of the job is also to change the **amplitude of the modulator**. So far, we used a full amplitude modulating the carrier frequency from 0 to 2-times its original frequency which produces a quite rough sound.

Try to change the modulator amplitude on the following demo:

<iframe width="100%" height="310" src="http://fiddle.jshell.net/DAT5S/12/show/light/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<a href="http://jsfiddle.net/DAT5S/12/" target="_blank" style="display: block; text-align: right">Open on jsfiddle</a>

Technically, we can easily control that range to any by changing the gain of the Modulator with a `GainNode` which is just a tool to scale the amplitude of a signal.

### Envelope

Now, we need to add an **Envelope** for automating that amplitude change you just experiment with.

An envelope in electronic music will generally look like this:

[![](/images/2013/08/500px-ADSR_parameter.svg.png)](http://en.wikipedia.org/wiki/File:ADSR_parameter.svg)

An Envelope corresponds to a **note lifespan**.
It is the minimum required for making our Synth.

We will generally **automate that amplitude through time for each note triggered**.

Here is a demo.
Play, try to hold and release a note (using the Play button or SPACE), and observe how the Spectrum Analyzer is moving:

<iframe width="100%" height="400" src="http://fiddle.jshell.net/tyEKr/32/show/light/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<a href="http://jsfiddle.net/tyEKr/32/" target="_blank" style="display: block; text-align: right">Open on jsfiddle</a>

**Two different envelopes** has been used: one for the **Modulator** and one for the **Carrier** which produce **different sound effects in a note lifespan**.

*We won't make an interactive demo for changing these envelope parameters,
but you can try them in the ZOUND project (or see again the video).*

### Finetuning

Another interesting effect occurs **when the frequency of the Modulator is very close to the frequency of the Carrier**.
In the following example, we have set both oscillators to the same frequency but we expose a "detune" parameter which allows to change a bit the frequency of the Modulator.

<iframe width="100%" height="400" src="http://fiddle.jshell.net/X95S6/10/show/light/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<a href="http://jsfiddle.net/X95S6/10/" target="_blank" style="display: block; text-align: right">Open on jsfiddle</a>

You can slightly notice that a sound is regulary looping like if it was an LFO effect. You can also visualize it on the graph.

This effect corresponds to the **[phase](http://tinyurl.com/nzkus8) change between both oscillators**: it regulary change from **"in-phase"** state (where it have exactly the same sine waveform at the same time) to a desynchronize **"out-of-phase"** (because of the small detune), and then slightly go to the next "in-phase" step. More the frequencies are close, more it takes time to oscillate from phase to phase.

This effect is especially awesome when you start mixing multiple synths together and finetune a bit each one so they don't sound exactly on the same frequency.

### Modulating the Modulator

There is so much more possibilites to play with,
for instance, the previously introduced Envelope could be mixed
with an LFO to change the Modulator effect in a rythm,
but now let's see how we can...

**...modulate the modulator!**

Eventually we can make a stack of modulators and use different kind of waveforms
for more powerful effects:

![](/images/2013/08/fm_multiple.png)

> Be careful when playing with stack of modulators, it is quite easy to have saturated or noisy sounds.

As an example, I made this experiment which randomly takes different frequencies and amplitude for a stack of 5 modulators:

[**-> http://jsfiddle.net/s2MMR/45/ <-**](http://jsfiddle.net/s2MMR/45/)

Careful! this experiment is a bit crazy! but it shows how different patterns can be when playing with FM.



----

Also, **If you are interested by ZOUND live, [fork it on Github][zoundrepo].**

Frequency Modulation (FM) with Web Audio API


Here is a preview video of the Work In Progress development of [ZOUND live](/2013/07/zound-live/),
the **collaborative modular audio tracker** built with bleeding edge **web technologies**: *Web Audio API, Web MIDI API, WebSocket & Playframework*.

<iframe width="640" height="480" src="//www.youtube.com/embed/621dpTK8OOc" frameborder="0" allowfullscreen></iframe>

<img src="/images/2013/07/nanokontrol.jpg" alt="" class="thumbnail-left" style="width: 150px">

**N.B.** In the video, I've used the nanoKONTROL2 for changing some properties in real time and using the MIDI API.

----

**If you are interested by the project, [fork it on Github](https://github.com/gre/zound-live).**

More to come, stay tuned!


Here is a preview video of the Work In Progress development of ZOUND live, the collaborative modular audio tracker built with bleeding edge web technologies: Web Audio API, Web MIDI API, WebSocket & Playframework.

ZOUND live v1 in development

[0]: /pages/a-world-of-promises/
 [1]: http://t.co/OeSukzxv3F
 [2]: http://github.com/42loops/Zanimo.js
 [3]: http://twitter.com/42loops
 [4]: http://github.com/kriskowal/q

# A [World Of Promises][0], episode 4

<img src="/images/2013/07/zanimo_animation_thumbnail.png" alt="" class="thumbnail-left" style="width: 200px" />

*This fourth article on [Q][1] will introduce [Zanimo.js][2], 
a Promisified animation library which helps to chain different
CSS transitions with only Promises.
It is very interoperable with any other Promise library,
meaning that you can easily chain Zanimo animations with other asynchronous actions.*

[Zanimo.js][2] is a smooth library developed by [@42loops][3] animation library based on the library [Q][4], a Javascript implementation of Promises.

This article is an introduction of the concept of Promises in Javascript with the library Q and will show a real use case of it: Promises used on top CSS Transitions to make powerful and efficient DOM animations in Javascript.



## Zanimo.js

TODO: overview of the library

## Examples

### Recursive tree particle animation

[![tree-particle](/images/2013/05/tree-particle.png)][1]

It turns out that promise is very good tool for animating any recursive things.

TODO

Zanimo.js, a promise-based animation library

Qep4.: Zanimo.js, a promise-based animation library

[zound]: /2012/08/zound-a-playframework-2-audio-streaming-experiment-using-iteratees/
[webmidiapi]: http://webaudio.github.io/web-midi-api/
[webaudioapi]: https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html
[tracker]: http://en.wikipedia.org/wiki/Tracker_(music_software)
[zenexity]: http://zenexity.com

<img src="/images/2013/07/nanokontrol.jpg" alt="" class="thumbnail-left" />

Last week, I initiated, with my [Zenexity][zenexity] Hackday team, **"ZOUND live"**
following the previous ["ZOUND"][zound] experiment but being much more ambitious this time:
using both the **Audio API**, the _new_ **MIDI API** and electronic music software experience,
we start our own **web collaborative audio modular tracker**.

### Live demo of the Hackday application

<iframe width="640" height="480" src="//www.youtube.com/embed/uyHWhCnE4L0" frameborder="0" allowfullscreen></iframe>



## Inspiration

A lot of features have been inspired from existing software like _SunVox_ or _Renoise_.
However, our version uses 100% web technologies and add collaborative and real time aspects.

<img src="/images/2013/07/sunvox.png" style="max-width: 300px" />

### Our Tracker

The application has a [tracker][tracker] where you can put notes.

<img src="/images/2013/07/tracker.png" style="max-width: 300px" />

### Our Audio modules

The application integrates a [modular music](http://en.wikipedia.org/wiki/Modular_software_music_studio) concepts.

<img src="/images/2013/07/nodeeditor.png" />

## The web techs

### About Web MIDI API

We bought a few **cheap MIDI controllers to interact with our application**.

<img src="/images/2013/07/midicontrollers.jpg" class="thumbnail-right" style="max-width: 250px" alt="" />

MIDI means _Musical Instrument Digital Interface_,
it is the **protocol** used by a lot of electronic musical instruments for a few decades.

The [Web MIDI API](webmidiapi) is a recent specification which makes MIDI devices accessible from a web page,
via a Javascript API.

Recently, _Chrome_ has started to [implement it](https://code.google.com/p/chromium/issues/detail?id=163795)
and it is available under _Chrome Canary_ (the dev version) via a _flag_ that you need to enable.

This is the perfect time to start experimenting it!

However, what I feared the most happened on the Hackday: **the MIDI API was broken on the morning
after a Chrome update during the night!** A first version of a browser MIDI permission was implemented
but I never succeeded to make it working. The state of the API seems to be still broken on Mac as of writing.

<blockquote class="twitter-tweet"><p><a href="https://twitter.com/greweb">@greweb</a> If you know how to build chromium, I may be able to provide a patch to enable it. But it isn't so long until Canary supports it.</p>&mdash; とよしま (@toyoshim) <a href="https://twitter.com/toyoshim/statuses/360685543778041857">July 26, 2013</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

Well, that was already too late for the Hackday,
Fortunately we fallbacked on an alternative which relies on a Java applet to access MIDI devices, it was a laggy polyfill though...

**Lesson learned:** a nightly feature is a nightly feature, never assume features you add via flags are stable _(I never did, but it was a Hackday afterall!)_.

BTW, cheers to <a href="https://twitter.com/toyoshim">@toyoshim</a> who is implementing the MIDI API in Chrome :-)

### Using Web Audio API

The [Web Audio API][webaudioapi] is _a high-level JavaScript API for processing and synthesizing audio in web applications_.

The good thing about this API: it is already an **modular audio API**, so it's not so hard to build a modular audio application on top of it!

### Playframework

[Playframework](http://playframework.com/) has been used for **broadcasting events
between clients via WebSocket and synchronize everything on the interface**.
It is only broadcasting and does not save the song yet.

### Backbone.js

[Backbonejs](backbonejs.org) was used for the **models**, **views** and its nice **event system**.
It was a good library for prototyping and architecture the different parts of the application.

I found Backbone.js especially good when linking all parts together and especially for the network logic.
This leads to a very reactive style of programming:

<script src="https://gist.github.com/gre/6107277.js"></script>

## The team

**This project has been started during our monthly Hackday at [Zenexity][zenexity],
I want to thank my 6 awesome coworkers for being part of the project:**

- [@mrspeaker](http://twitter.com/mrspeaker) for his awesome electronic music knowledge.
- [@bobylito](http://twitter.com/bobylito) for his brilliant ideas and his JavaScript skills.
- [@mandubian](http://twitter.com/mandubian) for his playframework experience and JSON superpower!
- [@etaty](http://twitter.com/etaty) for helping with the server synchronization.
- [@skaalf](http://twitter.com/skaalf) for his cool DrumBox module.
- [@Noxdzine](http://twitter.com/Noxdzine) for his talentuous design.

This was actually my first real project managment and it was quite cool!

**Hackday is only one day** and such an ambitious project is hard to achieve one in a row,
the project architecture needed to be a bit ready and having a PoC working before the Hackday. Also I wanted everyone to have fun by experimenting with the Audio API parts and not to be blocked on boring parts.

As a team manager, I also had to define goals to achieve for the Hackday.

Woo, I realize that's **not an easy task to manage a team when running out of time!**

But fortunately, I think we fulfilled it just in time!

We ended the Hackday with a **Real Time demonstration of our application** with 4 people interacting together
with MIDI controllers.

## More to come!

Today, we have a **first working version of a
collaborative tracker with basic modular audio features**:

- MIDI note support + MIDI control assignation allowing to change module properties.
- a unique tracker with a 32 lines loop and 23 tracks.
- Synchronisation of everything: the tracker and modules for all connected clients.
- off-mode allowing one user to prepare a track which is muted for other users.
- play/pause and record mode!
- cursor of users displayed on the tracker.

**Stay tuned because there is so much features to come!**

[**The project on Github**](http://github.com/gre/zound-live)

Last week, I initiated ZOUND live following my previous "ZOUND" experiment but being much more ambitious this time: using both the Audio API, the new MIDI API and electronic music software experience, we start our own web collaborative audio modular tracker.

ZOUND live project initiated

[0]: /pages/a-world-of-promises/
 [1]: http://github.com/gre/qanimationframe
 [2]: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html
 [3]: http://creativejs.com/resources/requestanimationframe/
 [4]: http://www.paulirish.com/2011/requestanimationframe-for-smart-animating/

# A [World Of Promises][0], episode 3

<img src="/images/2013/07/qanimationframe.jpg" alt="" class="thumbnail-left" style="width: 200px" />

*This third article on [Q][1] is a little parenthesis to the Qep articles series,
featuring the `requestAnimationFrame` Javascript function and its general usage,
and [QanimationFrame][1], its Promisified version used as a "wait for DOM to be ready" API.*



## `requestAnimationFrame`

`requestAnimationFrame` is a function which **delays a Javascript function execution to the next browser render frame**.
It takes one argument in parameters which is **the function to call on next repaint**.
*(N.B. there is not anymore a second DOM parameter like a few months ago, see the [spec][2])*

### ...for animation loop

`requestAnimationFrame` helps to easily make a **render loop**:

```javascript
(function loop(){
  requestAnimationFrame(loop);
  render();
}());
```
In that example, the `render` function can contains any Javascript code which updates
some graphics either using Canvas or DOM.

A good practice is to always **compute time-relative** animations and 
never assume the framerate to be constant.

```javascript
function badRenderFunction() {
 someObject.x += 0.1; // 10 pixels per 100 frame.
 // not so good with non-constant framerate
}
```

```javascript
var lastTime = Date.now();
function goodRenderFunction() {
 var now = Date.now();
 var delta = now-lastTime; // in milliseconds
 lastTime = now;
 someObject.x += 0.01 * delta; // 10 pixels per second
 // good because function of time
}
```

More information on `requestAnimationFrame` can be found [here][3] or [here][4].

### ...for waiting a DOM update

**We will now focus on another interesting benefit of that function:**

Instead of using `requestAnimationFrame` for a render loop,
**you can use it only once** in order to **wait for the next DOM update**.

There is a lot of use-cases where you need to wait for the next DOM update 
and `requestAnimationFrame` is perfect for that.

Most of the code you can see on the internet rely on using a `setTimeout` with an arbitrary time
given in second parameters *(sometimes 30, sometimes 0 !?)*.
This is, in my humble opinion, a wrong approach because you will never know if the repaint has 
really been performed.

## QanimationFrame

`QanimationFrame` is a function which takes a **DOM Element** in parameter and return a 
**Promise of that "ready" DOM element**.

**`QanimationFrame (elt: DOM Element) => Promise[DOM Element]`**

**N.B.:** Even if `requestAnimationFrame` doesn't have anymore a second *DOM element* parameter,
I found it quite cool that you can give it as argument and retrieve it back to manipulate it.
It also makes the function more composable because it behaves like an identity Promise function.
We will also see benefits when using with other DOM Promise libraries.

### Basic example

```javascript
var elt = document.createElement("div");
elt.innerHTML = "Hello world";
// wait for the DOM to be ready before using the height
QanimationFrame(elt).then(function (elt) {
  console.log("height="+elt.offsetHeight);
});
```

### Composability

```javascript
function createDivInBody (html) {
  var elt = document.createElement("div");
  elt.innerHTML = html;
  document.body.appendChild(elt);
  return elt;
}

var height = 
Q.fcall(createDivInBody, "Hello world!<br/>How are you today?")
 .then(QanimationFrame)
 .then(function (elt) {
   return elt.offsetHeight;
 });

height.then(function(height){
  console.log("height is "+height);
});
```

There is of-course a lot of more examples and use-cases of that library.

## Next episode

Next episode is a big one!

We will introduce you a Promisified animation library called **Zanimo.js** which
helps to chain different **CSS transitions with only Promises**.
It is very interoperable with any other Promise library,
meaning that you can easily chain Zanimo animations with other asynchronous actions.

This third article on Q is a little parenthesis to the Qep articles series, featuring the requestAnimationFrame Javascript function and its general usage, and QanimationFrame, its Promisified version used as a "wait for DOM to be ready" API.

Qep3.: QanimationFrame

[0]: /pages/a-world-of-promises/
[1]: http://github.com/kriskowal/q
[2]: http://github.com/gre/qimage
[3]: http://wiki.commonjs.org/wiki/Promises/A
[4]: http://dom.spec.whatwg.org/#promises
[5]: http://wiki.commonjs.org/wiki/Promises/B
[6]: http://wiki.commonjs.org/wiki/Promises/D
[7]: https://npmjs.org/package/qimage

# A [World Of Promises][0], episode 2

<img src="/images/2013/07/qimage_then_thumbnail.jpg" alt="" class="thumbnail-right" style="width: 200px" />

*This second article on [Q][1] will introduce you how to easily 
turn a callback API into a promise API using Deferred objects.
It will also present the new W3C specification of Promise and finish
with the implementation of [Qimage][2], a simple Image Promise wrapper.*



## Deferred objects

[Q][1] splits the concept of Promise in two parts: one part is the **Deferred object**, another is the **Promise object**.

A **Deferred object** is an object which just aims to control the state of a Promise.
It allows to do one of the two following actions (one time only):

* `.resolve(value)`: moving from *pending* to ***fulfilled* with a value**.
* `.reject(error)`: moving from *pending* to ***rejected* with an error**.

<img src="/images/2013/07/promise.png" style="max-width: 300px; width: 100%" />

A **Promise object** can be obtained from a Deferred object via the `promise` field.
In [Q][1], a Promise is **read-only**: you can basically only do `.then` with it 
and there is no such `resolve` or `reject` method on a Promise.

 > a Deferred is "resolvable", a Promise is "thenable".

***N.B.***: *this separation also exists in other languages but with different names (for instance in Scala: Promise / Future).*

### `Q.defer()`

The method Q.defer() will return a new **Deferred object** initialized in a *pending* state.

```javascript
var d = Q.defer();
setTimeout(function () {
  d.resolve(42);
}, 500);
var promise = d.promise;
// ...
promise.then(function (value) {
  console.log("the universe = "+value);
});
```

Note that the [Promises/A][3] spec only specifies the concept of **Promise**.
It does not defines the "Deferred" part.
Up to the Promise library to implement its own way of resolving / rejecting the value of a Promise.

There is also [Promises/B][5] and [Promises/D][6] to define that though.

### About the DOM.Promise specification

a [new DOM specification draft][4] has born recently and is a bit different from the Q style,
the "Deferred" object (called a **Resolver**) is given as an argument of the function given at Promise instanciation.

```javascript
var promise = new /*DOM.*/Promise(function (resolver) {
  setTimeout(function () {
    resolver.resolve(42);
  }, 500);
});
promise.then(function (value) {
  console.log("the universe = "+value);
});
```

## Qimage: Wrapping the Image API

We will now show you how to easily **wrap the DOM Image API into a Promise API with Q**.
Before showing the implementation, let's explore the possibilities of such API.

**`Qimage (url: String) => Promise[DOM Image]`**

Here is how we want our `Qimage` API to look like:

```javascript
var promise = Qimage("http://imagesource.com/image.png");
promise.then(function (image) {
  // image instanceof Image
}, function (error) {
  // error instanceof Error
});
```

We can use it like this:

```javascript
Qimage("images/foo.png").then(function (img) {
  document.body.appendChild(img);
}, function (error) {
  document.body.innerHTML = "Unable to load the image";
});
```

Now we define `Qimage` as a Promise library, **we can then use all the power of Promises,
combine Promises together, chain different Promise APIs**...

```javascript
Q.all([
  Qimage("res1.png"),
  Qimage("res2.png"),
  Qimage("res3.png")
])
.spread(function (res1, res2, res3) {
  document.body.appendChild(res1);
  document.body.appendChild(res2);
  document.body.appendChild(res3);
});
```

This wrapper makes a simple but powerful Image Loading library module.

### Implementation

Here is how `Qimage` works:

```javascript
var Qimage = function (url) {
  var d = Q.defer();
  var img = new Image();
  img.onload = function () {
    d.resolve(img);
  };
  img.onabort = function (e) {
    d.reject(e);
  };
  img.onerror = function (err) {
    d.reject(err);
  };
  img.src = url;
  return d.promise;
};
```

...and that's it!

Note that **the Deferred object is isolated** in the `Qimage` function scope.

Only the (read-only) Promise is accessible from the outside when returned by the function.

**How simple is wrapping a callback API into a Promise API!**

---

[Qimage][2] is released as a micro-lib and available on [Github][2] and [NPM][7].

## Next episode

Next episode will feature **`requestAnimationFrame`**, 
*a fundamental function generally used for performing efficient Javascript animations*.
We will show you **QanimationFrame** and how we can use it as a **Promisified "wait for DOM to be ready" API**.

This second article on Q will introduce you how to easily turn a callback API into a promise API using Deferred objects. It will also present the new W3C specification of Promise and finish with the implementation of Qimage, a simple Image Promise wrapper.

Qep2.: Deferred objects, Qimage

[0]: /pages/a-world-of-promises/
[1]: http://github.com/kriskowal/q
[2]: http://github.com/gre/qimage
[3]: https://github.com/kriskowal
[4]: http://wiki.commonjs.org/
[5]: http://domenic.me/2012/10/14/youre-missing-the-point-of-promises/
[6]: https://raw.github.com/kriskowal/q/master/design/README.js
[7]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/EventLoop
[8]: http://jquery.com/
[9]: http://wiki.commonjs.org/wiki/Promises/A
[10]: http://tritarget.org/blog/2012/11/28/the-pyramid-of-doom-a-javascript-style-trap/

# [A World Of Promises][0], episode 1

*This article is the first of a series of small articles 
on the Q Javascript library and its eco-system.
This article is a brief introduction to Q Promises.*

<img src="/images/2013/07/promise_then_thumbnail.jpg" alt="" class="thumbnail-left" />

[Q][1] is a **Promise library** in **Javascript** 
created 4 years ago by [Kris Kowal][3] who is one of the main contributor to [CommonJS][4]
where we can find the **[Promises/A][9]** specification.

[Q][1] is probably **the most mature and powerful Promise library in Javascript**
which inspired a lot of libraries like [jQuery][8].
It exposes a complete API with, in my humble opinion, 
good ideas like the separation of concerns between a "Deferred" object (the resolver) 
and a "Thenable" Promise (the read-only promise).

This article is a brief introduction to Q Promises with some examples.
For more information on the subject, I highly recommend reading
the article ["You're Missing the Point of Promises"][5] 
and [the Q implementation design README][6].



## What is a Promise

A **Promise** is an object representing a **possible future value** which has 
a `then` method to access this value via callback. A Promise is initially 
in a *pending* state and is then either *fulfilled* with a value or *rejected* with an error.

![Schema representing Promise states: pending -> fulfilled|rejected](/images/2013/07/promise.png)
### Some properties

It is **immutable** because the Promise value never changes and each `then` creates a new Promise. 
As a consequence, one same Promise can be shared between different code.

It is **chainable** through the `then` method (and other Q shortcut methods),
which transforms a Promise into a new Promise without knowing what's inside.

It is **composable** because the `then` method will unify any Promise returned as 
a result of the callback with the current Promise (act like a map or flatmap). 
[Q][1] also has a `Q.all` helper for combining an Array of Promise into one big Promise.

## A solution against the [Pyramid of Doom][10] effect

*Javascript* is by nature an **asynchronous language** based on an [event loop][7] which enqueue events.
As a consequence, there is no way to block long actions (like Image Loading, ajax requests, other events), but everything is instead asynchronous:
Most of Javascript APIs are using **callbacks** - functions called when the event has succeeded.

**Problem with callbacks** is when you start having a lot of asynchronous actions.
It quickly becomes a [Callback Hell](http://callbackhell.com/).

### Example

Here is a simple illustration, let's say we have 2 functions, 
one for **retrieving some photos meta-infos from Flickr** with a search criteria: `getFlickrJson(search, callback)`, 
another for **loading an image from one photo meta-info**: `loadImage(json, callback)`. 
Of-course both functions are asynchonous so they need a callback to be called with a result.

With this callback approach, we can then write:

```javascript
// search photos for "Paris", load and display the first one
getFlickrJson("Paris", function (imagesMeta) {
  loadImage(imagesMeta[0], function (image) {
    displayImage(image);
  });
});
```
*(Imagine what it can look like with more nested steps.)*

> we can easily turn a *callback* API into a *Promise* API

#### Promise style

`getFlickrJson` and `loadImage` can now be rewritten as Promise APIs:

Each function has clean signatures:

* `getFlickrJson` is a `(search: String) => Promise[Array of ImageMeta]`.
* `loadImage` is a `(imageMeta: ImageMeta) => Promise[DOM Image]`.
* `displayImage` is a `(image: DOM Image) => undefined`.

...and are easily pluggable together:

```javascript
getFlickrJson("Paris")
  .then(function (imagesMeta) { return imagesMeta[0]; })
  .then(loadImage)
  .then(displayImage, displayError);
```

**This is much more flatten, concise, maintainable and beautiful!**

Note that if we want to be safer we can write:

```javascript
Q.fcall(getFlickrJson, "Paris")
  .then(function (imagesMeta) { return imagesMeta[0]; })
  .then(loadImage)
  .then(displayImage, displayError);
```

`Q.fcall` will call the function with the given parameters and ensure wrapping the returned value into a **Promise**.
So my code should continue working even if we change signatures to:

* `getFlickrJson` is a `(search: String) => Array of ImageMeta`.
* `loadImage` is a `(imageMeta: ImageMeta) => DOM Image`.

One other cool thing about this chain of Promises is **we can easily add more steps** between two `then` step, for instance a DOM animation, a little delay, etc.

### Error Handling

But a much important benefit is, unlike the callbacks approach,
we can properly **handle the error in one row** because one of the following steps eventually fails:

* `getFlickrJson` fails to perform the ajax request to retrieve the Flickr JSON data.
* The array returned by Flickr was empty so `loadImage` throws an exception.
* The `loadImage` fails (e.g. the image is unavailable).

This is called **propagation** and is exactly how **exceptions** work.

**Promise Error Handling** really looks like **Exception Handling**.

If it would be possible to have two methods:

* `getFlickrJsonSync` is a `(search: String) => Array of ImageMeta`.
* `loadImageSync` is a `(imageMeta: ImageMeta) => DOM Image`.

Then, the blocking code would look like this:

```javascript
try {
  var imagesMeta = getFlickrJsonSync("Paris")
  var firstImageMeta = imagesMeta[0]
  var image = loadImageSync(firstImageMeta)
  displayImage(image);
} catch (e) {
  displayError(e);
}
```

*...which is very close to Promise style.*

**Q Promises also unify Exceptions and Rejected Promises**:
throwing an exception in any Q callback will result in a rejected Promise.

```javascript
var safePromise = Q.fcall(function () {
  // following eventually throws an exception
  return JSON.parse(someUnsafeJsonString);
});
// safePromise is either fulfilled with a JSON Object
// or rejected with an error.
```

> Error handling with the callbacks approach is hell:

```javascript
getFlickrJson("Paris", function (imagesMeta) {
  if (imagesMeta.length == 0) {
    displayError();
  }
  else {
    loadImage(imagesMeta[0], function (image) {
      displayImage(image);
    }, displayError);
  }
}, displayError);
```


## Next episode

Next episode, we will show you how to create your own Promises with *Deferred* objects.
We will introduce **Qimage**, a simple Image loader wrapped with Q.

---

Special Kudos to <a href="http://twitter.com/42loops">@42loops</a> & <a href="http://twitter.com/bobylito">@bobylito</a>
for bringing Q in my developer life :-P

This article is the first of a series of small articles on the Q Javascript library and its eco-system. It is a brief introduction to Q Promises.

Qep1.: Q, a Promise library

Playframework simple deployment scripts

[2]: http://gre.github.io/glsl.js/examples/balls
[3]: http://gre.github.io/glsl.js/examples
[4]: http://gre.github.io/glsl.js/docs
[5]: http://github.com/gre/glsl.js
[6]: http://gre.github.io/glsl.js/test
[7]: http://gre.github.io/glsl.js/examples/pong/
[8]: http://glsl.heroku.com
[13]: http://gre.github.io/glsl.js/examples/helloworld
[15]: http://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf
[16]: http://glsl.heroku.com/
[24]: http://gre.github.io/glsl.js/examples/canvas-text/
[25]: http://gre.github.io/glsl.js/examples/video/
[26]: http://gre.github.io/glsl.js/examples/mario_sprites/

[![glsl_mario](/images/2013/02/glsl_mario.jpg)][2]

**TL;DR. WebGL is super powerful and efficient. This library abuses this power for efficient 2D.**

glsl.js is a subset of a WebGL library which focuses on making the GLSL (OpenGL Shading Language) easy and accessible for vizualisation and game purposes (2D or 3D).

- **[Bouncing balls example video tutorial][2]**
- [Open other examples][3]
- [API Documentation][4]
- [Fork me on Github][5]
- [Unit tests][6]

[![glsl_pong](/images/2013/02/glsl_pong.jpg)][7]

## Why?

**WebGL is a very low level and stateful API**. Actually the WebGL API **is** the OpenGL API.

I wanted to make a graphic library where you wouldn’t have to know about this API but still have access to the powerful OpenGL Shading Language called GLSL.

Do you know [glsl.heroku.com][8]? It’s a cool platform for demoscene where you can experiment some nice effects in GLSL. My library extends this concept of rendering in one whole fragment shader (which takes the plain canvas) but also provides a way to inject your own Javascript variables.

### DRY

**WebGL is not DRY at all**, you always have to repeat yourself both on the GLSL and on the Javascript part (especially for synchronizing variables).  
Worse than that, you have to know in your Javascript code what are the GLSL types of every variable to synchronize.

How boring is that:

```javascript
// Synchronizing the new values of 2 variables in pure WebGL.

var myInt = 1;
var myIntLocation = gl.getUniformLocation(program, "myInt");
myInt;
gl.uniform1i(myFloatLocation, myInt); // 1i means one integer

var myVector2 = { x: 1.3, y: 2.4 };
var myVector2Location = gl.getUniformLocation(program, "myVector2");
gl.uniform2f(myVector2Location, myVector2.x, myVector2.y); // 2f means float[2]
```

**glsl.js** provides a DRY and simple way to synchronize Javascript variables.

First, the library will handle for you the UniformLocations.

More important, and unlike the WebGL API and many WebGL libraries, **you will never have to define the type of your variables from the Javascript with glsl.js!** You just define it once in your shader!

How it works behind is the framework will statically parse your GLSL and infer types to use for the synchronization. The right `gl.uniform*` function is called by Javascript reflection.

It now simply becomes:

```javascript
// Set the values of 2 variables in glsl.js
this.set("myInt", 1);
this.set("myVector2", { x: 1.3, y: 2.4 });
// ... see also this.sync() and this.syncAll()
```



More technically, **glsl.js** is a subset\* of a WebGL library which focus on **making the GLSL (OpenGL Shading Language) easy and accessible** for vizualisation and game purposes (2D or 3D).

> \* Subset, because we only focus on using a _fragment shader_ (the _vertex shader_ is static and take the full canvas size), But don’t worry, you have a long way to go with just one _fragment shader_.

The concept is to split the **rendering part in a GLSL fragment** from the **logic part in Javascript** of your app/game. Both part are linked by **a set of variables** (the state of your app/game).

![schema](https://f.cloud.github.com/assets/211411/133026/5ed79ff8-709b-11e2-85dd-60332f74dc31.png)

**glsl.js** aims to abstract every GL functions so you don’t have to learn any OpenGL API.  
What you only need to care about is the logic in Javascript and the rendering in GLSL.

By design, **you can’t mix logic and render part**, this approach really helps to focus on essential things separately.

### Efficiency

Basically, this design is efficient because the Javascript logic will take some CPU while the rendering will take the graphic card.

Today, WebGL is widely supported on modern desktop browsers. It’s not yet the case on mobile and tablet.

However, using Chrome Beta, I’m able to run my HTML5 game at 60fps on my Nexus 4, which is quite promising for the future.

<iframe width="640" height="360" src="http://www.youtube.com/embed/EzTCdjpdTfk?feature=player_embedded" frameborder="0" allowfullscreen></iframe>

_Enough talking, let’s see some examples now…_

### [][11]Hello World Example

[11]: #hello-world-example

Here is an Hello World example. For more examples, see [/examples][3].

```html
<canvas id="viewport" width="600" height="400"></canvas>
<script id="fragment" type="x-shader/x-fragment">
  #ifdef GL_ES
  precision mediump float;
  #endif
  uniform float time;
  uniform vec2 resolution;
  void main (void) {
    vec2 p = ( gl_FragCoord.xy / resolution.xy );
    gl_FragColor = vec4(p.x, p.y, (1.+cos(time))/2., 1.0);
  }
</script>
<script src="../../glsl.js" type="text/javascript"></script>
<script type="text/javascript">
  var glsl = Glsl({
    canvas: document.getElementById("viewport"),
    fragment: document.getElementById("fragment").textContent,
    variables: {
      time: 0, // The time in ms
    },
    update: function (time, delta) {
      this.set("time", time);
    },
  }).start();
</script>
```

[![screenshot](https://f.cloud.github.com/assets/211411/132729/e702c2b4-7090-11e2-8904-49e904e6c5a2.png)][13]

### [][14]GLSL: OpenGL Shading Language

[14]: #glsl-opengl-shading-language

> GLSL is a high-level shading language based on the syntax of the C programming language. (Wikipedia)

GLSL gives a very different way of thinking the rendering: basically, in a main function, you have to **set the color (`gl_FragColor`) of a pixel for a given position (`gl_FragCoord`)**.

As a nice side effect, GLSL is vectorial by design: it can be stretch to any dimension.

GLSL is efficient because it is compiled to the graphic card.

GLSL provides an interesting collection of **types** (e.g. `int`, `float`, `vec2`, `vec3`, `mat3`, `sampler2D`,… and also arrays of these types) and **functions** (e.g. `cos`, `smoothstep`, …).

[Here is a good reference for this][15].

You can also deeply explore the awesome collection of [glsl.heroku.com][16]. Any of glsl.heroku.com examples are compatible with **glsl.js** if you add some required variables (\*time\*, _mouse_, …).

### [][17]App/Game Logic

[17]: #appgame-logic

You must give to Glsl a `canvas` (DOM element of a canvas), a `fragment` (the GLSL fragment code), the `variables` set, and the `update` function.

Then you can start/stop the rendering via method (`.start()` and `.stop()`).

The `update` function is called as soon as possible by the library. It is called in a `requestAnimationFrame` context.

You must define all variables shared by both logic and render part in a Javascript object `{varname: value}`.  
Variables must match your GLSL uniform variables. Every time you update your variables and you want to synchronize them with the GLSL you have to manually call the `sync` function by giving all variables name to synchronize.

**Exemple:**

```javascript
Glsl({
  canvas: canvas,
  fragment: fragCode,
  variables: {
    time: , // The time in seconds
    random1:
  },
  update: function (time, delta) {
    this.set("time", time);
    this.set("random1", Math.random());
  }
}).start();
```

**Note:** _under the hood, a type environment of uniform variables is inferred by parsing your GLSL code._

### [][18]Using arrays

[18]: #using-arrays

Hopefully, GLSL also supports arrays. You can actually bind a Javascript array to a GLSL uniform variable.

**Example:**

In GLSL,

```glsl
uniform float tenfloats[10];
```

In Javascript,

```javascript
var glsl = Glsl({
  ...
  variable: {
    tenfloats: new Float32Array(10)
  },
  update: function () {
    this.tenfloats[3] = Math.random();
    this.sync("tenfloats");
  }
}).start();
```

Alternatively, you can still use a classical javascript Array (but native Javascript arrays are prefered because more efficient).

Use `Int32Array` for `int[]` and `bool[]`.

Vector arrays are also possible. In Javascript, you will have to give a linearized array.  
For instance,  
a `vec2[2]` will be `[vec2(1.0, 2.0), vec2(3.0, 4.0)]` if `Float32Array(1.0, 2.0, 3.0, 4.0)` is used.

### [][19]Using objects

[19]: #using-objects

Even more interesting now, you can synchronize a whole object into the GLSL world. This is very interesting for Object-Oriented approach.

**Example:**

In GLSL,

```glsl
struct Circle {
  vec2 center;
  float radius;
}
uniform Circle c1;
bool inCircle (vec2 p, Circle c) {
  vec2 ratio = resolution/resolution.x;
  return distance(p*ratio, c.center*ratio) < c.radius;
}
void main (void) {
  vec2 p = ( gl_FragCoord.xy / resolution.xy );
  if (inCircle(p, c1))
    gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
  else
    gl_FragColor = vec4(0.0, 0.0, 0.0, 1.0);
}
```

In Javascript,

```javascript
function Circle (x, y, radius) {
  this.center = { x: x, y: y };
  this.radius = radius;
  this.originalRadius = radius; // not visible by GLSL
}
Circle.prototype.update = function () {
  this.radius = this.originalRadius Math.sin(Date.now()/100);
}
var c1 = new Circle(0.5, 0.5, 0.1);
Glsl({
  ...
  variable: {
    c1: c1
  },
  update: function (time, delta) {
    c1.update();
    this.sync("c1");
  }
}).start();
```

structs inside structs are also supported:

```glsl
struct Circle {
  vec2 center;
  float radius;
}
struct Player {
  Circle circle;
  bool visible;
}
```

### [][20]Using Arrays of Objects

[20]: #using-arrays-of-objects

The two previous chapters can be assemble!

Yes man, Array of JS object is possible!

```glsl
uniform Circle circles[2];
// circles[0].radius
// …
```

```javascript
Glsl({
  ...
  variable: {
    circles: [ new Circle(0.1, 0.1, 0.2), new Circle(0.2, 0.3, 0.2) ]
  },
  ...
}).start();
```

### [][21]Using images

[21]: #using-images

GLSL:

```glsl
uniform sampler2D img;
```

Javascript:

```javascript
var image = new Image();
img.src = "foo.png";
var glsl = Glsl({
  ...
  variable: {
    img: image
  }
});
img.onload = function () {
  glsl.start();
}
```

Note: Using an image loader library can be a good idea.

In GLSL, you will need to use the texture lookup functions to access the image color for a given coordinate. E.g. `texture2D(img, coord)`. (see the [specs][15]).

#### See also

[The mario_sprites example][26]

### [][22]Using another canvas

[22]: #using-another-canvas

[![hello_world_text_glsl_js](/images/2013/02/hello_world_text_glsl_js.png)][24]

### Using

[![glsl_js_video](/images/2013/02/glsl_js_video.png)][25]

## See also

<iframe width="480" height="360" src="http://www.youtube.com/embed/kxBkfy_8JEs" frameborder="0" allowfullscreen=""></iframe>

WebGL is super powerful and efficient. This library abuses this power for efficient 2D.

glsl.js, a Javascript + GLSL library = DRY & efficient

[1]: http://scala-lang.org
 [2]: http://www.playframework.org/documentation/2.0/Iteratees
 [3]: http://gre.github.io/playCLI-examples/api
 [4]: http://github.com/gre/playCLI
 [5]: http://github.com/gre/playCLI-examples
 [6]: /2012/08/zound-a-playframework-2-audio-streaming-experiment-using-iteratees/
 [7]: http://mandubian.com/2012/08/27/understanding-play2-iteratees-for-normal-humans/
 [8]: http://gre.github.io/playCLI-examples/api/#enumerate(command:scala.sys.process.ProcessBuilder,chunkSize:Int,terminateTimeout:Long)(implicitec:scala.concurrent.ExecutionContext):play.api.libs.iteratee.Enumerator[Array[Byte]]
 [9]: http://www.playframework.org/documentation/api/2.1-RC1/scala/index.html#play.api.libs.iteratee.Enumerator
 [10]: http://gre.github.io/playCLI-examples/api/#pipe(command:scala.sys.process.ProcessBuilder,chunkSize:Int,terminateTimeout:Long)(implicitec:scala.concurrent.ExecutionContext):play.api.libs.iteratee.Enumeratee[Array[Byte],Array[Byte]]
 [11]: http://www.playframework.org/documentation/api/2.1-RC1/scala/index.html#play.api.libs.iteratee.Enumeratee

 [12]: http://gre.github.io/playCLI-examples/api/#consume(command:scala.sys.process.ProcessBuilder,terminateTimeout:Long)(implicitec:scala.concurrent.ExecutionContext):play.api.libs.iteratee.Iteratee[Array[Byte],Int]
 [13]: http://www.playframework.org/documentation/api/2.1-RC1/scala/index.html#play.api.libs.iteratee.Iteratee
 [14]: http://www.scala-lang.org/api/current/index.html#scala.sys.process.package
 [15]: http://www.playframework.org/documentation/api/2.1-RC1/scala/index.html#play.api.libs.iteratee.Done$
 [16]: #pipe(command:scala.sys.process.ProcessBuilder,chunkSize:Int,terminateTimeout:Long)(implicitec:scala.concurrent.ExecutionContext):play.api.libs.iteratee.Enumeratee[Array[Byte],Array[Byte]]
 [17]: http://www.playframework.org/documentation/api/2.1-RC1/scala/index.html#play.api.libs.iteratee.Input$$EOF$


> **TL;DR.** PlayCLI is a new [Scala][1] library to work with UNIX commands and [Play-Iteratees][2] (a scala implementation of Iteratees facilitating the handling of data streams reactively). Here’s an overview:

<iframe src="http://gre.github.io/playCLI-examples/embedder.html#index.html" frameborder="0" width="550" height="452"></iframe>

## Links

*   [The scala API][3].
*   [PlayCLI source code (Github)][4].
*   [PlayCLI Examples application (Github)][5].

### SBT

```scala
"fr.greweb" %% "playcli" % "0.1"
```



## Why PlayCLI

After having made [Zound][6] in a HackDay (an experiment to generate an audio stream with playframework iteratees and through the WAVE format), I figured out this was going to be hard to make it work with multiple audio format: *tell me if I’m wrong but*, there are not so much audio libraries in Java/Scala, or most of them does not support stream handling (and not reactively), and it was going to be crazy to re-implement everything in Scala (both in term of cost and performance).

Besides, **UNIX has plenty of tools** to do this and:

1.  they are **complete** and provide a lot of options
2.  they are **easy to use** (see how Bash is powerful as a consequence)
3.  Most of them **support streams** out of the box (via stdin / stdout)
4.  They are very **efficient** (written in C / assembly)

So why not re-use them from our reactive code?

### Similarities with UNIX pipes

> Take the expressivity of UNIX pipes, bring the power of Scala, mix it with Play Framework and you got a powerful framework for handling real-time and web streaming.

Play Iteratees are an elegant & powerful way to handle streams reactively, and I’ve actually always understood them like UNIX pipes, you have the same reactive code style: linearized declarative way of handling streams.

**Bash:**

```bash
cat words.txt | grep $word > result.txt
```

**Scala:**

```scala
Enumerator.fromFile("words.txt") &>   
  splitByNl &> // split a stream of Array[Byte] into stream of String (not impl here)  
  Enumeratee.filter(_.containsSlice(word))  |>>>   
  fileWriter // consume the steam while storing in a file (not impl here)
```

or if you prefer the “without symbol” version:

```scala
Enumerator.fromFile("words.txt").  
  through splitByNl.  
  through Enumeratee.filter(_.containsSlice(word)).  
  run fileWriter
```

However, It’s biased to say Iteratees are only UNIX pipes, they are more than that, but I’m not going to extend on that subject, they are at least statically typed and safe (it’s more than just a stream of bytes, see [this article][7]).

So if Iteratees are at least UNIX pipes, why can’t we use Unix pipes from iteratees?

**PlayCLI provides a bridge to use scala.sys.Process with play-iteratees.**

## More about PlayCLI

*(this is a copy of the API documentation)*

### Overview

Depending on your needs, you can **Enumerate / Pipe / Consume** an UNIX command:

[CLI.enumerate][8] is a way to create a stream from a command which **generates output**  
(it creates an [Enumerator][9][Array[Byte]] )

[CLI.pipe][10] is a way to pipe a command which **consumes input and generates output**  
(it creates an [Enumeratee][11][Array[Byte],Array[Byte]])

[CLI.consume][12] creates a process which **consumes a stream** – useful for side effect commands  
(it creates an [Iteratee][13][Array[Byte],Int])


#### Examples

```scala
import playcli._  
import scala.sys.process._  
  
// Some CLI use cases  
val tail = CLI.enumerate("tail -f /var/log/nginx/access.log")  
val grep = (word: String) => CLI.pipe(Seq("grep", word))  
val ffmpeg = CLI.pipe("ffmpeg -i pipe:0 ... pipe:1") // video processing  
val convert = CLI.pipe("convert - -colors 64 png:-") // color quantization  
  
// Some usage examples  
val sharedTail = Concurrent.broadcast(tail)  
Ok.stream(sharedTail).withHeaders(CONTENT_TYPE -> "text/plain") // Play framework  
  
val searchResult: Enumerator[String] = dictionaryEnumerator &> grep("able") &> aStringChunker  
  
Ok.stream(Enumerator.fromFile("image.jpg") &> convert).withHeaders(CONTENT_TYPE -> "image/png")  
  
Enumerator.fromFile("video.avi") &> ffmpeg &> ...
```

### Process

CLI uses [scala.sys.process][14]  
and create a Process instance for each UNIX command.

A CLI process is terminates when:

*   The command has end.
*   stdin and stdout is terminated.
*   [Done][15] is reached (for [enumerate][8] and [pipe][16]).
*   [EOF][17] is sent (for [pipe][10] and [consume][12]).

CLI still waits for the Process to terminate by asking the exit code (via `Process.exitCode()`).  
If the process is never ending during this phase, it will be killed when `terminateTimeout` is reached.

PS: Thanks to implicits, you can simply give a String or a Seq to the CLI.* functions a `ProcessBuilder`.

### Mutability

[enumerate][8] and [pipe][10] are **immutable**, in other words, re-usable  
(each result can be stored in a val and applied multiple times).  
**A new process is created for each re-use**.

[consume][12] is **mutable**, it should not be used multiple times: it targets side effect command.

### Logs

A “CLI” logger (logback) is used to log different information in different log levels:

*   **ERROR** would mean a CLI error (not used yet).
*   **INFO** used for the process’ stdout output of a [CLI.consume][12].
*   **DEBUG** used for the process life cycle (process creation, process termination, exit code).
*   **WARN** used for the process’ stderr output.
*   **TRACE** used for low level information (IO read/write). 

## Conclusion

I’m eager to see what you guys can do with such an API, it enables a lot of possibility, I’m especially thinking about multimedia purposes (using powerful commands like: ImageMagick, ffmpeg, sox,…).

PlayCLI is a new Scala library to work with UNIX commands and Play-Iteratees (a scala implementation of Iteratees facilitating the handling of data streams reactively)

PlayCLI: Play Iteratees + UNIX pipe

[3]: http://wtfjs.com/
 [4]: https://en.wikipedia.org/wiki/Floating_point
 [6]: http://news.ycombinator.com/item?id=5051525
 [7]: http://silentmatt.com/biginteger/

<blockquote class="twitter-tweet" lang="fr"><p>@<a href="https://twitter.com/greweb">greweb</a> : Let's do a kickstarter to build the 1st space rocket running on embedded Javascript... I think we can discover new physics rules!</p>&mdash; mandubian (@mandubian) <a href="https://twitter.com/mandubian/status/289422662101504000">10 janvier 2013</a></blockquote>

It is [common][3] in Javascript to have unexpected behaviors, but this one is particulary vicious.

> 10000000000000000 === 10000000000000001

**Javascript doesn’t have integer type but lets you think it has.** `parseInt` and `parseFloat` built-in functions, the fact that “1″ is displayed as “1″ and not as “1.0″ (like many languages) contribute to the general misunderstood.

**In Javascript, all numbers are floating numbers and are prone to [floating point approximation][4].**

When you write `var i = 1;`, and you console.log it, Javascript is nice, you obtain `1` and not `1.0000000000000001`. 

But you can experiment that, in Javascript, `1.0000000000000001 === 1` is true…

> I hear you, telling me that *this sounds OK, floating point approximation rules, right?*

But the same thing occurs for big numbers:

```javascript
10000000000000000 === 10000000000000001
```

Oh **F\*\*K** !

[edit] where in python:  
![](https://pbs.twimg.com/media/BAg2wRyCIAAGuXW.png:large)

## Termination of loops

The following is worse:

<script src="https://gist.github.com/4504986.js"></script>

is logging `10000000000000000` forever!

Because 10000000000000001 can’t exist in Javascript with approximations, 10000000000000001 is 10000000000000000, so you can’t increment this value, and you are stuck in this crazy f\*\*king loop. 

Conclusion, *Program termination proof* sounds hard to reach in Javascript!



## How many numbers in a 1000 range?

Between 10000000000000000 and 10000000000001000, there are actually 750 Javascript integers.

<script src="https://gist.github.com/4505510.js"></script>

## Real World Example

The issue can actually **lead to real web application disaster**. Imagine if your database use Long for id (well like almost every databases in the world, like twitter does), and **if you use the id as number in Javascript and not as string**, you can have strange behaviors like never being able to represent and access a resource from the Javascript or worse!

<script src="https://gist.github.com/4505517.js"></script>

## TL;DR. The lesson

This is not something new, floating point approximation, but the way Javascript fix values to round the approximations mislead us.

Now, simple thing, **Avoid numbers when approximation is not permitted** like for resource id (especially when you retrieve it from a server).

This probably impacts your JSON APIs because it’s the last thing you had think of!

Otherwise, **if you need to manipulate big integers in Javascript use a library for that**.

Example: [http://silentmatt.com/biginteger/][7]

[EDIT]  
9007199254740993 (which is 2^53 1) is the smallest not representable integer in Javascript. In other words, you can trust Javascript numbers before this integer!

[EDIT 2]  
[Thanks to 0×0 on HackerNews][6] who told me the twitter id issue example really happened in a previous twitter API:

Javascript doesn’t have integer type but lets you think it has. In Javascript, all numbers are floating numbers and are prone to floating point approximation.

Be careful with JS numbers!

[1]: https://github.com/playframework/Play20/commit/0f1ec1479e490f2c8af4cd79dd0b6a14b0ea9f75
[2]: http://www.playframework.org/
[3]: http://mandubian.com/2012/08/27/understanding-play2-iteratees-for-normal-humans/

A few weeks ago, [we’ve introduced][1] a new feature in [Play Framework][2]: the `Enumerator.outputStream` method, allowing you to work with Java API requiring an `OutputStream` to generate content, for instance the `java.util.zip` API.

**Now, let’s see how easy it is to serve a big Zip generated on-the-fly without memory load with Play Framework.**



## The Zip generation example

<script src="https://gist.github.com/4058734.js?file=Application.scala"></script>

This demo shows how to **generate a zip file on-the-fly** and directly **stream it** to an HTTP client **without loading it in memory or storing it in a file**.

It uses an `Enumerator` created with the `Enumerator.outputStream` method.  
The `OutputStream` provided by the method is then plugged to the Java’s `ZipOutputStream`.

For the example, we have generated a zip containing 100 text files, and each text files contains 100’000 random long numbers (yes, 100’000 !).

The zip size is approximatively 100 Mb. (and is generated in about 3Mb/s in my machine in localhost, but this can be improved)

The huge benefit of this is the download starts instantly, it means the Zip is streamed while it is generated.

## Show me the code!

Internally, it is implemented with a `Concurrent.unicast`, and a simple implementation of an `OutputStream` pushing into the unicast’s channel:

<script src="https://gist.github.com/4058734.js?file=Enumerator.scala"></script>

## About Iteratee and Enumerator

If you want to learn more about Iteratee concepts in Play Framework, I recommend you [this article][3].

A few weeks ago, we’ve introduced a new feature in Play Framework: the Enumerator.outputStream method, allowing you to work with Java API requiring an OutputStream to generate content, for instance the java.util.zip API.

Play Framework – Enumerator.outputStream

![ZOUND](/images/2012/07/ZOUND.png)

Last Friday was HackDay #7 at [Zenexity][2], and we decided to work on a real-time audio [experiment][3] made with [Play Framework][4]. The plan was to use an audio generator ([JSyn][5], an audio synthesizer), encode the output and stream it all using Play Iteratees to pipe everything in real-time.

 [2]: http://zenexity.com
 [3]: http://github.com/gre/zound
 [4]: http://playframework.org
 [5]: http://www.softsynth.com/jsyn/
 [7]: https://twitter.com/mrspeaker
 [12]: http://www.playframework.org/
 [13]: scala-lang.org/
 [14]: http://sadache.tumblr.com/post/26784721867/is-socket-push-bytes-all-what-you-need-to-program
 [15]: http://www.infoq.com/presentations/Play-I-ll-See-Your-Async-and-Raise-You-Reactive
 [16]: https://github.com/playframework/Play20/tree/master/framework/src/play/src/main/scala/play/api/libs/iteratee
 [17]: http://en.wikipedia.org/wiki/WAV
 [19]: http://en.wikipedia.org/wiki/Broadcasting_(networking)

<iframe width="640" height="360" src="http://www.youtube.com/embed/taDLKTcNHnQ?feature=player_embedded" frameborder="0" allowfullscreen></iframe>

**First of all, let’s highlight some interesting part of the project, then get into some of the details.**

Thanks to [@Sadache][6] for his Iteratee expertise, we ended up with a simple line of code that does all of the hard work:

 [6]: https://twitter.com/Sadache

```scala
val chunkedAudioStream = rawStream &> chunker &> audioEncoder
```

You can think of the `&>` operator as the UNIX pipe `|`. So we simply take the `rawStream`, chunk it with a `chunker` and encode it with an `audioEncoder`.

Now, **rawStream** is the raw stream of audio samples (numbers between -1 and 1) generated by the audio synthesizer. Next, the **chunker** buffers a data stream into chunk of bytes. For instance, if you send data stream at 1Kb/s to a 10Kb chunker, it will output one chunk of size 10Kb every 10 seconds. And finally, the **audioEncoder** takes **audio samples** and outputs encoded bytes implementing an audio format (like WAVE).

We can then make a broadcast of the stream:

```scala
val (sharedChunkedAudioStream, _) =   
  Concurrent.broadcast(chunkedAudioStream)
```

And then the **sharedChunkedAudioStream** is now a shared stream for every consumer (clients). All that’s left to do is to stream it over HTTP:

```scala
def stream = Action {  
  Ok.stream(audioHeader >>> sharedChunkedAudioStream).  
     withHeaders( ("Content-Type", audio.contentType) )  
}
```

The `>>>` operator means “concatenation”, so here we’re concatenating the **audio header** (given by the format like WAVE) with the current **chunked audio stream**. We also send the right HTTP **Content-Type** header (like “audio/wav” for WAVE).

Another interesting part of the project is the **multi-user web user interface: allowing users to interact with the sound synthesis**.

Using [@mrspeaker][7]‘s audio synthesis expertise, we started creating a synthesizer generator – 3 oscillators, various wave shapes, frequency and volumes, and finally flowing through a high pass filter before entering our “rawStream” above.


Thanks to the Play framework goodness, **this audio stream can be both consumed by the web page with an HTML audio tag, and with a stream player such as VLC!** Ok, that’s the project – let’s have a closer look at some of the concepts…




## What is sound?

> Sound is a mechanical wave that is an oscillation of pressure transmitted through a solid, liquid, or gas, composed of frequencies within the range of hearing and of a level sufficiently strong to be heard, or the sensation stimulated in organs of hearing by such vibrations. ***Wikipedia***

We can represents the sound like any wave as a graphic of the amplitude (the oscillation pressure) as a function of time. Here you see it in Audacity:

![sound-audacity](/images/2012/07/sound-audacity.png)

Electricity is used to pump these amplitudes to your speakers, over time.

### About primitive wave sounds

There are some patterns – some primitives waves – we can easily generate with computers (or before with analog oscillators). Those are well known by mathematicians and physicians: Sine wave, Triangle wave, Square wave,…

[![](/images/2012/07/557px-Waveforms.svg_.png)][10]

 [10]: http://en.wikipedia.org/wiki/File:Waveforms.svg

A sine wave produce a smooth tone, whereas Triangle and Square wave are more aggressive sounds. The shorter a wave period is, the lower the note you hear: it’s called the frequency.

### How is sound represented by computer?

Whereas analog oscillators generate sounds in an *almost** continuous stream of electricity, computers are not able to generate continuous stream of data. This is why with computers the sound is divided in to discrete **samples**, usually **44100 samples per second** for standard CD quality audio. Each sample is a value (amplitude) for a given time position.

[See Sampling (wikipedia)][10].

 [10]: http://en.wikipedia.org/wiki/Sampling_(signal_processing)

If you zoom in Audacity, you can actually see each sample:  
![audacity-zoom](/images/2012/07/audacity-zoom-ah.png)
This is an “AH” timbre of my voice. A timbre is unique to everyone, it’s the pattern the sound wave take when you speak. **The amplitude of an audio sample is usually represented as a Real number between -1.0 and 1.0**.

** electricity is not strictly continuous, we have electrons out there!*

Ok, Let’s go back to our experiment now!

## The experiment

Our experiment is using [Play Framework][12] and is written in [Scala language][13]. Specifically, our project takes advantage of Play framework’s powerful **Iteratee**s.


> Take the expressivity of UNIX pipes, bring the power of Scala, mix it with Play Framework and you got a powerful framework for handling real-time and web streaming.

The iteratee (and related constructs) can take a bit of getting used to. I recommend checking out [this article on Iteratees in Play][14] and/or [this presentation][15] if you are interested in learning more about Play2 and reactive programming with Iteratees. And if you just want to see how it work – you can read the source code at [Play20 Github source code][16].


### Generating the audio stream

```scala
val (rawStream, channel) = Concurrent.broadcast[Array[Double]]  
val zound = new ZoundGenerator(channel).start()
```

We create an `Array[Double]` broadcast which return two values: the **rawStream** will be used to read the generated data, and the **channel** used by the generator to push generated audio samples. We give this channel to the **ZoundGenerator**. The `.start()` then starts the audio generation. All of the generation is done using the JSyn library.

Here’s a snippet from the **ZoundGenerator** class showing the connection between **JSyn** and **Channel**:

```scala
class ZoundGenerator(output: Channel[Array[Double]]) {  
  val out = new MonoStreamWriter()  
  
  val synth = {  
    val synth = JSyn.createSynthesizer()  
    synth.add(out)  
    out.setOutputStream(new AudioOutputStream(){  
      def close() {}  
      def write(value: Double) {  
        output.push(Array(value))  
      }  
      def write(buffer: Array[Double]) {  
        write(buffer, , buffer.length)  
      }  
      def write(buffer: Array[Double], start: Int, count: Int) {  
        output.push(buffer.slice(start, start count))  
      }  
    })  
    synth  
  }  
  // ...
```

We have to implement the methods of AudioOutputStream – but it’s just a matter of pushing each audio sample to the channel. It’s that simple!

### Encoding the raw audio stream

For now, we have only implemented the [WAVE format][17]. Basically, WAVE has 2 parts; the WAVE header which describes important information (like the framerate and the bits per sample), and the data.  
The data is encoded in a simple manner I won’t describe here but you can look to the encoder I made here: 


Now more interesting, let’s wrap it with Play Iteratees:

```scala
val audio = MonoWaveEncoder() // instanciate the WAV encoder  
val audioHeader = Enumerator(audio.header)  
val audioEncoder = Enumeratee.map[Array[Double]](audio.encodeData)
```

***N. B.***: *Remember that Scala is a typed language but where the type declaration is optional because the compiler can infer the type.*

**audioHeader** is an `Enumerator` which means it can *produce* data, and here the data is the audio header. More precisely it’s an `Enumerator[Array[Byte]]` because audio.header is an `Array[Byte]`. Note that contained data is not “consumed” like it would be for an `InputStream`. Each time you use this enumerator, it gives you its entire content.

**audioEncoder** is an `Enumeratee[Array[Double], Array[Byte]]`. It takes an `Array[Double]` from input and returns an `Array[Byte]` as output. The input is a raw array of audio samples (double numbers between -1.0 and 1.0). The output is the encoded array of bytes.

More formally, an `Enumeratee[A, B]` is an *adapter* which maps some data of type A to new data of type B. You can implement the way the data is transformed with the map function. Here we just give it the `audio.encodeData` function.

### Streaming it

We can basically stream the audio stream with Play2 like so:

```scala
def stream = Action {  
  val audioStream = rawStream &> audioEncoder  
  Ok.stream(audioHeader >>> audioStream).  
     withHeaders( (CONTENT_TYPE, audio.contentType) )  
}
```

The `rawStream &> audioEncoder` takes the raw stream and **pipes** it into the encoder which results in the encoded audio stream. `audioHeader >>> audioStream` will **concatenate** `audioHeader` with `audioStream`. Hence, the first thing the server will do is start sending the audio header to the client **and then** stream the audio in real-time.

**A client can connect at any time and will hear current stream**, so it should simultaneously hear the same thing as any other client (with some delay depending on the client buffer). If the generator stops emitting audio samples, the http client will stop receiving audio data – but it will still be waiting for the server, so the audio play will pause until the server re-sends new audio samples. **That is pretty cool!** – because of the way iteratees work, the stream doesn’t just die when all of the input is consumed.

#### A chunker to reduce HTTP packet numbers

Up to now we’ve been streaming the audio in **very small chunks** because by default JSyn writes out arrays of just 8 audio samples and the `.stream()` function consumes all data as it comes. This means *a lot* of HTTP chunks per second are sent – which is less efficient and take more bandwidth.

In order to fix this, we need to use a **buffer on the server side**. In other words, instead of sending audio samples as they come we need to **group audio samples**. We have currently grouped audio samples in arrays of 5000 which is quite reasonable (it’s about 10 chunks per second using 44100 samples/s). We can easily change this later. This logic is implemented in an `Enumeratee` we called “chunker”. In that sense, it is reusable and modular:

```scala
val chunker = Enumeratee.grouped(  
  Traversable.take[Array[Double]](5000) &>> Iteratee.consume()  
)
```

And now, we can easily plug it in like this:

```scala
def stream = Action {  
  val chunkedAudioStream = rawStream &> chunker &> audioEncoder  
  Ok.stream(audioHeader >>> chunkedAudioStream).  
     withHeaders( (CONTENT_TYPE, audio.contentType) )  
}
```

### Broadcast

Now, another improvement we made was to **factorize this chunking and encoding part: avoiding having this computing tasks done for every stream consumer**.

Basically, we move it out of the stream function:

```scala
val chunkedAudioStream = rawStream &> chunker &> audioEncoder  
def stream = Action {  
  Ok.stream(audioHeader >>> chunkedAudioStream).  
     withHeaders( (CONTENT_TYPE, audio.contentType) )  
}
```

But to allow broadcasting, we have to use a broadcast:

```scala
val chunkedAudioStream = rawStream &> chunker &> audioEncoder  
val (sharedChunkedAudioStream, _) =  =   
  Concurrent.broadcast(chunkedAudioStream)  
def stream = Action {  
  Ok.stream(audioHeader >>> sharedChunkedAudioStream).  
     withHeaders( (CONTENT_TYPE, audio.contentType) )  
}
```

Here we only care about the enumerator (the left argument in the Tuple2), we put the wildcard "_" to ignore the return value.

[![](/images/2012/07/320px-Broadcast.svg_.png)][19]

Using a broadcast, generated audio samples pushed by the audio generator can be simultaneously spread to multiple consumers. This is perfect for our needs, multiple players can connect to this web radio!

### Avoiding the server load

The last important fix we made was to **avoid the server load**:

```scala
  def stream = Action {  
    Ok.stream(audioHeader >>> sharedChunkedAudioStream   
      &> Concurrent.dropInputIfNotReady(50)).  
       withHeaders( (CONTENT_TYPE, audio.contentType) )  
  }
```

If a client is opening the stream connection but doesn’t consume enough or doesn’t consume it at all (download is paused), the server will fill in memory the chunks to send to the client and the server can reach an *out of memory* exception. To avoid that **we have to drops chunks if the consumer is not ready**. Then the client will just lose messages if it is not ready (in our case, we give them 50 milliseconds).

And this is what `Concurrent.dropInputIfNotReady(50)` is actually doing – with yet another **Enumeratee**! **Dropping old chunks is really what we want in an audio streaming application**: We want the consumer to subscribe to the current audio stream and not to continue from where they stopped.

### Client consumers

#### HTML5 Audio tag

In HTML5, we have the Audio tag – and we can just consume our stream like this:

```html
<audio src="/stream.wav"></audio>
```

Or if we want to make it auto loading:

```html
<audio src="/stream.wav" preload autoplay controls></audio>
```

It may be a bit “wrong” to use `` for streaming, but it works because we are using it as if the server was hosting a static audio file. The only disputable hack is to have to set the max ChunkSize in the WAVE header which is 2147483647 (it’s about 6 hours 45mn!), so the browser believes the audio is not finished.

The issue we are currently facing is this crazy latency (a few seconds) between user actions and the produced sound. This problem is due to the browser audio cache buffer: if we were able to minimize it we would have an almost real-time audio player.

#### Playing it with VLC

This stream is spread through HTTP so we need a HTTP client to consume it. But a HTTP client doesn’t mean only browsers! We can also use VLC for this, as if it was a web radio! One advantage of using VLC is it suffers far less latency (presumably because the cache buffer is smaller than the audio tag).

![vlc](/images/2012/07/vlc.png)

## Making the real-time control UI

Our experiment **mixes different oscillators to generator one sound**. The web user interface allows a user to control the parameters of those. Two knobs control the **volume** and the **pitch** (tuned to a dorian mode scale) and you can select the oscillator **wave primitive** (sine, sawtooth, square, noise). It’s not fancy at the moment – but JSYN offers a lot of features for expanding our simple demo.

![](/images/2012/07/Capture-d’écran-2012-07-31-à-16.42.15.png)

This interface is **multi-users**, so if you use it with other people, **the interface will stay synchronized over multiple browsers** (turn the knobs, change the wave primitive, …). All this is done with WebSockets, and on the server-side it’s using, again, **Iteratees**!

The workflow is simple: When someone does some action on the user interface, events are sent to the server. These events are interpreted by the *ZoundGenerator* resulting in updates to the audio synthesis configuration. These events are then broadcast to each client, and some Javascript handlers are called in order to keep the interface synchronized.

## Source code

**[Fork me on Github][3]**

## What’s next?

This was just a simple demo to show the power and flexibility of Play2′s Iteratee concept. Because of the modular nature, extending the demo is easy. For example, we could plug a new audio encoder such an OGG encoder. The code would be simple and we could even choose on a request-by-request basis which encoder to use:

```scala
import Concurrent.broadcast  
val (chunkedWaveStream, _) =   
  broadcast(rawStream &> chunker &> waveEncoder)  
val (chunkedOggStream, _) =   
  broadcast(rawStream &> chunker &> oggEncoder)  
  
def stream(format: String) = Action {  
  val stream = format match {  
    case "wav" => waveHeader >>> chunkedWaveStream  
    case "ogg" => oggHeader >>> chunkedOffStream  
  }  
  Ok.stream(stream).  
     withHeaders( (CONTENT_TYPE, audio.contentType) )  
}
```

**Now it’s up to you!**

Hopefully you get a feel for the possibilities of stream processing and piping with Play. You can now reuse these concepts and make your own stuff: Maybe you don’t need to generate sounds on the fly, but instead you simply want to play a collection of audio files and stream them like radio? **Well you can make a web radio engine now!**. 

But that’s just the beginning – I would love to see someone taking the concept, and running even further… Do you know that in Youtube, during the time you are uploading a video, Youtube is already re-encoding it and can start streaming it *before* the file has finished uploading? Hmm, that’s starting to sound almost simple…

Zound uses an audio generator (JSyn, an audio synthesizer), encode the output and stream it all using Play Iteratees to pipe everything in real-time.

Zound, a PlayFramework 2 audio streaming experiment using Iteratees

[1]: http://youcanmakevideogames.com/
[2]: http://7dfps.org/
[3]: http://www.ludumdare.com/
[4]: http://gre.github.io/dta
[8]: http://caniuse.com/#search=webgl
[12]: http://www.egonelbre.com/js/jsfx/
[16]: http://www.opengl.org/documentation/glsl/
[17]: http://glsl.heroku.com/
[19]: https://github.com/gre/dta/blob/master/app/models/models.scala
[20]: http://playframework.org/

![](/images/2012/07/dta1.png)

Last week was the [7dfps challenge][2], an open challenge where participants had to make a FPS in only one week.
Such contest are very very interesting for those who want to experiment with things. Challenging yourself is IMO the best way to learn new things. You may also know the famous [“Ludum Dare” contest][3].

I learned to use Backbone.js and Three.js (a famous library on top of WebGL) in only one week, so you have no excuse to not be able to do the same!

[-> You can make games!][1]

> “If Lawnmower Man f\*\*\*\*d Tron on the bonnet of a tank”  
> **_YouBigNugget_**

I’ve only used web technologies, no need of any plugin, just a recent browser like Chrome / Firefox.

This is the result:

<iframe width="640" height="360" src="http://www.youtube.com/embed/g9CldBI9C6E?feature=player_embedded" frameborder="0" allowfullscreen></iframe>

and you can play it here:

**[Play the game][4]**



## Overview of a one week game development

### Backbone.js, for the model, events and class inherence

I’m a fan of the “do it yourself” idea, not using any library or only using small 140byt.es codes. But the frequent issue with that is (1) always doing the same thing again and again, (2) taking a lot of time on the architecture, and not finishing anything. When you have a due date, relying on libraries and frameworks could save you a lot of time.  
I’ve choose Backbone.js for its Model architecture with class inherence, a get/set system, and also its event system bound to model instances, the destroy function with the “destroy” event to bind on,… It was also a new library to learn for me.

#### Models

Here is the class diagram of the game:

![not available](/images/2012/07/f5dea341.jpg)

### Learning Three.js, a 3D library on top of WebGL.

WebGL is [more and more supported by browsers][8].  
WebGL means OpenGL in the web. It allows to make efficient and hardware accelerated 3D computation.

Here is the same, not using any library but using pure WebGL wasn’t possible in one week! This is why I’ve chosen to use Three.js, probably today the most popular WebGL library.  
I was impressed how Three.js is finally not so hard to use, knowing some basic 3D concepts from my old Blender days.

You create a `Scene`, add a `Camera`, add Meshes to the scene, A `Mesh` has a `Material` and a `Geometry`, … everything very straighforward.

One challenging part was when trying to compute global world position relative to a given object position, for instance to compute the Bullet initial position and orientation from the Tank position and orientation.

Fortunately I’ve got some help ![:)][4] and got the answer: multiply your vector with the worldMatrix of the mesh.

<blockquote class="twitter-tweet" data-in-reply-to="212609230891524096" width="550" lang="fr"><p>@<a href="https://twitter.com/greweb">greweb</a> Should be calculatable quite easily. Multiply the position vector by the object’s matrixWorld property.</p>
<p>&mdash; Paul Lewis (@aerotwist) <a href="https://twitter.com/aerotwist/status/212617930024816641" data-datetime="2012-06-12T18:50:39+00:00">Juin 12, 2012</a></p></blockquote>

<blockquote class="twitter-tweet" data-in-reply-to="212609230891524096" width="550" lang="fr"><p>@<a href="https://twitter.com/greweb">greweb</a> var position = new THREE.Vector3().getPositionFromMatrix( object.matrixWorld );</p>
<p>&mdash; Mr.doob (@mrdoob) <a href="https://twitter.com/mrdoob/status/212648943673290752" data-datetime="2012-06-12T20:53:53+00:00">Juin 12, 2012</a></p></blockquote>

### Playing with AI

Like TankKeyboardControls, I’ve created a new “TankControls” for computer tanks: **TankRandomControls** was the first dumb one, it just does random things:

```javascript
function TankRandomControls () {
var self = this;
self.moveForward = false;
self.moveBackward = false;
self.moveLeft = false;
self.moveRight = false;
self.fire = false;
self.fireMissile = false;
var i = ;
setInterval (function () { // take random decisions every 0.5 second
  i;
self.moveForward = i%3== && Math.random() > 0.2;
self.moveBackward = !self.moveForward && Math.random() > 0.5;
self.moveLeft = Math.random() < 0.1;
self.moveRight = Math.random() < 0.1;
self.fire = Math.random() > 0.2;
self.fireMissile = Math.random() < 0.2;
}, 500);
}
```

**TankRemoteControls** was the second one using some simple AI rules:

- Try to avoid walls and objects
- Either do random things or target a tank (more likely)
- Target the closest tank, update target every 5 seconds
- Turn the tank to the target tank, shoot bullets and missiles
- Move forward if the target is far away / Move backward if the target is too close

See the source code here: .

### Sounds

I’ve used [JSFX][12], an experimental library, were you can generate sounds based on a few parameters.  
It’s a 8-bit sound generator perfect for generate old-school sounds.

So you can create each sound in Javascript like this:

```javascript
SOUNDS = {
  bullet: jsfxlib.createWave([
    "noise",
    7.0,
    0.18,
    0.0,
    0.082,
    0.0,
    0.222,
    20.0,
    800,
    2400.0,
    -0.428,
    0.0,
    0.0,
    0.01,
    0.0003,
    0.0,
    0.0,
    0.0,
    0.0,
    0.0,
    0.0,
    0.0,
    0.0,
    0.992,
    0.0,
    0.0,
    0.22,
    0.0,
  ]),
  missile: jsfxlib.createWave([
    "noise",
    0.0,
    0.12,
    0.0,
    0.546,
    0.0,
    0.856,
    64.0,
    250,
    1063.0,
    0.28,
    0.086,
    0.024,
    5.4329,
    0.3565,
    0.466,
    -0.638,
    0.058,
    0.008,
    0.0,
    0.0,
    -0.114,
    0.216,
    0.98,
    -0.984,
    1.0,
    0.307,
    0.988,
  ]),
  explosion: jsfxlib.createWave([
    "noise",
    1.0,
    0.4,
    0.02,
    0.682,
    1.746,
    1.97,
    100.0,
    378.0,
    2242.0,
    -0.55,
    -0.372,
    0.024,
    0.4899,
    -0.1622,
    0.262,
    0.34,
    0.724,
    0.0205,
    -0.102,
    0.0416,
    -0.098,
    0.1,
    0.805,
    0.094,
    0.428,
    0.0,
    -0.262,
  ]),
  collideWall: jsfxlib.createWave([
    "noise",
    0.0,
    0.4,
    0.0,
    0.056,
    0.0,
    0.296,
    20.0,
    560.0,
    2400.0,
    -0.482,
    0.0,
    0.0,
    0.01,
    0.0003,
    0.0,
    0.0,
    0.0,
    0.0,
    0.0,
    0.0,
    0.0,
    0.0,
    1.0,
    0.0,
    0.0,
    0.0,
    0.0,
  ]),
};
// ...
// SOUNDS.bullet.play()
```

The jsfxlib.createWave function returns a HTML5 Audio element and you can play with its API (.play(), .pause(), …).  
But doing this way, you will not be able to play a sound at the same time so I’ve made a buffer system which duplicate N times the sound in different audio elements.  
I have also try to generate different sounds to randomize it a little.

See the full source code here: .

### Post Processing Effects with GLSL shaders

I was very impressed by the power of GLSL for its possibilities and efficiency.  
GLSL are definitely the indispensable thing you need to add a better atmosphere in your games.

#### Before

![](/images/2012/06/before.png)

#### After

![](/images/2012/06/after_.png)

and when getting shot:

![](/images/2012/06/after.png)

These effects are done by combining these two GLSL effects.  
Here is the GLSL code of these effects.

#### The radio noise effect

<script src="https://gist.github.com/2950478.js?file=radionoise.frag"></script>

#### The shot interference

<script src="https://gist.github.com/2950478.js?file=perturbation.frag"></script>

### Wait! what is this crazy “GLSL” language?

GLSL is an OpenGL language close to the C syntax design to have a direct control of the graphic pipeline. You can directly add passes to the rendering process with GLSL shaders.  
GLSL gives you a lot of very useful types (like vectors, matrix, …) and functions (like smoothstep, …). [Read the spec][16] to know more about it.  
I also recommend you to experiment the [GLSL Sandbox][17]. You can see awesome demos and their codes shared by people made with GLSL. It also have an online IDE to easily code and instantly test your shaders.

### WebGL and Three.js integration

You can use GLSL in different ways with Three.js. You can add a GLSL shader to an object material, and you can also add GLSL shaders on top of the Canvas (post-processing). We will only see how to add GLSL shaders as a post processing render on the entire Canvas.

Fortunately Three.js have some utils classes to make the GLSL shaders integration easier.

I have been inspired from the awesome work done here: .

There is a lot of code out there, so I’ve try to extract the minimum required for mixing the 2 GLSL shaders for a post-processing on the entire canvas of a Three.js scene:

<iframe style="width: 100%; height: 400px;" src="http://jsfiddle.net/jggvJ/7/embedded/" frameborder="0" width="320" height="240"></iframe>

As you can see, you can easily inject your own Javascript variables in a GLSL shader to make a bridge between the JS and the GLSL code and so having quite generic and configurable shaders.  
Quite cool!

### Adding game UI

Web, with HTML and CSS, allows to have different containers, layers, positioning systems,…  
Perfect! For the game UI, we used different elements:

![](/images/2012/06/ui.png)

Radar and Damage are implemented with an independent Canvas while Level is a simple text div.

For instance, this is Damage (I called LifeIndicator):

```javascript
(function(){

var LifeIndicator = function (nodeId) {
this.canvas = document.getElementById(nodeId);
this.ctx = this.canvas.getContext("2d");
this.life = 1;
this.render();
}

LifeIndicator.prototype.setLife = function (life) {
this.life = life;
this.render();
}

LifeIndicator.prototype.render = function () {
var c = this.ctx;
var w = c.canvas.width, h = c.canvas.height;
c.clearRect(, , w, h);
// TODO
var g = Math.floor(255*this.life);
var r = 255-g;
c.fillStyle = "rgb(" r "," g ",0)";
var wt = 6;
var ht = 12;
c.fillRect((w-wt)/2, , wt, ht);
c.fillRect(, ht, w, h);
}

window.LifeIndicator = LifeIndicator;

}());
```

## Play Framework integration

I was planning to make a multiplayer game but I couldn’t find the time for this.  
I use Play Framework 2 and its power and concepts for handling streams (even if I don’t use it yet).  
The only part I can show you for now is the game map generation. For making a multiplayer game, I needed to have the game state on server side to be able to submit game infos (map, players, …) to new players.

This is a few scala code to generate a nice distribution of random objects in the map:

```scala
object Game {
  def createRandom: Game = {
    val random = new Random()
    val half = 5000
    val size = 2*half
    val split = 4
    val objects =
    Range(, split).map { xi =>
      Range(, split).map { yi =>
        val s = size.toDouble / split.toDouble
        val x = -half.toDouble math.round(s*(xi random.nextDouble));
        val y = -half.toDouble math.round(s*(yi random.nextDouble));
        var sizeRandom = random.nextDouble
        val w = 200.*math.ceil((1-sizeRandom)*8.);
        val h = 200.*math.ceil(sizeRandom*8.);
        RectObj(Vec3(x,y,), w, h)
      }.toList
    }.toList.flatten
    Game( (Vec3(-half, -half, ), Vec3(half, half, )), List(), objects, List() )
  }
}

case class Game (bounds: Tuple2[Vec3, Vec3], chars: List[Char], objects: List[GameObj], dynamics: List[GameDyn])
...
```

[See the full source][19] (some code may not be used).

## Still an unfinished game

There is more things to do now:

- More visual effects
- More sound effects
- A better collision system (using a physic engine?)
- Multiplayer
- A better gameplay with some goals, different kind of games, …

### Initial multiplayer objective rescheduled

My initial game release was focus on the game core, graphisms and gameplay.

I was unfortunately not ready enough to make the multi-player real-time part for the first week sprint but I have some though on the subject.  
I was asking myself what are the best way to make the game synchronisation between clients while trying to keep as much client-side code as possible. I wanted a scalable decentralized game. I had some though on how to solve this issue. For instance, when a client shoots, he sends a “shoot” event with the timestamp, server just streams events (with a tick frequency) sent by clients and clients replay the game exactly the same way everywhere (using all these time-based events) with some interpolation with the current time.  
I need to think more about this now, and try to use [PlayFramework][20].

## Source code

[http://github.com/gre/dta](http://github.com/gre/dta)

**[EDIT] You may be mainly interested by the [main.js][21]. It shows how powerful the even-driven programming is, for plugging components together.  
**

[21]: https://github.com/gre/dta/blob/master/app/assets/javascripts/main.js

## Special thanks

[@mrspeaker][22] for helping me with Three.js & also collision system,  
[@mrdoob][23] & [@aerotwist][24] for replying to my newbies questions,  
guys on IRC (#three.js),  
and of-course 7dfps guys.

[22]: http://twitter.com/mrspeaker
[23]: http://twitter.com/mrdoob
[24]: http://twitter.com/aerotwist

I learned to use Backbone.js and Three.js (a famous library on top of WebGL) to make a FPS in only one week.

How I learned Backbone.js, Three.js, GLSL in one week

I’ve always been fascinated by the power of **using existing web applications as external tools**: you don’t need to install anything on your computer but you can **rely on the web**.

We can **externalize the intelligence of applications in servers** and **easily make updates**, while having any terminal consuming them with a **minimal OS environment**.  
*Cloud* or whatever you call it, it’s awesome.

WOA is our common architecture for making applications. Clients of web servers can be anything you want, not only desktop browsers, but also mobiles, tablets, other web services, and… **command-line**!

And today, as an example, we will use [Google Closure Compiler web service][1] to **minimize a Javascript file with only cURL**.

 [1]: https://developers.google.com/closure/compiler/docs/api-ref



**cURL** is a CLI swiss army knife of transferring data and it is perfect for testing, debugging and consuming web services.

**Google Closure Compiler** check and “compile” your Javascript file. By compile, it means optimizing its size by renaming variables and removing spaces and comments. Javascript compilation has because an essential phase of major javascript libraries.

## Bash script examples

### Download and minimize the last version of Illuminated.js

```bash
URL=https://raw.github.com/gre/illuminated.js/master/src/illuminated.js  
OUTPUT=illuminated.min.js  
curl -d compilation_level=SIMPLE_OPTIMIZATIONS -d output_format=text -d output_info=compiled_code -d code_url=$URL http://closure-compiler.appspot.com/compile > $OUTPUT
```

### Minimize a local JS file

```bash
LOCAL_FILE=./mysuperlib.js  
OUTPUT=mysuperlib.min.js  
curl -d compilation_level=SIMPLE_OPTIMIZATIONS -d output_format=text -d output_info=compiled_code --data-urlencode "js_code@${LOCAL_FILE}" http://closure-compiler.appspot.com/compile > $OUTPUT
```

use Google Closure Compiler web service to minimize a Javascript file with only cURL.

Minimize your Javascript files with cURL

[1]: http://bit.ly/LZ2dq1
[2]: http://gre.github.io/illuminated.js
[3]: http://github.com/gre/illuminated.js
[4]: /2012/05/illuminated-js-2d-lights-and-shadows-rendering-engine-for-html5-applications/#gettingstarted
[5]: /2012/05/illuminated-js-2d-lights-and-shadows-rendering-engine-for-html5-applications/#underthehood
[6]: http://en.wikipedia.org/wiki/Canvas_element
[7]: http://gre.github.io/illuminated.js/gettingstarted.html
[8]: http://en.wikipedia.org/wiki/Ray_tracing_(graphics)
[9]: /images/2012/05/step11.jpg
[10]: /images/2012/05/step21.jpg
[11]: /images/2012/05/step31.jpg
[12]: /images/2012/05/step4.jpg
[13]: http://blog.marmakoide.org/?p=1
[14]: /images/2012/05/sampling.jpg
[15]: http://en.wikipedia.org/wiki/Tangent_lines_to_circles

[![](/images/2012/05/illuminatedjs.jpg)][1]

[Click on the image to open it!][1]

## Wow! what’s this?

It’s a **2D scene** containing 2 **lights** and 13 different **objects** rendered in **real-time** by a **Javascript library** I made called **Illuminated.js**.

The library is designed to add some **awesome effects to your existing applications**. Adding **a cool atmosphere for your applications and games** can make the difference!

**[Try the editor][2]** and **[Get the source code][3]**.

In this article, we will introduce the basic usages of _Illuminated.js_ and APIs, and then explain how the engine works step-by-step.

- [API – Getting started][4]
- [Technical notes – how does it work?][5]



## How can I use it?

The library uses [HTML5 Canvas][6] to draw lights and shadows – so you can simply drop it straight into your existing Canvas applications: you just need to add some code in your render function and maintaining a binding between your application logic and the _Illuminated.js_ objects.  
Not using canvas? No worries! In theory, if you have an existing application or game made in full DOM, you could use _Illuminated.js_ behind this, playing with z-index.

## <a id="gettingstarted"></a> Getting started

### Basic concepts

All the classes of the package live in `window.illuminated`.

A **Light** describes a light emit source.  
An **OpaqueObject** specifies an 2D object used by a Lighting.  
A **Lighting** defines the lighting of a light through a set of opaque objects, each object stops the light and casts shadows.  
A **DarkMask** defines a dark layer which hides dark area not lighted by a set of lights. It should be drown on the top-layer to hide objects which are far from the light. This effect produces a better atmosphere and is perfect for game where light are essential (where hiding invisible area is part of the difficulty).

### Example of a basic scene rendering

[  
Click here to open this example.  
![](/images/2012/05/gettingstarted.jpg)
][7]

## Lights and Objects

### Vec2

```javascript
new Vec2(x, y);
```

Vec2 represents a 2d position or a 2d vector. It is used everywhere in _Illuminated.js_.

Vec2 is inspired from Box2d’s Vec2 except that in _Illuminated.js_ a Vec2 vector is immutable. It means every methods create a new Vec2 instance and you can safely use a same Vec2 instance everywhere because the immutability guarantees the non-modification of properties.

### Lights

For now, we have only implemented one kind of light: a **Lamp** which is basically a radial gradient. A Lamp can also be “oriented”, it means lighting more far in a given direction.

#### Lamp

```javascript
new Lamp();

new Lamp({ position: new Vec2(12, 34) });
```

every parameters:

```javascript
new Lamp({
  position: new Vec2(12, 34),
  distance: 100,
  diffuse: 0.8,
  color: 'rgba(250,220,150,0.8)',
  radius: ,
  samples: 1,
  angle: ,
  roughness:
})
```

It defines a **Lamp** placed at a **position**, with a maximum emiting **distance**, a **diffuse** parameters to define the light penetration in objects.  
The **radius** defines the size of the light. Bigger the size is, Higher shadows are smoothed. The **samples** is an important parameters to define the quality of this smooth.  
The **angle** and **roughness** parameters are used for oriented lamp: angle defines the orientation while roughness defines the roughness of the effect.

### Light methods

You can easily create your own Light type by implementing its methods.

#### .mask(ctx)

Render a mask representing the visibility (used by DarkMask).

#### .render(ctx)

Render the light (without any shadows).

#### .bounds()

Return the Rectangle bound of the light representing where the light emission limit. `{ topleft: vec2, bottomright: vec2 }`

#### .forEachSample(fn)

Apply a function fn for each light sample position. By default it’s called once with the light position.

### Opaque Objects

In _Illuminated.js_, an object which cast shadows is called an opaque object. That’s why every types inherits OpaqueObject.

DiscObject and PolygonObject are the two available primitive objects.

#### DiscObject

A “DiscObject” is basically a 2D circlar object. You must define its center **position** and its **radius**:

```javascript
new DiscObject({ position: new Vec2(80, 50), radius: 20 });
```

#### PolygonObject

PolygonObject also has some derivated classes you can use: **RectangleObject**, **LineObject**.

You can instanciate these different objects like this:

```javascript
new PolygonObject([ new Vec2(, ), new Vec2(10, 10), ... ]) // an array of points
new RectangleObject(topleft, bottomright) // topleft and bottomright positions of the rectangle
new LineObject(a, b) // an object defined by the line from a to b.
```

### OpaqueObject methods

You can easily create your own object type by implementing OpaqueObject methods.

#### .bounds()

Return the Rectangle bound of the object. `{ topleft: vec2, bottomright: vec2 }`

#### .contains(point)

Return `true` if the object contains a **point**.

#### .path(ctx)

Build the path of the object shape in a 2d context **ctx**.

#### .cast(ctx, origin, bounds)

Fill every shadows with **ctx** projected by the **origin** point in the object and in a given **bounds**.

## Lighting and DarkMask

Previous defined classes was representing datas we will now use to perform lightings and masks.

### Lighting

A Lighting defines the lighting of one light through a set of opaque objects.

```javascript
new Lighting({ light: light, objects: [ object1, object2, ... ] })
```

#### .compute(width, height)

will compute shadows casting.

#### .cast(ctx)

will draw black shadows on the **ctx** canvas 2d context.  
You usually don’t have to use it if you use `render()`.

#### .render(ctx)

will draw the light with its shadows on **ctx** canvas 2d context.

### DarkMask

A DarkMask defines a dark layer which hides dark area not lighted by a set of lights.

```javascript
new DarkMask({ lights: [light1, light2, ...], color: 'rgba(0,0,0,0.9)' })
```

#### .compute(width, height)

will compute the dark mask.

#### .render(ctx)

will draw the computed dark mask on **ctx** canvas 2d context.

### about compute and render

Both Lighting and DarkMask objects have `compute()` and `render()` methods.

We think that **you** know the best when to recompute the lights because it’s closely link to the application you are making (we will not check at each time if something has changed, you know it).  
Call the `compute()` method when something has changed in your scene so we can recompute lights and shadows.

## <a id="underthehood"></a> How does it work under the hood?

_Illuminated.js_ divides its work into several layers.

### Real-time example

<iframe src="http://gre.github.io/illuminated.js/howdoesitwork.html" border="0" height="2700" width="450"></iframe>

### The art of composing layers

The layers are all stored in a Canvas which allows us to cache it. The light is drawn using a Canvas Radial Gradient in a cache canvas only once. This is interesting because canvas gradient are processor intensive  
At the end, layers are combine on the global canvas with `drawImage`.  
But the library lets you reuse these layers to combine them the way you want.

Canvas’ `globalCompositeOperation` is very useful to compose layers together.  
For instance, in the following example, the “Light shadow casting” layer is combined with the “Light rendering” layer to generate the “Light rendering with shadows” layer. The composition mode used is “destination-out” which remove the color of the destination image where the source image has color.

```javascript
light.render(ctx);
ctx.globalCompositeOperation = "destination-out";
this.cast(ctx);
```

Another very useful composite operation is `"lighter"` which adds color values. It is used to combine two lightings.

### How shadows are projected

Some rendering engine use [ray tracing][8] to render a scene, a concept very close to physics which trace from a light source a lot of rays with different paths which will collide with object and will be subject of absorption/diffraction/reflexion in accordance with the object properties…  
Ray casting is a very **realistic** rendering solution **but consuming** (you need a lot of rays to avoid noises in the result image).  
_Illuminated.js_ doesn’t use ray tracing because it aims to be efficient for a real-time usage. It uses some heuristics for casting shadows.

#### Let’s see how shadows are projected for a polygon object.

We have a scene with a light and a triangle.

![][9]

We select each edge of the polygon which is visible by the light (and in the light bounds).

![][10]

For every selected edge, we project it to generate a polygon area.

> **N.B.** In the current implementation, we generate an hexagon projection to ensure it goes outside of the light bounds because a quadrilateral didn’t garantee it, if a light is very close to it. The projecting vector used is enough big to work for most case, but it’s still an heuristic.

![][11]

We draw black color in this polygon area. Some improvments can be made by not drawing black in the shape / ajusting the opacity of the color.

![][12]

For casting blured shadows, we repeat this algorithm for each “samples” of the light. Samples are distribute around the light with a [“spiral algorithm”][13].

![][14]

```javascript
var GOLDEN_ANGLE = Math.PI * (3 - Math.sqrt(5));
Lamp.prototype.forEachSample = function (f) {
  for (var s = 0; s < this.samples; ++s) {
    var a = s * GOLDEN_ANGLE;
    var r = Math.sqrt(s / this.samples) * this.radius;
    var delta = new Vec2(Math.cos(a) * r, Math.sin(a) * r);
    f(this.position.add(delta));
  }
};
```

## To be continued…

The current version of _Illuminated.js_ needs more work, I’m aware of some bugs and some parts I need to improve:

- Implementing new kinds of lights like “Spot”, “Neon”, …
- The dark mask doesn’t follow the Lamp orientation.
- The shadow casting of Circle objects are not projected nicely, I need to compute [tangent lines to the circle][15].
- Shadows go sometimes wrong especially when having objects behind objects
- The shadow sampling implementation is a bit hacky and wrong (changing the samples parameter changes the shadow opacity…)

## Get involved

[Try the editor][2] and [Get the source code][3].

This article is translated to [Serbo-Croatian](http://science.webhostinggeeks.com/masina-za-renderovanje) language by Jovana Milutinovich from Webhostinggeeks.com.

Illuminated.js is designed to add some awesome effects to your existing applications. Adding a cool atmosphere for your applications and games can make the difference!

Illuminated.js – 2D lights and shadows rendering engine for HTML5 applications

[2]: http://gre.github.io/illuminated.js/
 [3]: https://github.com/bgrins/spectrum
 [4]: http://www.w3.org/TR/css3-color/

<img src="/images/2012/05/color-alpha-options.png" alt="" class="thumbnail-left" />

I’m currently working on the User Interface of a scene editor for my [Illuminated.js library][2] with some color and alpha picker.

HTML5 now have the `<input type="color" />` and `<input type="range" />` which is nice. It works on Chrome and there are some [polyfills][3] to make it working on older browsers.

We will now see how we can easily **retrieve a rgba color from such an UI**, regardless of the color format given by the color picker and **combine the alpha component from the alpha range picker**.

> We can implement an **anythingToRGBA converter** in 10 lines of Javascript!

## What?

Basically, for instance, you have this: `"#ff6432"` and `0.8`

and you want this: `"rgba(255,100,50,0.8)"`

which is this color: <span style="background: #ff6432; display: inline-block; width: 50px">&nbsp;</span>.

> Well, of course, we could use a library with regexp parsers!

But there is a lot of different formats available especially if you want to convert a color from [CSS][4]!

Only for the <span style="color:blue">blue</span> color, you have at least 7 different representations: `#00F`, `#0000FF`, `rgb(0,0,255)`, `rgba(0,0,255,1)`, `hsl(255,100%,50%)`, `hsla(255,100%,50%,1)`,  
and… `blue`!

> Ouch, so let’s make a huge converter library!

Nope! 

All of these are color formats are supported by CSS and also Canvas.  
**So, why not just re-using what the browser can do?**




## How?

Because we have access to Canvas in Javascript, **we can implement an anythingToRGBA converter in a few line of Javascript**:

```javascript
var getRGBA = (function(){  
  var canvas = document.createElement("canvas");  
  canvas.width = canvas.height = 1;  
  var ctx = canvas.getContext("2d");  
  return function (color, alpha) {  
    ctx.clearRect(,,1,1);  
    ctx.fillStyle = color;  
    ctx.fillRect(,,1,1);  
    var d = ctx.getImageData(,,1,1).data;  
    return 'rgba(' [ d[], d[1], d[2], alpha ] ')';  
  }  
}());
```

You have now a ready to use Javascript color library! 

`getRGBA("#ff6432", 0.8)` will returns `"rgba(255,100,50,0.8)"`.  
`getRGBA("red", 0.5)` will returns `"rgba(255,0,0,0.5)"`.

You can “standardize” your color and use it anywhere!

**Feel free to adapt the code to any other desired format.**

We can easily make the reverse (give a rgba color and get the #RRGGBB and alpha values):

```javascript
var extractColorAndAlpha = (function(){  
  var canvas = document.createElement("canvas");  
  canvas.width = canvas.height = 1;  
  var ctx = canvas.getContext("2d");  
  
  function toHex (value) {   
    var s = value.toString(16);   
    if(s.length==1) s = "0" s;  
    return s;  
  }  
  
  return function (color) {  
    ctx.clearRect(,,1,1);  
    ctx.fillStyle = color;  
    ctx.fillRect(,,1,1);  
    var d = ctx.getImageData(,,1,1).data;  
    return {  
      color: "#" toHex(d[]) toHex(d[1]) toHex(d[2]),  
      alpha: Math.round(1000*d[3]/255)/1000  
    };  
  }  
}());
```

We can implement an anythingToRGBA converter in 10 lines of Javascript!

HTML5 Canvas as a color converter

**Did you know browsers now have a built-in HTML tag for making progress bar?**

<progress style="width: 50%">(progress is not supported)</progress>

How cool is that!

It is perfect for making web applications loading bar in just one line of HTML and a few Javascript code.

A progress tag will be displayed on recent browsers with a OS-native progress bar representing a loading. Like many HTML tag, if it is not supported, it fallbacks nicely by displaying its inner content. This fallback content should either be your own designed progress bar or simply display a percentage.

It is today supported by Firefox 9 , Chrome, Opera and IE10.



## Example

```html
<progress value="23" max="100">23 %</progress>
```

### On your browser:

<progress value="23" max="100">23 %</progress>

### On Linux / Firefox (with GNOME)

![](/images/2012/04/progress.png)

### On Mac OS / Chrome:

![](/images/2012/04/progress_mac.png)

### On IE 6:

![](/images/2012/04/progress_ie.png)

## Let’s see some cases:

### waiting

<progress max="1000"></progress>

```html
<progress max="1000"></progress>
```

### starting

<progress value="0" max="1000"></progress>

```html
<progress value="0" max="1000"></progress>
```

### in progress:

<progress value="500" max="1000"></progress>

```html
<progress value="500" max="1000"></progress>
```

### finished:

<progress value="1000" max="1000"></progress>

```html
<progress value="1000" max="1000"></progress>
```

## Making a download bar

When you need to load big resource like images, videos, or 3D materials, you usually want to display the progress of the download.  
You could still do it using some divs and CSS Javascript, but this is now much simpler to use a :

### One line of HTML:

```html
<progress id="download"></progress>
```

### And the Javascript:

(for more convenience, we are using jQuery)

```javascript
var totalBytes = 10000000; // CHANGE ME WITH THE SIZE OF THE RESOURCE
var req = new XMLHttpRequest();
var progress = $('#download');
progress.attr("max", totalBytes);
req.addEventListener("progress", function (e) {
  progress.attr("value", e.loaded).text(Math.floor(100*e.loaded/totalBytes) " %");
}, false);  
req.addEventListener("load", function (e) {
  // THE RESOURCE IS LOADED
  progress.replaceWith("Downloaded!");
});
req.open("GET","resource.dat",true);
req.send();
```

It is quite easy to extend my code to support multiple files to download.

It is also easy to use this progress bar for anything else, but remember it represents a progress. If you want to represent some kind of stats, refer to the dedicated tag.

A progress tag will be displayed on recent browsers with a OS-native progress bar representing a loading.

Work in <progress />

#

A long time ago, video games were only two-dimensional. Of-course this was due to our poor hardware capabilities, but when computers became faster and faster 3D games appeared in mass.  
**Did it kill 2D games? Nope.** They continue to exist because it offer a different gameplay and are easier to make. Maybe also a bit because we are nostalgic of old-school games!

We can distinguish two kinds of 2D games:

<img src="/images/2012/04/bomberman93.jpg" alt="" class="thumbnail-left" />
[**Tile based games**][2] where the game world is simplified with a big grid – each grid position has some properties.  
A map editor is not always needed for tile based games, because the map can be straighforward to represent and maintain like in a *Bomberman* or in a *Pacman*. A simple editor is generally used to make graphism with sprites.

[2]: http://www.tonypa.pri.ee/tbw/tut00.html
[4]: http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/
[5]: http://www.masswerk.at/JavaPac/JS-PacMan2.html
[6]: http://impactjs.com/documentation/weltmeister
[7]: http://gre.github.io/blazing-race
[12]: http://gre.github.io/blazing-race/maps/converter/

<br style="clear:both" />

<img src="/images/2012/04/woarpc001.jpg" alt="" class="thumbnail-left" />
**Non-tile based games**, which can be called “polygon based games” are more complex.  
In such game, like a *Worms* or a *Sonic*, it’s totally crazy to write the map by hand (objects positions, polygons coordinates, …). The alternative, is not to use predefined maps, but on-the-fly generated maps which doesn’t fit every games.

<br style="clear:both" />
  
[Here are more detailed work on these different game designs][4].

**Making the game engine** is one thing, but **designing the game levels** can be one big work too and **we need tools to make it easier**.



## Tile based game maps

In tile based games, maps are usually quite simple to represent.

For instance, here is how we can code the maze of [Pacman][5]:

```javascript
[
  "ahhhhhgxbhhdxehhhhhc",
  "vp....o......o....pv",
  "v.lhm...lhhm...lhm.v",
  "v.....n......n.....v",
  "v.n.n.v.ahhc.v.n.n.v",
  "d.v.o.v.vxxq.v.o.v.b",
  "x.v...v.vxxt.v...v.x",
  "c.bhm.o.bhhr.o.lhd.a",
  "v........x.........v",
  "em.lc.am.lm.lc.am.lg",
  "v...v.v......v.v...v",
  "v.k.o.o.lhhm.o.o.k.v",
  "vp................pv",
  "bhhhhhcxahhcxahhhhhd",
];
```

where every character is a tile and has a given meaning.

For more complex games, we can also represent the map with a set of objects, and each object has position and size properties (x, y, width, height) and other properties for the game logic.

For instance, see the _ImpactJS_ tile based games editor:

[![](/images/2012/04/weltmeister-tutorial-entities.png)][6]

## But what about polygons based game?

Well, some have tried to make dedicated 2D game map editor like shown in this video:

<iframe width="640" height="360" src="http://www.youtube.com/embed/kvvEmm2Vyoc?feature=player_embedded" frameborder="0" allowfullscreen></iframe>

but it sounds a bit unfinished and specific.

### Do it yourself, but don’t reinvent the wheel.

**But finally, isn’t it what a 3D editor is doing?**

Isn’t it the most generic tool we can find?

They have done a lot of awesome work in term of user interface, polygon modeling, textures (procedural / bitmap), …let’s profit of all this work to generate awesome texture map while exporting polygons.

Relying on such tools, you don’t have to learn a brand new map editor, you can relax on what you know if you have the chance to know Blender or Maya or anything.

### The Z magic

Let’s ignore the Z dimension, or rather, let’s **use the Z-dimension as a way to represent the semantics of the game map!**

This is the map I made for [Blazing Race][7], a HTML5 against-the-clock platform game where you control a fireball:

![](/images/2012/04/zs.png)

For my game needs, I used **different Z layers to represent different kind of materials and game objects**:

- z=1 : candles’ position – the objective of the game is to light them all
- z=0 : the game grounds – where collision occurs
- z=-1 : the water areas – where your flame dies
- z=-2 : special areas where you miss oxgyen – your flame dies in a few seconds

But I also used **objects ids** as an another way to distinguish objects:  
a “start” object to define the game start position and two “topleft” and “bottomright” objects to define the game bound.

### Maintain your map source in one file

Another powerful feature of this, is you can maintain your map polygons AND your map textures in a single way. Use your 3D editor as a polygon editor and use its render engine to generate textures:

![](/images/2012/04/map1.png)

Take benefits from what your 3D editor can do.

### Export polygons to the Javascript game

![](/images/2012/04/path4850.png)

I’ve made a transformer which take a COLLADA file in input (the most commonly supported standard format to describe a 3D scene, you can export it from any 3D editor like Blender, Maya, 3DS…) which extract and transform relevant informations from it and give you a json map for your game in output.

_It was quite simple to implement, thanks to the Three.js COLLADA importer!_

Here is the current (unfinished) interface for this:

[![](/images/2012/04/demo_screenshot.png)][12]

As a proof of usability of the output JSON map, the preview was only made in a few lines of Javascript code.

Extract:

```javascript
function draw(map) {
  var container = $("#viewport").empty();
  $("#legend").empty();
  a = 0;
  var w = 500;
  var h = Math.floor((w * map.height) / map.width);
  var CROSS_SIZE = 3;
  var canvas = $('<canvas width="' + w + '" height="' + h + '"></canvas>');
  var ctx = canvas[0].getContext("2d");
  for (var name in map) {
    var objs = map[name];
    if (objs[0] && objs[0].faces) {
      var color = randomColor(70, 0.8);
      ctx.fillStyle = color;
      for (var i = 0; i < objs.length; ++i) {
        var obj = objs[i];
        for (var f = 0; f < obj.faces.length; ++f) {
          var face = obj.faces[f];
          ctx.beginPath();
          for (var v = 0; v < face.length; ++v) {
            var vertice = obj.vertices[face[v]];
            var x = (ctx.canvas.width * vertice.x) / map.width;
            var y = ctx.canvas.height * (1 - vertice.y / map.height);
            if (v == 0) ctx.moveTo(x, y);
            else ctx.lineTo(x, y);
          }
          ctx.fill();
        }
      }
      addLegend(color, name, true);
    }
  }
  for (var name in map) {
    var objs = map[name];
    if (objs[0] && objs[0].x) {
      var color = randomColor(50);
      ctx.strokeStyle = color;
      ctx.lineWidth = 2;
      for (var i = 0; i < objs.length; ++i) {
        var p = objs[i];
        var x = (ctx.canvas.width * p.x) / map.width;
        var y = ctx.canvas.height * (1 - p.y / map.height);
        ctx.beginPath();
        ctx.moveTo(x - CROSS_SIZE, y);
        ctx.lineTo(x + CROSS_SIZE, y);
        ctx.moveTo(x, y - CROSS_SIZE);
        ctx.lineTo(x, y + CROSS_SIZE);
        ctx.stroke();
      }
      addLegend(color, name, false);
    }
  }
  container.append(canvas);
}
```

## What is next?

Blazing Race, is not finished yet, I need to improve a lot of things.

I’ll try to release a standalone version of this converter soon with tutorials and examples.

Here is how you can design and export your 2D game map with Blender (both the logic and the graphics).

Blender as a 2D game level editor – Proof Of Concept

One week ago, I’ve released a [technical web experiment][1] featuring **a collaborative real-time Paint-like application I’ve called Play Painter**. It has been made with [Play Framework 2][2] and rely on WebSocket and HTML5 Canvas Javascript APIs.

[1]: /2012/03/30-minutes-to-make-a-multi-user-real-time-paint-with-play-2-framework-canvas-and-websocket/
[2]: http://playframework.org/
[4]: https://github.com/playframework/Play20/wiki/Iteratees
[5]: https://github.com/gre/playpainter/blob/master/scala/app/controllers/Application.scala
[6]: http://github.com/gre/playpainter
[7]: http://playpainter.greweb.fr/
[8]: https://github.com/gre/playpainter/issues/1
[9]: https://twitter.com/dbathily

Thanks to everyone having tested my Play Painter experiment, you helped me figure out bugs and bottlenecks and to benchmark the application running on my tiny server.  
The first version of Play Painter has been improved with some optimizations.

Explanation…

<blockquote class="twitter-tweet" lang="fr"><p>Thanks guys for testing playpainter! but you are breaking my server :D <a href="http://t.co/F62qwk1i" title="http://twitter.com/greweb/status/179194592481116160/photo/1">twitter.com/greweb/status/…</a></p>&mdash; Gaëtan Renaudeau (@greweb) <a href="https://twitter.com/greweb/status/179194592481116160">12 mars 2012</a></blockquote>



## In brief

- **80 twitts**, **3500 unique visitors** in a few days.
- a peak of about **80 simultaneous painters**.
- about **200 WebSocket messages per second** when 3-4 users are drawing => bottleneck found.
- when it occurs, 100% CPU and about **1500 system interrupts per second** on my poor Atom 1.2 Ghz server.

## Some reasons

The initial version of Play Painter was a basic fast-prototyped version:

First, It was **spreading every mouse events** (down, up, move) to all clients **as fast as it comes**. It means that, depending on the computer and browser performance, a huge number of events could have been triggered and spread to all connected users.

We solved this by **Chunking draw events**.

Second, **a lot of informations was repeated in WebSocket messages.** No datas were stored on the server-side so to be sure a new user see the right draws, player name, brush color and size was sent in every message. Multiply this by the number of mouse events and you get a lot of useless information!

We are now **Storing painters information**.

## Chunking draw events

When an user starts drawing, mouse events give the brush positions (x, y). But instead of sending a websocket message for each of these new positions, they are stored, and every **X** milliseconds, are sent in a websocket message. Such message contains all points of the draw from the last sent draw message.

The **X** value has currently been fixed to **50 milliseconds** because it’s enough for the human eye: It means about 20 messages per second for one painter. In movies we usually have a 24 frame rate.

The same principle has been applied on the painter brush positions.

### Example

**Before**  
13 WebSocket messages:

```javascript
{"type":"lineTo","x":181,"y":259,"pid":19}
{"type":"lineTo","x":183,"y":259,"pid":19}
{"type":"lineTo","x":184,"y":257,"pid":19}
{"type":"lineTo","x":187,"y":257,"pid":19}
{"type":"lineTo","x":188,"y":257,"pid":19}
{"type":"lineTo","x":191,"y":256,"pid":19}
{"type":"lineTo","x":192,"y":255,"pid":19}
{"type":"lineTo","x":192,"y":255,"pid":19}
{"type":"lineTo","x":192,"y":254,"pid":19}
{"type":"lineTo","x":193,"y":254,"pid":19}
{"type":"lineTo","x":195,"y":254,"pid":19}
{"type":"lineTo","x":196,"y":253,"pid":19}
{"type":"lineTo","x":196,"y":253,"pid":19}
```

**After**  
2 WebSocket messages: (50 ms apart)

```javascript
{"type":"trace","points":[{"x":181,"y":259},{"x":183,"y":259},{"x":184,"y":257},{"x":187,"y":257},{"x":188,"y":257},{"x":191,"y":256},{"x":192,"y":255}],"pid":19}
{"type":"trace","points":[{"x":192,"y":255},{"x":192,"y":254},{"x":193,"y":254},{"x":195,"y":254},{"x":195,"y":253},{"x":196,"y":253},{"x":196,"y":253}],"pid":19}
```

### To a variable frame rate?

I am also thinking about a variable rate depending of the number of active painters. In fact, the more we have painters, the more we will have messages, and the more the server will have system interrupts, we could then decrease the frame rate per second to reduce this load.

The problem of this extreme approach is the degradation of the feeling of real-time.

For now, I’m keeping the constant frame rate version, we will see how far it goes.

## Storing painters information

As I said, **a lot of informations was repeated in WebSocket messages.** In every draw events, painter name, brush size and brush color was sent from the client to the server, and the spread into all connected clients.

This was ok for prototyping but we have now optimize this by storing these painter generic informations in the server and sending them when a new WebSocket connection is opened.

### Example

This is what a client can receive when a websocket is connected:

```javascript
{"type":"youAre","pid":24}
{"name":"john","color":"red","size":5,"type":"painter","pid":21}
{"name":"gre","color":"red","size":5,"type":"painter","pid":24}
{"name":"peter","color":"red","size":5,"type":"painter","pid":4}
{"name":"paul","color":"red","size":5,"type":"painter","pid":6}
{"name":"jack","color":"red","size":5,"type":"painter","pid":2}
```

and then…

```
{"type":"trace","points":[{"x":181,"y":259},{"x":183,"y":259},{"x":184,"y":257}],"pid":19}
...
```

By knowing all painter properties, when someone will draw something, he will not have to repeat which color and size its brush has.

### Server side

It was quite interesting to implement the server part with [Play2′s Iteratees][4], a new way of handling I/O – not so new in fact because it is directly related to Haskell Iteratee concepts.

To implement a WebSocket connection, you will provide an **Iteratee** for consuming the **input** and an **Enumerator** for producing the **output**.

Enumerator are chainable, this is how I firstly send the painter id and painters informations:

```scala
// out: handle messages to send to the painter
val out =
  // Inform the painter who he is (which pid, he can them identify himself)
  Enumerator(JsObject(Seq("type" -> JsString("youAre"), "pid" -> JsNumber(pid))).as[JsValue]) >>>
  // Inform the list of other painters
  Enumerator(painters.map { case (id, painter) =>
    (painter.toJson JsObject(Seq("type" -> JsString("painter"), "pid" -> JsNumber(id)))).as[JsValue]
  } toList : _*) >>>
  // Stream the hub
  hub.getPatchCord()
```

The **>>>** operator is a shortcut to the **andThen** method which is the way to chain enumerators.

For more details, [see the scala code of the controller][5].

## Other features

The application has been improved in many other ways.

- **A “buffering” Canvas** in the foreground has been add **for the user draws**. It brings client-side reactivity and helps to avoid unpleasant lag feeling when drawing. When the user draw events are coming from the server and no other user events has been sent since, it’s synchronized and we can clean this buffer.
- **Painter positions are show with their names**.
- It should now work properly on **smartphones and tablets**. Try on iPad and iPhone, and maybe on recent version of Android (WebSocket support required).
- **Keyboard shortcut**: using arrows to change brush size and color.
- The **[source code][6] has been polished and commented** especially the server side part (it’s probably the hardest part if you don’t know Play framework).
- Error message displayed when a technology is not supported and when the WebSocket connection goes down (with a reconnecting try loop).

## The demo is still online!

**[playpainter.greweb.fr][7]**

## Future

With these two optimizations, I’ve reduce the global **number of socket messages** and also the **size of each message**.

The first benchmark sounds good, 3 painters was simultaneously crazily painting while the server application was only using less than 10% of CPU.

Now, the most challenging part would be to scale the application to a huge number of connections, but having maybe solved this bottleneck, it’s maybe now more a matter of system architecture than the application itself.

This experiment gave me a lot of interest in **WebSocket** and also in **the powerful way WebSockets are handled in Play framework**.

If anyone want to start a Java version of the application, please go on! [(this was requested on Github)][8]

Thanks to [@dbathily][9], we know have both Scala and Java version!

### Next experiment

I am thinking about making a multiplayer game on the web.  
It would be something like a shooter survival game (like Counter Strike Zombie Mod) a multi-plateform 2D side view game (like Mario) !

You will know more about this soon!

One week ago, I’ve released a web experiment featuring a collaborative Paint-like application made with Play Framework 2 and relying on WebSocket and HTML5 Canvas. Here is how I've improved it.

Play Painter – how i've improved the 30 minutes prototyped version

[1]: http://playpainter.greweb.fr/
 [2]: http://playframework.com
 [3]: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html
 [4]: http://dev.w3.org/html5/websockets/
 [5]: /2012/03/play-painter-how-ive-improved-the-30-minutes-prototyped-version/
 [6]: https://github.com/gre/playpainter

[  
<img src="/images/2012/03/playpainter_teaser2.png" alt="" class="thumbnail-left" />
][1]

> I will show you how to **implement a multi user paint** using latest web technologies like [Play framework][2] (version 2), [HTML5 Canvas][3] and [WebSocket][4].


Let’s see how to implement this from scratch in about 30 minutes…

<iframe width="640" height="360" src="http://www.youtube.com/embed/NHEbm-WEbRw?feature=player_embedded" frameborder="0" allowfullscreen></iframe>



[and read how I’ve improved this initial version…][5]

[or try the demo below…][1]

<iframe frameborder="0" src="http://playpainter.greweb.fr/" width="550" height="501" style="overflow: hidden; max-width: 550px"></iframe>

[Fork me on Github.][6]

[VIDEO] I will show you how to implement a multi user paint using latest web technologies like Play framework (version 2), HTML5 Canvas and WebSocket.