That means, I want a build to be dynamic during build time, not during runtime (one could also call this a configurable build). If the resulting build should also be an AMD module, or you want to keep the single modules as modules, this can be easily achieved using the AMD feature plugin, which allows to configure a build during runtime as well as during build time. But what I wanted to have as a result this time, was a single UMD wrapped module with no define/require calls inside of it, so that a user can also just reference the build from a script tag (i.e. remove the dependency on an AMD loader as Require.js).
Posts Tagged: js
- Or: Navigate a Website on a Computer Screen in a Website on a Computer Screen -
Jerome Etienne‘s post on HTML Elements in a WebGL surrounding really caught my interest. What I wanted to do was slightly different, though: I wanted a fully accessible website displayed on the screen of a computer 3D model (creating a virtual 3D office in a browser with an interactive computer, phone, stereo and such is an old dream of mine).
Jerome’s post was a good start, and he created tQuery plugins to do it. After reading the source and understanding the concept, it was a pretty easy and straightforward process, except for two issues I ran into. And here’s the result: browse this website in a 3D environment (requires Chrome and features audio, so grab some headphones and turn up the volume).
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.
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.
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!
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…
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.
It all began half a year ago when I sat down with a friend and fellow crew member, Stephan, and we agreed that Gothic was indeed one the best RPGs of all times (seriously, if you don’t know it and are into RPGs, you should get it). We also soon agreed that it would be awesome to experience it’s amazing atmosphere in a browser, using WebGL. Stephan shopped two shiny new copies of Gothic and we started hacking away and gave the project the very fitting title RavenJS…
Update: Stephan recommended to put the video on top, so here it goes: Some impressions from RavenJS, enjoy (fullscreen and headphones recommended)!
[Note: This is a cross-post. I also published this on the uxebu blog.]
During JSConf.eu, we released EmbedJS 0.2. That release was mainly about a fundamental architectural change: the move to the AMD pattern for our features. Let me explain why we decided to do this, why we think this is a big step forward and what this means for the user.