It’s been some time since dojox/storage, and a lot of things changed since then. Most notably: Browsers now have IndexedDB, and Dojo now has the dojo/store API that widgets can directly work with.

The dojo/store API was built with IndexedDB and offline in mind, has a nice API and allows asynchronism, meaning that it can return Promises instead of values. The only thing missing was a persistence layer that would take data via that API and store it in the user’s browser, e.g. for offline availability.

And that’s what Storehouse is: A persistent object store implementing the dojo/store API.

read more »

Just recently I learned about the Web Speech API which it’s already available in Chrome 25. It takes input from the computer’s microphone, does a speech recognition and returns you the results – without needing you to do anything. You just start the service, say “Hello” and get a result returned that contains the string “hello”. I immediately got nerd sniped and decided I needed to add speech recognition to decoupled-input to be able to issue voice commands in a game, like “Arm cannon”, “Fire missile” or “Activate autopilot”. There’s an example page over here where you can see it in action. Just press “V” to activate recognition and say one of “Full speed”, “Slow” or “Stop” to control the car’s speed; you get a green confirmation text when the command has been recognized. While this is seriously awesome, it also has some cons. Let’s go into some details.

read more »

Note: This is a tutorial about working with IDBWrapper, a wrapper for the IndexedDB client side storage. Creating indexes and running queries only works with the new version of IDBWrapper, so if already have IDBWrapper, make sure you fetch a new version from GitHub.

All examples in this tutorial follow along the “Basic Index Example”, which uses IDBWrapper to store customer data such as name and age. You can find in the examples folder, and you can (and should) also open it in your browser, as it has a “query” section that allows you to set query options by using inputs and dropdowns to immediately see the results of your settings.

While the last part of the tutorial covered the basic CRUD methods get/getAll/put/delete, this part is about the real thing: running queries against the store.

To do so, we need to get familiar with two things: Creating indexes, and creating keyRanges.

read more »

The Ascent project had a bunch of upgrades these days, including better loading logic, a radar, pointer lock support and others. But the most important one certainly was decoupled input. I found it important enough to extract and polish it and create a separate GitHub repo for it. So, let me introduce you to decoupled-input!

read more »

Finding a Collada model that has been “clicked on” in a scene seems to be a common issue, and I’m getting quite some emails asking me about details. So here’s a how-to with annotated code.

The whole “finding an object” thing requires ray casting. When the user clicks anywhere on the screen, we’ll project the event coordinates into the 3D space so that we have a virtual “view-path” from the center of our view into the direction where the click took place – like our own eye does. We then follow that line until we find an intersection with an object in the scene. That line is the ray we are “casting”. OK, let’s go!
read more »

As I mentioned before, the THREE.js Ray class is not very optimized regarding memory usage. Of course, you should avoid expensive operations like ray casting, but it seems to be the cheapest way to detect if a given point is inside of a mesh. So you will eventually do a lot of ray casting in your render loop.

This is the case for Ascent, as I’m implementing shooting at things there. The whole “shooting at things” implementation can be optimized a lot, but that’s something for another post; for now, we just want a less memory-eating ray caster class.
read more »

Today is my last day at uxebu, so I want to take the opportunity to thank my fellow coworkers for an amazing time. We’ve been building crazy things. Things no one believed to be doable. Things so crazy that I had to sign contracts that did forbid me to even talk about signing those. And we built them all. Working at uxebu really was Vegas at times.

Thanks, dudes, we had some awesome time!

And now? Well, for now, I’ll be continuing my life as a freelancer, and spend some time on my own projects. I’ll keep you posted

One of the main missing things in Ascent is “Being able to shoot at things”. To solve this, the first question is “What to shoot?”. Ok, there are rockets. But what about the almost-unlimited-basic-weaponry? Many space games feature laser guns. But, lasers, if implemented they way they’d actually look like and work, are boring. Just long lines, going on forever; not the fancy thing you know from Star Wars. You could also implement them to work like railguns – still, boring. But I remember that one of the coolest things of WWI flight simulators was firing bullets at enemies with the on-board cannon. And I’m sure one can find a satisfactory explanation why firing bullets in space is a reasonable thing to do The only thing that feels odd to me is that those bullets will keep on traveling forever until they hit anything…

read more »

During the last month, I didn’t have much time to work on Ascent, mainly because of an awesome three week vacation in Italy. But there’s one tiny update I made that I find pretty important: moving from particles as scene “background” to a skybox.

read more »

Quite a while ago, I started RavenJS. It was awesome fun. Seeing it grow, and in the end, being able to walk the landscape, was an amazing experience. It triggered sweet memories from the past, and also showed what was possible today. But the whole project sadly has many downsides, the biggest being the fact that I will never be able to put it online somewhere. I still believe that it would have been an awesome opportunity; if I were the original publishers, I would have jumped at it, created a freemium model around it, and spent the rest of my days wondering where to put all the money. Seriously, an online MMORPG, without any plugin or executable to download, just open your browser, enter your (OpenID-) credentials and play? With decent 3D graphics? Plus, that all in a famous setting? I can hardly imagine the amount of success of such a thing would have. (Think about it a little more – virtually no barrier to play, payment and id providers all already in place, pushing updates without downloads, and so on…)

Well, however, I don’t want to get carried away, I guess you get what I mean. So, I decided to start something else. Something that would be easier to realize for a non-3D-guy like me. And something using three.js, as I’ve always been using GLGE for my WebGL experiments (RavenJS was built using GLGE, too). And, most important, something that could be open source and live on GitHub. Something that everybody could play, download and fork. Something people could contribute to, modify, extend, make better.
read more »