Now with 4500% more unique peaks and valleys.

On November 2nd, PeaksAndValleys 2.0 was uploaded to Github with a number of improvements. In the first release, we relied on a static map that was 150 by 150 vertices (22,500 total vertices.) When we’re talking about a map, we’re just referring to a grid of vertices where each vertex has a specific height.

Bird’s eye view of a 33 by 33 vertex grid (map); each vertex has a specific height associated with it.

These 22,500 vertices were all generated during startup with randomized heights. It was a good initial implementation, but subject to a number of limitations:

• Maybe we want a fixed / persistent world to traverse.
• We can’t expand the map much more due to performance reasons.
• If the player runs in any direction for long enough, they will hit the edge of the map.

Let’s take a look at each of these individually.

Fixed / Persistent World

One of the more common approaches to this problem is the use of a static source of data; in our case, a height map. This is the approach opted for in PeaksAndValleys 2.0. The following is an example of what a height map might look like:

Sample height map (originally 1024 by 1024 pixels).

Each pixel represents one vertex (or point) of the map, and the RGB colour of that pixel is used to determine the height of each vertex. In the case of PeaksAndValleys, the lowest height occurs at pure black (RGB = 0×000000) and the highest height at pure white (0xFFFFFF).

Though the height map is only 1024 by 1024 pixels, we can apply a scaling factor to extend the map across larger distances in our WebGL world.

Depending on how smooth the source image is, we may get areas where there is a very low region next to a very high region. To prevent drastic changes in terrain, a smoothing algorithm was implemented that averages the height of each pixel with that of its neighbours.

And with this, we address the fixed / persistent world by using a static data source. We can quickly see how multiple height maps and randomized starting locations can expand the versatility of this approach.

Performance

As noted, the first release of PeaksAndValleys contained a static 150 by 150 vertex area and expanding to a larger number of vertices would have an impact on performance; so then what good is a 1024 by 1024 height map?

In our case, we’re actually only loading a 121 by 121 region at any given time. As the player traverses the terrain, we are continuously reloading the surrounding region data (with the player at the center.) This means that as the player moves around, terrain in their vicinity is continually loaded from the height map.

There is a lot of processing that needs to go on in order to keep loading terrain — so much that if we do this processing on the main application thread, we’ll see a drop to roughly 30 frames per second. This is where Web Workers come in, for which the implementation can be seen in GLTerrainWorker.js.

A Web Worker allows a separate thread to perform actions without interfering with our main application thread. Our main application thread is where all of our interactions and rendering are performed, so if we can minimize the work being done there, we can improve our frames per second and responsiveness.

Web Workers aren’t without their limitations. Specifically affecting us, we cannot:

• Access the DOM. This eliminates WebGL rendering directly on the Web Worker.
• Pass objects with functions between the main application thread and Web Worker.

These two limitations mean that while we can perform our processing on a Web Worker, we actually need to pass the processed data back to our main application thread in order to update our rendering objects. We do this via the onMessage listener and postMessage initiator to initialize our Web Worker with the data it will need, and then pass subsets of that data at various intervals. You can see this initialization and rendering update performed in GLTerrain.js.

By offloading this processing to a Web Worker, we can continuously load more data off the main application thread, and only pass back the final data results to be assigned to our renderers. The end result is increasing our frames per second from roughly 30 to 50-60 frames per second; a huge win. To learn more about Web Workers, the following HTML5 Rocks tutorial is a great starting point.

Seamless Terrain

The final issue we had with our 150 by 150 static area was that when you run to the edge of the map, you hit the border. Loading data from a larger 1024 by 1024 area certainly extends the time before the player hits the border, but inevitably they will if they keep moving in one direction.

To counter this, the application continuously loads an area of pixels surrounding the player. As you reach any of the edges, data from the opposite side of the map will we used to populate that area. This produces a continuous terrain, even when travelling near the edges of the map.

Red cross represents the location of the player, white area represents the data we’ve loaded.

By wrapping the data that we load as we get close to the edges, we can in essence allow the player to run forever. You may notice that this image isn’t intended to be seamless (i.e. when wrapping around, the colours at the borders do not match up or flow together). This can be overcome by using a height map that is already seamless (i.e. it has already been processed to ensure that the pixels on the north side match those on the south, and those on the east match those on the west). In the case of PeaksAndValleys, our smoothing algorithm was implemented to wrap around the image when necessary (i.e. at the edges), thus turning non-seamless images into height map data that is seamless.

Preprocessing Data

To obtain usable height map data, we must:

• Read a source image; in our case 1024 by 1024 pixels.
• Perform height calculations.
• Calculate the normal (perpendicular vector) of each point.
• Calculate texture coordinates.

This involved quite a bit of math and processing power. Mathematical calculations are an area where JavaScript performance has historically suffered. Attempting to perform these actions while the application loads leads to a PC load time around 5 seconds and a mobile device load time around 20-25 seconds.

This also means that we are re-calculating data on every load just to get the same result as our previous run — a very inefficient approach.

To address this, a Node.js preprocessor tool was created that reads in an image, along with some parameters, and generates a json file with the resulting vertex, normal, and texture data required by our WebGL application. On a 1024 x 1024 image, the resulting file is roughly 50mb in size. Originally, this file was closer to 120mb, however by truncating decimal points to 5 significant digits the overall size was reduced.

As a result our application doesn’t actually process any data on load. Instead of feeding in an image, we are now feeding in the output json file with all calculations already in place. That being said, we are still loading a 50mb file which does take some time, but now we’ve managed to cut the loading time closer to 5 seconds on a mobile device.

Using preprocessed data also minimizes the amount of work the Web Worker has to do, as it will simply retrieve the appropriate data based on the user’s location and pass that data back to the main application thread.

Summary

Ultimately, PeaksAndValleys has seen a large number of improvements in the terrain implementation. From preprocessing / generating seamless height maps to leveraging Web Workers and minimizing strain on the main application thread, we now have a much more versatile world.

There are still some issues such as terrain popping into view as you move about. There is also room for optimization by only loading a cone of data in the player’s field of view (as opposed to a square in all directions around the player). These are topics that will be addressed in the next release.

For more information on this project, be sure to check out the Github release. Feel free to leave questions there, or reach out to me directly on Twitter® via @WaterlooErik.

We’re very pleased to announce that Sencha has released an update to their Sencha Touch framework that brings beta support for the BlackBerry® 10 operating system. For those unfamiliar with Sencha Touch, it is an impressive JavaScript® framework based entirely on HTML5, CSS and JavaScript that is designed to bring an incredibly powerful set of components to create rich mobile applications. Today’s Sencha Touch release not only brings support for BlackBerry 10, but it also supports the BlackBerry® PlayBook™ tablet.

Sencha Touch includes all of the core concepts around Controllers, including refs, control and routes as well as Device Profiles, which enables you to easily develop applications that can present customized UIs on BlackBerry 10 devices and BlackBerry PlayBook tablet. In terms of components, Sencha touch 2.1 supports all the major components which helps you to develop compelling application for the BlackBerry 10 Platform. Sencha Touch supports Forms, DataView, Carousel, List, TabPanel, NestedList and Navigation View, and the BlackBerry 10 specific CrossCut component.

While Sencha Touch 2.1 includes key upgrades such as significant performance improvements, a new and improved charting and data visualization package, a new infinite list component, and enhanced native support through the Sencha Mobile Packager, the most relevant upgrade to BlackBerry platform is the new BlackBerry theme and the new CrossCut component.

With over fifty built-in components, state management, and a built-in MVC system, Sencha Touch provides everything you need to create immersive applications for the BlackBerry 10 and BlackBerry PlayBook tablet platforms. Sencha Touch also provides access to local hardware services like geolocation and accelerometers as well as system services like localStorage, which allow developers to take advantage of hardware features. For more information on Sencha Touch 2.1, visit their website.

To get started, developers should download the framework and then check out the Sencha Touch Learning Center, where they will find code samples, videos and tutorials. To get an idea of what is possible using the framework, there are a variety of demo applications showcasing the breadth and power of the platform. For the complete BlackBerry guide to Sencha Touch, refer to http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/Introducing-Sencha-Touch-2-1-on-BlackBerry10/ta-p/1976695

Guest post from Nukul – Ed.

We’ve received a lot of requests from developers to be able to build BlackBerry® 10 WebWorks™ directly from GitHub. Before I talk about how to take advantage of this, I would like to explain why it took us so long to get here and what it means for you.

The main issue was that the latest BlackBerry 10 WebWorks SDK features were dependent on features in the BlackBerry 10 OS. Therefore, if you built BlackBerry 10 WebWorks in open source, it potentially would not work with latest BlackBerry 10 OS beta.

This has changed as we get closer and closer to launch. We are now starting to work on features that are not dependent on the latest BlackBerry 10 OS beta. Imagine this: You hear about an awesome new feature or extension we are working on. You can now go to our GitHub repositories, look at pull requests, pull down the branch, and a few minutes later you have a BlackBerry 10 WebWorks build with the new extension or feature.

Build time can be less than two to three minutes from a clean build. From the time you see someone’s tweet about an awesome new feature, it could take you less than five minutes to get a build of BlackBerry 10 WebWorks that has that feature.

The advantages to a BlackBerry 10 WebWorks app developer are infinite here. You should never need to wait for new features. You can even build with Linux! It’s all there. There will still be some features that you will need the next OS release for, but that will happen less frequently as we get closer to launch of BlackBerry 10.

Here are the two repos you need to build to get ready to take advantage of this:

https://github.com/blackberry/BB10-WebWorks-Framework

https://github.com/blackberry/BB10-Webworks-Packager

The framework repo contains the Framework that is packaged with your app when you build a BlackBerry 10 WebWorks app. The Packager repo contains all the code for the packaging tool.

There are two main branches in each BlackBerry 10 WebWorks repo: master and next. The master branch will contain all the features that you can currently use with the current publicly-released OS — think of it as the features we wish we had time to get into the previous release. When a feature is completed, it’s merged into master if does not have any OS dependencies. The next branch will contain the new features that have OS dependencies.

To allow developers to easily build stable versions, each release is tagged using the version number of the release. This allows you to easily check out the source of a particular release. You can simply use the tags to check out the code from that release. For example, you can use “git checkout v1.0.2.9” to pull down the code for the last release. So, any pull request you see going into the master branch, you can grab and use right away. You will see none open today, but over the next couple of weeks you should start seeing many.

The README.md has been updated with all the updated instructions.
Run the unit tests, automated tests, all the developer tools we use are all available to you.

We are doing everything we can to enable developers to take advantage of our latest and greatest work. Just open an issue on our repo when you find an issue with our BlackBerry 10 WebWorks SDK. If you fix a bug or build an awesome extension, contribute it back and help us make BlackBerry 10 WebWorks SDK even better. For details on how to contribute, check out http://blackberry.github.com/howToContribute.html

We recently had Mark Robinson contribute changes to make SDK work on Linux — contributions like that go a long way. Be sure to see our growing list of contributors!

You can reach me any time on Twitter® @nukulb or send me a message through GitHub.

The BlackBerry® Developer Relations will be at the Sprint Open Solutions Conference to help you with porting your existing Android™ or HTML5 application for the BlackBerry® PlayBook™ tablet and our upcoming BlackBerry® 10 platform. The Sprint Open Solution Conference runs on Wednesday, October 24th and Thursday, October 25th at the San Jose Convention Center in beautiful downtown San Jose.

Are you ready for #SprintOSC12?Have you registered?It’s not too late! Reg NOW! ow.ly/eBVv6

— Sprint Dev Program (@SprintDeveloper) October 21, 2012

Stop by our booth to port your HTML5 and Android apps to the BlackBerry 10 platform and the BlackBerry PlayBook tablet with few or no required code modifications. We’ll have porting experts on hand to help, and the first ten developers to get their app running on a BlackBerry 10 Dev Alpha testing device and submitted to the BlackBerry App World™ storefront will be given a BlackBerry 10 Dev Alpha testing device on site. Plus, if you get it running on the BlackBerry PlayBook tablet, you could receive 1 of 100 free BlackBerry PlayBook tablets — and once your app is on the BlackBerry PlayBook tablet, it can be easily ported to BlackBerry 10!

Want to get a head start?

1. Register for BlackBerry App World – Become an official BlackBerry developer.
2. Request signature keys – Ensure you select for BlackBerry PlayBook OS and BlackBerry 10 and higher. Downloading in advance is strongly recommended as the time involved to do so on site could prevent you from competing for Alphas.
3. Get the BlackBerry Tools and Plug-ins – Get your laptop set up with the right tools so you can begin creating apps for BlackBerry 10.

In addition to our Porting Booth, our own Larry McDonough is presenting the session “Mobile Monetization with BlackBerry – What Developers Need to Know” on Thursday, October 25th at 2:30pm PST in room 210G. This presentation will cover the different methods for monetizing mobile applications on BlackBerry devices. Larry will cover NFC, in-app payments, advertising, “freemium” apps, and carrier billing. This discussion will also consider how to prepare and market your app through a mobile app marketplace like BlackBerry App World.

See you in San Jose!

Beyond all you can learn at BlackBerry® DevCon Americas 2011 and the many great people you can meet, there is another real draw at the show: Your web or Android™ app can be ported over to the BlackBerry platform and be made distribution-ready for submission to the BlackBerry® App World™ storefront.

App Express kiosks are a show feature this year. Walk up to any kiosk in the Golden Gate Foyer, plug in your laptop and you can begin to port your existing Android app to the BlackBerry® PlayBook™ tablet. You’ll also be able to transform your existing web application into a ready-to-go app for both the BlackBerry PlayBook tablet and BlackBerry smartphones.

You can do all this quickly and then get your app submitted to BlackBerry App World right then and there – no kidding! Just keep in mind, submission to BlackBerry App World still requires your application to be signed with BlackBerry Code Signing keys. Get them here for free before coming on site to BlackBerry DevCon Americas (keys can take up to two hours to be generated). You’ll also want to check out this handy checklist for a list of other items to have ready to facilitate your BlackBerry App World submission.

App Express is free, and it opens on Monday, October 17 and runs through Thursday, October 20. It’s also a great place to meet experts from the development team at Research In Motion® (RIM®) and the BlackBerry App World team.

If you’re not registered for BlackBerry DevCon Americas 2011 yet, don’t worry. Come by and try out App Express on us. And then think about registering for the rest of the conference – there’s a lot to see and experience this year at BlackBerry DevCon 2011.