Just have a look at Gameslabor: Warum HTML5 auch für Games interessant ist.

Never the less I would like to share some experiences concerning object orientation in JavaScript. Many of you may remember JavaScript as the technology which enhanced HTMLs abilities to the worst. Responsible for pop-ups, evil cookies with a touch of annoying procedural syntax. You better forget about that quickly. JavaScript has become a quite powerful language, not only when it is about client side development. And only because many developers are still excellently ignoring the languages possibilities in case of object oriented programming doesn’t mean, that there aren’t any.

JavaScript is using so called prototyping for it’s object instantiation. Yes, using object orientation might be several times slower than just writing procedural code. But as history has proven, there are many good reasons for object oriented code design. Have a look at the following example code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

MyProject = {};
 
MyProject.Foo = function() {
      this.initialize();
      return this;
}
 
MyProject.Foo.prototype = {
	// called by constructor
	initialize : function() {
	   this.message = 'foobar!';
        },
 
        // instance method
	bar : function() {
		alert(this.message);
	}
}
 
// main
var obj = new MyProject.Foo();
obj.bar();

There are some other possibilities for writing the object code. I did choose this one over the others, because it’s compact, clean and probably the best performing way. If you are familiar with other languages using the object oriented programming paradigm, you might have recognized some differences. The code doesn’t seem to have a classic class declaration syntax. Instead of this the code has been split up into three important parts. The line MyProject = {}; isn’t really necessary but very helpful to keep track of your classes when a project grows bigger. It’s the DIY way of creating a namespace alike structure. The empty curly braces are JavaScript specific syntax for creating empty objects. It’s the simplies way to create objects or dictionary data scructures. JavaScript as well as ActionScript (ECMA Hooray!) doesn’t differentiate at that point, because JavaScript doesn’t depend on static types. That enables you to link every type of language element into the pseudo-namespace at every time. That’s exactly what’s happening in line 3: MyProject.Foo = function() {…}.

These lines simple create an attribute or the object represented by the MyProject variable, actually behaving as Namespace. The Value of MyProject.Foo will be a function, which only job it is to call the this.initialize() method. Speaking of object oriented theory, this is the object construtor. It’s just calling an initialization method and returning itself to the caller. Yes, exactly itself. Therefore we need to combine the call of MyProject.Foo() with the new statement in front of it. That creates a new copy of any given object, as you can see in line 21.

Lines 8 to 18 are containing the prototype implementations of the MyProject.Foo class. Watch out for the leading this. in front of every access to functions or variables of the current instance. Unlike Java or ActionScript for example, JavaScript doesn’t auto detect the function of variable scope by itself. Every call without scope declaration, will be executed within the current function scope.

Phew, pretty much to handle yet. As you can see, there are a lot differences between object orientation as we know it by languages like Java, Ruby or C++ and JavaScript. But at least there are only a few basic principles that you may keep in mind when developing JavaScript the OOP way:

• JavaScript objects are extendable at runtime
• Prototypes instead of static typed classes
• Always declare scope when calling attributes/methods
• Use the new keyword to create instances of prototype objects.

3d computer graphics in web applications seem to be still a topic thats is heavily associated with technologies like flash, shockwave or other plugin based platforms. This may become history soon. At least if the development of WebGL browsers will proceed as it currently does. If you already use a WebGL enabled browser and had a look at one of the several examples as they appear constantly on http://learningwebgl.com/, then you will figure out quickly what I’m talking about.

Beside the usual operations we are familiar with from nearly any 3D engine, the most Important part on WebGL seems to me that we are able to use vertex and fragment shaders in the usual native way. While the whole application code is written with JavaScript, the shader programs will be implemented in a C style shader code. In the end nothing special for OpenGL veterans. But hey! Exactly that’s the point! If you’ve ever developed your personal, most awesome shader ever, there’s the possibility to reuse or partly use them for WebGL. There’s an amazing experiment written by Inigo Quilez about this shader topic. It’s called Shadertoy (don’t forget to use a WebGL enabled browser). The Shadertoy website, currently offers you about 28 sample shaders of different kinds. All are looking very pretty and all are native shader programs, which are executed on the graphics accelerator. Hardware acceleration for Webapps: Just great!

The basic possibilities offered by this technology may end into enourmous impacts for webstandards. You already may have recognized the Flash Gordon Project of Tobias Schneider. His approach is to implement an open source flash runtime, written in JavaScript. Imagine this implementation, using the powers of GL rendering. Or ways better: a new runtime plattform using WebGL as rendering layer.

Enough of nerdy enthusiastic day dreaming. There are still some difficulties with WebGL. At first of course, the minor density of WebGL enabled browsers out there in userland. But there’s a silverline on the horizon: last September Mozilla announced to implement WebGL in future versions of Firefox. The current nightly builds yet implement it, but it’s disabled by default. So it’s just a matter of time, when WebGL will be available easily by default.

Second flaw: It is quite uncomfortable to keep track of all matrix transformations by yourself. Bare WebGL won’t do that job for you. Many examples on the internet (including the Learning WebGL lessons) implement their own helper functions for identity loading, by encapsuling Sylvester (vector and matrix math for JavaScript) routines. That’s a common but never the less hacky way to fix the problem. And even creating simple basic shapes still produces a lot of code. Many shaders are embedded directly into HTML code, like it is well know from CSS or JavaScript embedding. That feels pretty ugly, when you’ve a complex WebGL application in mind.

In my opinion, the best solution for this case is WebGLU by Benjamin DeLillo. This library is a set of frequently high usefull routines for developing your very own WebGL application. You can load externalized Shader code, enjoy the ease of a camera and many more fine features.

So if you are interested into WebGL now, you should have a look at Learning WebGL. It’s in my opinion one of the best and most up to date resources on the net. If you are interested in the papers and basics of the new standard, it’s the best to search The Khronos Group website for further information.

If you’ve any other interesting news or resources for WebGL, please leave a comment or message me on any of the known ways.

Okay, everybody stay calm now, there’s no reason to panic: I got a new showcase! Yes, it’s a brand new one. Please… ladies and gentlemen, please! Let’s behave like well civilized people. There’s enough for every single one of you.

After my last showcase went broken some months ago, I promised to myself to create new one next (actually THIS) year. You may see the results at http://www.abakia.de/showcase/. I made heavy use of native flash features, as well as of my interactive framework called Monosodium.

So actually this is also a double release party. When I started developing ActionScript Flash in 2008, I also began to collect often used chunks of code and glued them to build a giant tar ball of death. No, that’s not what the framework is actually made of. In late 2009 I throw away the prototype and started to create a better version of the old framework library collection… frankenstein monster.

The rewrite resulted in a lightweight and easy to use flash framework, for creating view based interactive flash apps. There’s probably nothing ground shaking with this framework but it’s my very personal 2 cent and “thank you” to the flash community itself. The project is still lacking some documentation. But I’m working on that as I continue integrating features and refactoring the code. Yes, the framework is still under heavy development. You know the game’s name: commit early, commit often and listen to the audience.
So if you’re interested in the framework, please give me some feedback on that.

Special thanks goes out to Sebastian Deutsch (9elements), for supporting me while developing Monosodium in the early stages.