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
• Open other examples
• API Documentation
• Fork me on Github
• Unit tests

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? 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:

// 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:

// 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()

TL;DR. 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). Here’s an overview:

Links

• The scala API.
• PlayCLI source code (Github).
• PlayCLI Examples application (Github).

SBT

"fr.greweb" %% "playcli" % "0.1"

@greweb : Let's do a kickstarter to build the 1st space rocket running on embedded Javascript... I think we can discover new physics rules!

— mandubian (@mandubian) 10 janvier 2013

It is common 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.

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:

10000000000000000 === 10000000000000001

Oh F**K !

[edit] where in python:

Termination of loops

The following is worse:

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!

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.

Now, let’s see how easy it is to serve a big Zip generated on-the-fly without memory load with Play Framework.

Last Friday was HackDay #7 at Zenexity, and we decided to work on a real-time audio experiment made with Play Framework. The plan was to use an audio generator (JSyn, an audio synthesizer), encode the output and stream it all using Play Iteratees to pipe everything in real-time.

First of all, let’s highlight some interesting part of the project, then get into some of the details.

Thanks to @Sadache for his Iteratee expertise, we ended up with a simple line of code that does all of the hard work:

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:

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:

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‘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…

Last week was the 7dfps challenge, 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.

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!

“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:

and you can play it here:

Play the game

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 to minimize a Javascript file with only cURL.

Click on the image to open it!

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 and Get the source code.

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
• Technical notes – how does it work?

I’m currently working on the User Interface of a scene editor for my Illuminated.js library 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 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:  .

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!

Only for the blue 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?