Update: Stephan recommended to put the video on top,  so here it goes: Some impressions from RavenJS, enjoy (fullscreen and headphones recommended)!

The Beginning

When we started, I had little to no knowledge about working with 3D and OpenGL – I’m a JavaScript guy, after all. When I first fired up Blender and tried to work with it I was pretty close to dropping the whole idea again. Same happened when I saw how shader code looked like. But I so much wanted this – and the existing wrappers like GLGE or three.js enable us to still work with WebGL even if we don’t have the background knowledge.

So I decided to go with GLGE as I had already played around it with it’s examples before and because it already had nice collada support, which I decided to have as format for meshes and animations.
The first step was to extract some assets from the original game, collect mesh and texture data and get it into Blender. Luckily, Gothic has a highly active modding community, and this community is supported by the original game developers. So there were a couple of tools that could be used to aid in this, and it didn’t take long and we had a sword rotating in a browser.

But if it was possible to load a sword into GLGE, then shouldn’t it also be technically possible to load parts of the world into it? Yes, it was. It took some time, and it’s still far from perfect, but it worked. The next step was to create a first person camera that would react to mouse and key events – and had collision detection. Real collision detection, a height map would get us nowhere, as the levels had bridges and indoor locations, and I needed moving objects, too. Luckily, GLGE had some demos using raycasting to achieve this that I could use as start and modify until it worked as needed.

To recreate the dark intense atmosphere I played around with the right ambient lighting, fog types and added a sky box. Well, I would have loved to have a real sky dome, but, alas, I have no idea how to do this… Finally, I added objects, both static and animated.

In action

I can’t and won’t put online a live demo, as I obviously have no rights to do so. The copyright of the meshes and textures used belongs to the original developers, Piranha Bytes, and the RavenJS project is in now way endorsed, encouraged or supported by nor affiliated with them. But I can show you some impressions of what it looks like so far (fullscreen and headphones recommended):

Update: Video is now on top

(The song in this video is called “A special thing” by “amanyth” and published under a Creative Commons license.)

Issues

Besides the mere amount of free time that is needed and lacking, there are currently four main issues that are a bit of a show-stopper:

Animations caused a big deal of problems, and it’s still not prossible to run more than one animation sequence – running multiple animations will screw up bone position. While the animations still run fine in Blender, something goes wrong during the export. I’m still to find out if this can be overcome by using an alternate format for export.

Another thing that is still unsolved is “double-faced textures” that have transparent parts (look at the trees in the video). Those transparent parts become plain black when rendered in the browser. I’ve read up on this, and it seems that this scenario is indeed not trivial… From what I understood so far, in our case there’s two shapes “glued” to each other and each one has its own material, but I still have no idea what exactly goes wrong.

A real biggie, performance-wise, is that there is no logic yet that handles display of objects that are not visible. In the original game e.g., doors and the likes are “closed” by vertices with solid (non-transparent) textures and everything that’s behind it is taken out from the whole rendering/object interaction/whatever process. Only when you get really close you can see through these and see the intereour of the adjectant room. If these vertices get actually removed or if you “portal” through them I don’t know.

Mouse lock. Of course. No further explanation needed, we’re all looking forward to seeing this in the browser.

Future

I always loved 3D games. And the fact that it’s possible to render 3D worlds in a browser – with acceptable performance – is just stunning. The majority of work is still ahead, I’m well aware of that, but I *so much* want this to happen… So I just hope that some of the major problems can be solved and this project can go on!

Update II: Ben Hockey proposed to do the whole thing without using the pub/sub system. I for one think its a good idea, but in case you want the topic version, I’ll leave the test page and add another one with the topic-less version. Thanks Ben!

Update III: Dojo 1.5 introduces robust Promises with dojo.deferred as Krys Zyp explains in this SitePen post.

—

One of the things/ideas/concepts that I really like about CommonJS is Promises.

Promises? A brief explanation from the CommonJS API:

Promises provide a well-defined interface for interacting with an object that represents the result of an action that is performed asynchronously, and may or may not be finished at any given point in time.

To hear more about Promises, I highly recommend these two posts.

That concept is not entirely new. The dojo toolkit has dojo.Deferred, which does a similar job. You create a Deferred, add (multiple) callbacks and error handlers to it, and when it fires off, all your handlers get called. But dojo.Deferred is pretty heavyweight. It’s loads of code. And it works with .addCallback() and .addErrback() methods – not with .then() methods, which provide maximum readability.

The goal

What I want to have is the follwing code running (with dojo):

asyncComputeTheAnswerToEverything().
    then(addTwo).
    then(printResult, onError);

(This is the example code from the proposed CommonJS Promise API)

And I want the execution to continue right after doSomethingAsnyc() – the async call should still be non-blocking. The .then() methods should recieve the results of the previous part of the chain, but still be non-blocking. Luckily, dojo provides a tool that allows us to achieve this: the publish/subscribe system.

Let’s do it

When we have unique topics for each promise made, we can subscribe the .then() method to the current topic in the chain, and publish the next topic when the data handlers are done computing. Within the then() method we need to check if the data we recieve is an error or not, to determine wich handler we need to call. The spec also demands a progress handler – if we wanted to implement that, we needed to add another topic, but I left that out.

We only need to kick off  the whole thing when we create the first promise, then the rest takes care for itself. Including the changes proposed by Micheil, what you have to do is pretty trivial and you don’t have to care about unique topics or the pub/sub system at all. The asyncComputeTheAnswerToEverything() function mentioned above would look like the following:

var asyncComputeTheAnswerToEverything = function(){
	var promise = new dojox.Promise();
	window.setTimeout(function(){ // some async operation
		var data = 42;
		promise.emit(data);
	},2000);
	return promise;
};

You create a Promise and store a reference to it. You return the promise and use the reference to it to kick off the chain when the data is there. Everything else runs on it’s own now.
Go to the test page or theand check the source – it contains the Promise code and the example functions. Open the console and run testSpec(); to start off the example code from the CommonJS API proposal.

Usage

As a namespace to put the Promise into I chose dojox – but choose whatever floats your boat. You can just drop the promise code somewhere into your code, or, if want to dojo.require("dojox.Promise") it, create a file named Promise.js that contains the code and place a dojo.provide("dojox.Promise"); as the first line in it. Save the file in the dojox directory and you’re done. (Well, to be honest, this violates the dojox naming convention, but if its just in your project, it’s ok and it will work.)

Any questions left? Feel free to leave a comment, @ me at twitter or drop me a line.

References / Files / More

• CommonJS Promise API Proposal
• Post by Kris Zyp @ SitePen blog about CommonJS
• Post on www.michaelharrison.ws about promises and more
• the test page (using topics and pub/sub)
• the test page (w/o topics, recommended)

The Curve

Every dojo.Animation needs a curve. If you call animateProperty or it’s shorthand anim, you don’t have to provide the curve for yourself, dojo will do it for you – if you build an animation using new dojo.Animation(), you have to provide your own curve. You can think of the curve as of a line that the animation walks on. The line is already present before the animation starts to walk it, and it can always take a break and pause in the middle and eventually continue walking where it had stopped. To create a curve, you need to call new dojo._Line(start, end). In return, you get an object with three properties: end, start and a getValue() method.

var anim = new dojo.Animation({
	curve: new dojo._Line(0,100)
});

Easing

The curve will then be modified by a easing function. By default, this is the linear dojo._defaultEasing. Easing breathes a bit of life into the curve, you can say. Other properties of dojo.Animation that affect the curve are rate and duration. rate is the timespan between two frames. To calculate the targeted fps, use (1000/rate). By default, dojo aims at 50 fps.

var anim = new dojo.Animation({
	curve: new dojo._Line(0,100),
	easing: dojo.fx.easing.quadInOut
});

Waking Life

To get some numbers out of dojo.Animation, let’s let it go wild and play(). When using animateProperty or the likes, you just fire and forget. In our case, we need to get the numbers. To achieve this, we connect to our animation’s onAnimate event. This is fired on every frame of the animation. When your connected function is called, you get – who would have guessed – the current value of the curve. Now you have a function called at a given rate, for a given period of time and you get get a numeric value that is already calculated for you. Decent!

dojo.connect(anim,'onAnimate',function(curveValue){
	// do something
});

To see some curves in action, go to this test page, open the console and type play(1); and play(2); and check the source code to see what’s happening.

Multidimensional Curves

dojo._Line generates only one-dimensional curves. But, there is dojox.fx._core, which contains an (old) version of dojox.fx._Line, which is capable of creating multi-dimensional curves. To use it, you have to explicitely dojo.require("dojox.fx._core"). It’s a bit odd, but the _core file contains only the _Line, and it is not loaded when requiring “dojox.fx”. Well, whatever, you can pass arrays of numbers into dojox.fx._Line:

new dojox.fx._Line([0,2],[100,6]);

Now you have a multi-dimensional curve. Or, if you could say, you have two curves in one. You can (technically) pass an unlimited amount of numbers into dojox.fx._Line. When you hand this curve to a dojo.Animation, it will animate all dimensions of the curve. And it will modify all dimensions of the curve according to easing, rate and duration. If you connect a function to onAnimate, it will now recieve an array of numbers.

var anim = new dojo.Animation({
	curve: new dojox.fx._Line([0,2],[100,6]),
	easing: dojo.fx.easing.quadInOut
});

Head over to the test page again, and type play(3); into the console. Now, the width of the bars is also animated – by the same animation function that calculates the height of the bars.

What now?

If your mind is still not blown away with ideas about how to use this, let me give you a start:

• animate position, width and height of a browser window and use it as a screensaver for some unknowing, yet thankful visitor…
• take some CSS 2D and 3D transisitions/transforms and animate away…
• canvas! No need to say another word…
• Still too banal? Go WebGL! Grab some 3DContext and animate an evil ball of jelly jumping around!

In short: dojo’s animation system allows you to not only animate CSS properties, but gives you a good tool for  animations in general. You get the curves on the one hand, but you also get the “player” for these curves, including play/pause/stop/gotoPercent methods. And dojo.fx.easing has a lot of easing functions in stock.

Besides indexOf(), there are some other ways to achieve this, so – let’s have a competition and find out who’s the fastest!

The Contestants

replace and length

One possibility is to replace the searched string with an empty string, read the length property of the modified string and compare it to the length of the haystack. If it’s different, the haystack contains the needle. Reading the length property is extra work, but comparing two integers is faster than comparing two strings, so maybe it’s faster in general.

replace

Again, replace the searched string with an empty string. Then compare the the modified string with the haystack. If they are different, the haystack contains the needle.

split

Take the haystack and try to split it using the needle as the seperator. If the result’s length is greater than one, the haystack contains the needle.

indexOf

Find the first occurance of needle in haystack; if the result is something else than -1, the haystack contains the needle.

Results

For testing, I did 10,000 iterations and retrieved the execution time in ms. The methods were tested in the order presented above.

On Chromium (Mac build, Version 4.0.203.0 here), replace + length is slightly faster than replace, and both are faster than split. indexOf is by far the fastest.

1) true: 7 / false: 3.5
2) true: 7.5 / false: 3.5
3) true: 10 / false: 8
4) true: 2.5 / false: 3

Safari 4 has nearly the same results as Chromium, but the numbers tend to differ a lot from test to test.

1) true: 4-18, avg 10 / false: 2.5
2) true: 4-19, avg 10 / false: 3
3) true: 6-22. avg 13 / false: 6-23 avg. 16
4) true: 2 / false: 3

On Firefox 3.5, split a bit faster than the two replace methods, but indexOf is again by far the fastest.

1) true: 13 / false 10
2) true: 13 / false 10
3) true: 10 / false 9
4) true: 1.5 / false: 2

On IE 8 (run in a VM), both replace versions perform almost the same, and faster than split. Again, indexOf is fastest. Only 2 – 3 times faster than the replace methods, but still the fastest.

1) true: 35 / false: 25
2) true: 30 / false: 25
3) true: 60 / false: 50
4) true: 15 / false: 15

You can run the tests yourself, if you are interested, the test page is here.

Summary

The results are pretty obvious: indexOf() outperforms the other contestants. Which is not really a surprise, considering that whatever Javascript does during indexOf() –  it has also to do the same before being able to do a split() or replace(). So, the proposed way for a contains() method is the following:

dojo.string.contains = function(/* string */ needle, /* string */ haystack, /* bool */ caseInsensitive) {
    if(caseInsensitive) {
        needle = needle.toLowerCase();
        haystack = haystack.toLowerCase();
    }
    return haystack.indexOf(needle) !== -1;
}

If you want to use contains() in your code, just copy the above lines somewhere in your code. Again, don’t forget to dojo.require(“dojo.string”) before.

Or, if you want to have beginsWith(), endsWith() and contains() all-in-one, use this: dojo.string.addons.js

One of its major drawbacks – and the one that keeps it pretty far from becoming a joyful member of the dijit namespace – is the lack of keyboard accessibility. It has plenty of other issues and could use some refactoring, but this one is outstanding. Hm, adding keyboard access shouldn’t be too hard I thought and went for it…

1. Moving and resizing

To enable keybord movement, there are some prequesites: First, the pane needs to be able to recieve focus and move itself to front via the keyboard. Second, the pane needs a lot of visual markers. And it needs a certain state in which the keybord movement can actually be activated.

So, the idea is the following: If you tab through the panes, the focus is set to the pane’s title node. If you click into a pane or into its child widgets, you need to shift-tab upwards until the title node recieves focus. In my minimal styling, the title node text is in italics when it has focus. You can then press space to “activate” keyboard movement. An overlay is shown to indicate that the “moveMode” is active. Then you can use the arrow keys to move, and shift-arrow to resize the pane. To exit this mode, press space or escape or take the focus off the title node by clicking somewhere else or tab away.

In short, the first step included:

• Adding visual hints to indicate which FloatingPane is on top (via box-shadow and a bold title node text)
• Adding a visual hint to indicate when the focus is on the title node and “moveMode” can be activated
• Enabling the pane to get on top of other panes by tabbing to it
• Adding key handlers to start and end “moveMode”
• Adding typematic key listerners to realize movement

Oh, did I mention that dojo’s typematic is awesome? Nope? Well, it’s awesome! Go try it out for yourself!

2. Minimize, maximize, restore and the dock

The FloatingPane also has docking abilities – so the dock and it’s items had be accessible, too. The dock items have their own widget class, so this had to be modified. The changes are minor: adding a tabIndex and a keyhandler. And, of course, adding a visual hint to indicate that the dock item has focus (that is, the label is bold). When the dock item has focus, press space to restore the corresponding pane.

Next, the pane needed extra key handling: I chose “+” to maximize, “-” to minimize (or restore, if pane is maximized) and “x” to close the pane.

3. Baking it all together

As it isn’t that desireable to have two widgets doing the same in the dojox namespace, I merged the changes with FloatingPane. But, then again, as I did some other minor changes to FloatingPane (but including changes to the CSS classNames to have a consistent use of baseClass, and inheriting from dijit.layout.ContentPane instead of dojox.layout.ContentPane), I named the new widget “WindowPane”.

What’s left?

Short: A ton. The widget needs to be refactored, it has a couple of bugs. The code I added is undocumented, the CSS incomplete. Well, I’ll be short on time for a week or two, but I’ll surely get back to this. Consider this a work in progress. But, hey, maybe having keybord accessibility will give further develepmont of this widget a little push.

You want to use it?

Cool, there are two options:

- You can use dojox.layout.Window to gain just movement/resize abilities. Then bake Window.js and the extra CSS from the test page into your build, replace calls to FloatingPane with calls to Window, and you’re done.
- Or, if you don’t use FloatingPane yet or want the complete functionality, grab the WindowPane.js file, the WindowPane.css file and the WindowPane.html template and add them to your dojox. This is probably the best way to do.

See below for files.

Keybord summary

Use Tab to navigate from pane to pane, and press space when the title node has focus (title text is itailc) to activate keyboard interaction.

Arrow keys: move pane around
Shift + arrow keys: resize pane
plus: maximize pane
minus: minimize pane or restore pane (if maximized)
x: close pane

Press space again or escape to deactivate keyboard interaction. Or just tab or click away.

Files:

Step one (moving and resizing):

• /dojox/layout/Window.js
• test page

Or: Step three (full)

• /dojox/layout/WindowPane.js
• /dojox/layout/resources/WindowPane.html
• /dojox/layout/resources/WindowPane.css
• test page

Consider the following code:

var nearbyZipcodes = dojo.filter(givenZipcodes,function(zipcode){
    return dojo.string.beginsWith(zipcode,'12');
});

No need to tell you what this does, right? So, let’s do this then! The only thing left is to think about performance: Is there a difference between String.substr() and String.substring()? And can we get faster than the two?

If we have very short needles to look for in our haystack, one could consider the following approach:

dojo.string.beginsWith = function(/* string */ needle, /* string */ haystack) {
    var i,
        len = needle.length;
    if(needle.length > haystack.length) {
        return false;
    }
    for(i = 0; i < len; i++) {
        if(needle.charAt(i) !== haystack.charAt(i)) {
            return false;
        }
    }
    return true;
}

For very short needles, or when we expect close to no hits, this might be faster. So I set up a test page and let the different methods run against each other. The results clearly spoke against the char iteration method: On Firefox, iteration was always slower, even when the iteration method could return false after the first character. And when it had to iterate more often, times went up (I somehow had in mind Tracemonkey was perfect for simple iterations – but in this case it won’t help). Only on Safari the iteration method could compete with native substr() / substring() – but was never significantly faster. So, we’ll stick to the native methods (there was no real difference between the two).

More convenience?

Depending on your datasource, you might want to trim the input. No problem, as we use dojo, we can use it’s super fast trim and end up with the following:

dojo.string.beginsWith = function(/* string */ needle, /* string */ haystack, /* bool */ trimBefore) {
    if(trimBefore) {
        needle = dojo.string.trim(needle)
    }
    if(needle.length > haystack.length) {
        return false;
    }
    return haystack.substr(0,needle.length) === needle;
}

So simple, so sweet.

You can run the tests for yourself, the page is located here: test_beginsWith.html

If you want to use beginsWith in your code, just put the lines above it anywhere in your code – but don’t forget to dojo.require(‘dojo.string’) before.

Screenshot

One of the things that fascinated me most about computers since I was a teen, was their ability to simulate a three-dimensional space where one could move around in.

That’s why I was so intrigued when I read Jacob Seidelin’s post about “Creating pseudo 3D Games“. I had to play around with it, as I wanted to have mouse control in it, but performance was so bad that it was impossible. So I laid aside that idea. Eventually, he continued this project and used it for something pretty awesome called “WolfenFlickr“, where you can walk around and look at Flickr photos, attached to walls. As I said, pretty awesome.

Anyway, what I wanted was mouse navigation and strafe keys, as you have it in shooters – this kind of moving around always gives me the feeling of being “free“ in a way. Experiencing that freedom in a web page (w/o flash, of course) was still on my mind.

And the I stumbled upon Ben Joffe’s textured Canvascape 3D-Walker. The performance of the canvas element drawing the image slices was better than letting the browser render single elements for each slice – much better. In fact, the idea of mouse control immeadiately popped up again and I had to give it a try. And – it worked! Of course it has some drawbacks (that is, when the cursor leaves the browser window, there’s no more control…), but it gave me that feeling of freedom while moving around!

Fooling around with the canvas element was fun and tought me about it’s image methods. And I hope to find more time to take it further…

Of course there’s an aweful lot of work ahead if one would want this to be pretty (it’s all bricks now, no interaction, perspective issues, no smooth movement on strafe, and so on…) and performance is still an issue with high-res textures, but it is a lot of fun moving around.

Here’s what I added to Ben Joffe’s Walker:

• mouse control
• strafe movement
• walk and crouch
• high-res textures

I dropped IE-Support for this and disabled the mini map for performance reasons.

You’ll need Chrome/Chromium to see it in action in high details mode, but it’s definitely worth it!

Go give it try! Move the mouse cursor into the center of your browser window, press “M“ and enjoy!

PS: Chromium builds for Mac can be found here.

Note: The modifications are all just minor, all credits for this go out to Ben Joffe!