Setting up an OpenGL ES 2.0 dev environment for Android (The horror!)

It is a well known phenomenon that if you give a software developer (a REAL developer) any device which contains a CPU (and even a great many that don't) you will also install in them a great and uncontrollable urge to put their own programs on the damn thing. This urge cannot be satisfied by any old "Hello World" app either, oh no. It has to be something significant. Something that uses the device in a non-trivial way. Something that makes your peers say "Woah!" (The "Woah" factor is incredibly important, ask anyone.)


As such, being a developer and recently coming to posses a shiny new smartphone I've been dying to do some code for it for a while now. Finishing up some of my WebGL stuff and keeping up with my normal work (you know, the one that actually pays me) has prevented me from acting on it so far, and I still may not get a chance to code for it for a little while, but I finally had enough time lately to sit down and actually set up the SDK and play with some of the examples.

Communication across language barriers

Had a neat experience while out walking my dog today. We came across a very kindly and very lost elderly Hispanic gentleman that flagged us down to ask for help. Since the first thing out of his mouth was "I no speak-a English very good." I was concerned that I would be fairly useless with whatever problem he was having. (Two years of Jr. High Spanish and all I can say fluently is "I don't speak Spanish".) Luckily, however, he was able to point to an address scrawled on a bus schedule and indicate that he was trying to reach that location. I knew where the address was, and fortunately he wasn't more than a couple of blocks off, but I was somewhat at a loss for how to communicate directions to him outside of vague hand gestures.

Then, in a moment of fleeting intelligence, I recalled the trusty little Android phone in my pocket that I had been listening to music on. Pulling it out, in under a minute I was able to call up Google Maps, punch in the address, have it map out the directions, and show this gentleman the results. Even though the map was in English a big blue line guiding you from where you are now to where you want to be is pretty universal. After studying the map for a moment a look of understanding and relief swept over him. He thanked me several times, a sentiment that I had no problem understanding, and headed off to his destination no longer lost and much happier for it.

For my part I was left with a mix of the warm fuzzies you get from helping another human being and wonder that we live in a day and age where I can hold in my pocket a tool that can completely transcend language and cultural differences and allow me to help someone in need. I don't care who you are, that's just cool!

As a programmer it's very easy for me (and, I think, others of my profession) to loose sight of why we surround ourselves with all this technology. We can easily fall into the trap of pursuing technology for the sake of technology. (I'm certainly guilty of that.) It's worth reminding ourselves once in a while that all of these spectacular devices and innovations are really there to serve one singular purpose: To make our lives better in some little way. Whether it does that by making some task a little easier, bringing us the information we need, making us safer, or just providing a few moments of entertainment, it's all in the name of improving our day to day existence. If we keep that in mind, magical things can happen.

Random WebGL related gunk

There's a few things I've come across in the last few days that I feel are worth pointing out to the WebGL community:

• Newer builds of Firefox have started validating the textures passed to generateMipmaps according to the OpenGL ES 2.0 spec. This means that attempting to generate mipmaps with non-power-of-two textures will start failing on you very soon! Please update you code/resources accordingly. (This already bit me with my Quake demos, which have now been tweaked accordingly.)
• WebGL___Array types are going, going, gone! Newer browser builds don't even have them defined, so make sure you are using the appropriate analogs from the Typed Arrays. Again, my demos have been updated to account for this.
• In an odd twist, whereas Firefox has been speeding up lately apparently Chrome is cracking down on crazy fast loops now. With the latest dev releases (7.xx) I've noticed that my Quake 3 demo is basically locked at 30fps, regardless of whether or not you check "Cap FPS". Curiously, this does not seem to be the case for my Quake 2 demo, which means that Chrome is actually limiting the internal message pump. Granted, it's a very stable 30fps, and I'd rather have a lower but stable framerate than a high but erratic one, so I'm not complaining. It did strike me as an interesting change, though. A bit of background on this one: For the Quake 3 demo in order to get the best framerates possible I used a hack picked up from Vladimir Vukicevic that continually posts messages to the page as a signal to draw (demo), which attempts to avoid some of the resolution limitations of setTimeout/Interval. This apparently causes severe performance issues if allowed to run rampant, however (as commenters on this site have pointed out) and so it's possible that this apparent capping may be Google trying to prevent abuse of the system. (Which is probably a good thing!) I'd love to know a bit more about the actual changes that took place in this regard, but in the end it appears that the timer-based method is the better way to go.
• Finally, in a bit of news that has nothing to do with WebGL whatsoever, I find this to be supremely amusing. Chrome envy, perhaps? :) It's especially funny in light of some Google-bashing that Microsoft did a few months back about how a single address/search bar was a bad thing for users privacy.

Firefox 4 beta 4 - Hardware Acceleration FTW!

I just wanted to jot down a quick note about something that made me VERY happy today! Firefox 4 beta 4 was released today, and one of the big features that it includes is (On Windows Vista/7 anyway) hardware acceleration via Direct2D. It's disabled by default, but doesn't take much to turn on (and certainly shouldn't be a problem for anyone who's been following WebGL).

First off, let me say that text rendering looks 1000% better when hardware acceleration is enabled. Seriously! I'm usually not one to care about aliasing in my text and whatnot but... WOW! The really exciting bit for me, though, was booting up my Quake 3 demo. With acceleration turned off I'm getting about 20-23 FPS (on par with previous betas), but with acceleration enabled I'm seeing 60-70 FPS! OMGWTFBBQ!?!

A 300% bump in render performance? That's insane! Awesome, but insane! Great work, Firefox crew! I can't wait to get this out of beta and into the average users hands.

(And now Chrome needs to get with the program! Seriously, looking at text in any other browser is gonna bug the crap out of me now!)

UPDATE: Ask and it shall be given, I suppose? I've turned the associated flag on, but can't see any difference in performance due to the apparent message pump cap I mentioned in a newer post. I'll see if I can find some better way of performance testing this later.

Spring (er.. late Summer?) Cleaning

As a heads up, some of my older demos (well, basically everything but the Quake 3 demo) are probably broken on newer browser builds at this point due to changes in the WebGL's API. (Hey, that's what you get for developing against experimental libraries!) Over the next couple of days I'm going to go back and fix them up (may even try to optimize the code a bit), so hopefully everything should be working again soon.

Until then, sorry for any broken code you may stumble across!

Update: So I've got all of the demos to stop throwing errors, but the Spore and Hellknight demo's aren't showing anything, even though they appear to load correctly. I'll continue looking into it, but in the meantime at least the Quake 2 and 3 demo's are running fine.

Droid X Android 2.2 (FroYo) Micro-review

So anyone patiently waiting for Motorola to release Android 2.2 for the Droid X has probably heard by now that an official build of it was leaked and can be installed on any X, rooter or otherwise. I was personally quite excited by this news, since I had been looking forward to the new release to see if it addressed some of the software shortcomings that I had found in the phone. As such, it took me all of about half an hour after I found out about the leak before I was running 2.2! (Disclamer.... voided warranty... not supported... blah blah blah...)

Now, before I continue I should note that there is a chance that this is not the final update that will be released OTA. That said, I doubt that Motorola is planning on making any major changes if they still intend to hit an early September release.

If you want to skip my earlier review essentially I think that the X is a beautiful piece of hardware that is badly hampered by Motorola's terrible software. (MotoBlur, uninstallable services, etc.) So as much as I doubted it I kept a little spark of hope alive deep down in my heart that Motorola would hear the impassioned cries of their faithful userbase and use the 2.2 update as an opportunity to strip away the bloatware that we all hate so much (or at least give power users a way to do so).

Rendering Quake 3 maps with WebGL: Tech talk

So, I promised I would talk more about the the development side of the Quake 3 demo and I'm here to deliver. Warning! This is going to be somewhat long and technical, so steer clear if you're just here for the shiny graphics!

So first off, why Quake 3? After all, CopperLicht has already been there and done that, and I think many people won't recognize this as much of a step up from the Quake 2 demo I already did. Not to mention that along with my Doom 3 model loader this is my 3rd id-related demo in a row, which may seem a bit boring to some people.


For me it mostly comes down to what I wanted to achieve personally. Thus far each of my demos have had been the result of a specific goal on my part: My Spore demo was just to familiarize myself with WebGL. The Hellknight model was to toy around with animation and game-oriented file formats. The Quake 2 demo was a (somewhat failed) stab at large scenes that the user could navigate. I had intended next to move on to some special effects (I still want to try Megatexture-style streaming, for example), but the problems with the Quake 2 demo left me itching for some closure. So I redirected my efforts and decided that I wanted to do a project that created a "real world" game environment in WebGL. Something that looked and acted like an actual game, running at framerates that would actually be considered playable, without "dumbing it down" for the browser. Partially for the challenge, and partially to demonstrate that yes, WebGL is (or at least will be when released fully) a viable platform for game development.

Rendering Quake 3 maps with WebGL: Demo

So, after a good long delay it's finally WebGL demo time again! This one is pretty elaborate, but I feel like it was worth the effort:

WebGL Quake 3 - Q3TOURNEY2

A quick note: I've heard reports that Chrome 5 has trouble with the demo because I'm using the newer texImage2d signature. Your mileage may vary, but if you're having trouble give it a try with the Chrome dev channel.

Now, there are SOOO many things to talk about in regards to this demo: Optimizations, remaining issues, changes made to resources for web use, etc. Unfortunately I don't have the time to elaborate on them right now but I wanted to get the demo out there ASAP to get some feedback on it. Expect another post (or maybe an addendum to this one) within the next couple of days about my thoughts on Quake 3 bsp maps under WebGL.

(UPDATE: My ramblings about the demo are online now)

Have fun!

EDIT: Quick update. I've tweaked the code a little bit to reflect gero3's suggestion of combining the multiple event loops into one. It worked pretty well, and the movement in particular feels better for it (well, not the mouselook. Not much I can do there though). Not to mention the code now reflects a "traditional" game loop much more.

Droid X: First Week Impressions

Things have been a bit quiet on the blog lately, but not for lack of activity on my part! I've been working on a fairly involved WebGL demo that I'm hoping to post soon (I'd like to get it out by Aug. 12...) that I feel is pretty dang awesome. Hopefully the rest of the interwebs will feel the same. :)

For the moment, though, I want to talk about something non-WebGL. I bought a new phone last week after my EnV Touch started randomly powering off... again. (For the record in the last two years I have cycled through 6 EnV phones: 3 EnV 2s and 3 EnV Touches. ALL of them had power issues within about 4 months or so of receiving a replacement phone. Don't get phones from the EnV line. Ever.) This time I decided to make the jump to smartphone land, and since Apple has yet to dump AT&T (and since I like to, you know, HOLD my phone) I went with the Android powered Droid X. I will admit that it was a close race between that and the HTC Incredible, though. Better battery life on the X won me over in the end.

Well, I've had it for about a week now and thought I would do a brain dump of my initial impressions of the device. Please keep in mind that this is the first Android device that I've owned or even used extensively, and as such I'm not 100% certain of where the line is between stock Android and the Droid X's software.