Finally, the keynote room opened its doors, and the considerable amounts of people waiting were able to slowly get in. I also noticed there was a lot more cameras and media people than yesterday, and I couldn’t but keep asking myself whether the journalists room/area had already been there yesterday, but I couldn’t remember.

In the hall, this time I got a seat, and not in the middle of a lot of people, so it was great. There wasn’t any countdown as in the first keynote, but there were lots of people taking pictures anyway, this time imitating the same gesture they do with their phones, but putting the tablets they got yesterday in the air instead, which makes it a bit embarrassing or annoying, depending on the moment.

The keynote started after having been politely asked to turn off “any hotspots” several times. I hadn’t used any of those before, but it seems portable hotspots are a big thing in the States. Or at least at the I/O… Anyway, it didn’t seem to work, since I still could find lots of wifi networks with my phone.

Vic appeared on stage again and quickly handed over to Sundar Pichai, which way less enthusiastic than Vic, and that was a bit of a downer. He described various nice feats achieved by the Chrome team since the last I/O, then handed to another guy who described more particular details, then that guy left the stage, and the cycle repeated. From all of what they announced, it seemed interesting they were just going to charge 5% for in-app payments… and made me wonder whether they would do the same with the Android market at some point. Now that would be cool! ;-)

There was the Chromebook and their pricing that got everyone clapping… well, except probably me. I couldn’t stop wondering whether they had considered the privacy implications of copying everything “to the cloud”, specially when we’re talking about corporate and educational environments migrating to use Chromebooks. And what with their customer support!? If it’s as good as the support for their other projects… (and I’ll leave it there) .

A good thing was that those machines will be jailbreakable. That always makes hardware more attractive (and relevant, in my opinion). But I can also foresee it doesn’t guarantee anything, specially if they get the same closed binary drivers issues we’re getting with Android. Which they will probably get, since they don’t have the latest word on the hardware those computers will be using, and it’ll be completely up to the vendors to integrate open source hardware or just proprietary stuff as usual.

Later the guy from that Angry birds game came up on stage to explain how awesome the newly ported to Chrome version was, and during all the time he was on stage praising the game and trying to convince me to play it (since it seems like I’m the only one who has yet to play it) I couldn’t stop wondering what took them that long to port it. My point is: since it worked on mobile phones, which are underpowered in comparison with full-fledged computers, there was no reason it wouldn’t work on a normal computer. It sounded like a bad excuse. Specially since mrdoob made his Chrome ball pool and Google Gravity experiments a couple of years ago already, and both used Box2D, with Javascript, way before v8 and jagermonkey were as fast as they are now. I truly didn’t understand anything, but I was surrounded by a mass of hysterical people and they looked at me and wondered why I wasn’t clapping like crazy too (and at the end I didn’t).

Then Aaron Koblin did a short intervention presenting a sneak peek for the Rome project, and then explained they had used three.js and mrdoob was working on the project too, and the die-hard fans in the front rows just went WOOOW YEEES WOHOOO crazy-crazy. It seems being honest about the libraries you’re using earns you lots of good karma ;-)

And when they finally announced they were going to send a Chromebook to every attendee in June–when it was a physical reality and in production, I thought the ceiling was going to collapse and the entire hall was going to fall down. Yesterday’s tablet announcement effect was nothing compared to this!

I immediately moved to another floor for Chris Pruett’s talk about building “aggressively compatible games for Android“. I’m not currently writing games but I’d like my apps to be playful and compatible with as many devices as possible, so I believe those were two valid reasons for attending the session! Some of its contents weren’t new to me, but there were some tips that I hadn’t heard of. For example, if a device doesn’t comply with the compatibility guidelines (and hence doesn’t pass the set of automated tests), Google won’t allow it to have the Google applications such as Maps, Market, etc. Which in other words means that if a phone has the Market application, it complies with a minimum set of requisites. It was also funny that Chris’s first words for the audience were “Hey folks”. Very looneytunesque, I loved it!

It was then time for a super very early lunch, since it was the only free time I’d had today between interesting sessions. As it happens, there was a huge amount of people already queuing, so I just joined the queue. Queueing was beginning to shape itself as the official alternative activity in the I/O!

I was a bit luckier with my table mates today, and we talked a bit about an assortment of things such as the food not being really Mexican, the ‘proper San Francisco hacking areas for coffee shop working’, etc.

When I finished, I tried to see if the tablet issue could be solved already, although it wasn’t 15h yet, and I had been told to go to that counter at that particular hour. As I kind of expected, they repeated me that again… so I went up for the Learning to love JavaScript session, but it had already started so it was slightly packed and hard to follow without a context, therefore I decided to simply grab a coffee and take it easy while waiting outside for the next session.

As I waited for the Evading pirates and stopping vampires session, an unknown guy approached me and asked what I did-did I develop Android stuff or…? I showed him Nerdstalgia and Instantanea, but he didn’t seem too impressed :-)

Then after I sat, another unknown guy asked me if the seat nearby was free. He sat and asked me if I was an Android developer … and then told me he came from Spain, so I just told him we could speak in Spanish then!

So he was from the Canary Islands, where they have an slightly different accent than in Peninsular Spain, and that had confused me at first. He was also an amazing connoisseur of Android phones. He knew all about the processors, available memory, small differences between consecutive models… really impressive. And he also told me that I should absolutely stay for the next session (in that very room), because one of the Sony-Ericsson guys had told him that if he was interested in the Xperia Play, the “Writing Android games in C++” session would “interest” him. It also “interested” me, so I decided to sacrifice the Chrome fireside chat in exchange for an hypothetical phone with joystick controls.
Multitouch is cool, but nothing beats a good old button.

The “anti-pirates” session clarified some concepts that were a bit blurry for me yet in regard to licensing, and Dan really insisted in us adding analytics to our applications and keeping track of various metrics in order to not only find out where are we doing wrong as developers but also what are the users doing with the app: how many times it’s launched, etc… and while I understand that it could work for a game, I’m not so sure about my current applications. I have to think about that, but for the moment it simply looks a bit too creepy, considering that Instantanea is already requiring GPS, external storage and camera permissions. If I was asked for internet permissions for a camera application, I don’t think I would allow the installation of that app. My paranoia would quickly kick in and say NO WAY.

On the other hand, I liked the way they proposed to convert casual pirates into customers, allowing some free play before popping up a “I have children to feed” dialog, while at the same time assuming that uberpirates will never be stoppable because they are way more determined to crack an app than we are to add complicated mechanisms to prevent that happening. I still am not totally sold on the whole licensing scheme; it usually adds more issues than solves.

The C++ session was half done by Dan too, and while I had read about the NDK, again there were some things I didn’t know yet, specifically the best way of dealing with OpenGL and GLSurfaceView’s quirks. And you guess what? The guy from the stand wasn’t lying. At the end of the session we were told to stay in the room for some interesting stuff, which was a card exchangeable for the phone on the Gear Pickup counter! Although I couldn’t but wonder whether they would just give me the phone or again make me visit the counter tomorrow :-D

On the way out I found Unai Landa, an old school Spanish demoscener, which as usual had forgotten my face and had to look at my badge to find out who I was :-P It has already happened twice already, once at Euskal party in 2003 and then in the way to the pmp in Madrid in 2005, so I just thought: old Unai, hasn’t changed!

And then, the deciding moment. Would they solve the mysterious tablet problem? I was slightly scared of trying, but I did so anyway…

And as it happens, I have written pretty much the entire post using the tablet!

For everything else, it’s pretty smooth, but the WordPress editor interface is a bit slow. Maybe it’s its Javascript which is slowing things down. I have to test it more before emitting a definitive opinion, but so far I like it more than the iPad form wise. It’s lighter and thinner… and has multitasking. So you can leave something updating or syncing and go to another activity more engaging than a progress bar, you know, that kind of things :-P And when you come back you don’t have to restart the download again (as it happens in other tablets).

Back to the I/O, once I picked the stuff I went to the “Lessons learned from Google Body” (for Android) session, and again most of the stuff I already knew, but it was a good wrap up with some new insights. And then… booh, the event was finishing quietly, without any bell or whistle, which was a bit sad after all the expectation of the keynotes. It felt as if something was missing.

So I went to the Larva Labs stand to see what they were up to and how things were going with their stand, and turns out they were giving away copies of a cute game they had developed, Gurk II. Well, actually you had to connect the phone to their computer and then they installed the game in your phone. It is an 8-bit style game and it’s got a very peculiar interface. And the music! Everything fits into place.

Things were coming to an end, and we had been gently invited to leave several times so that the vacuum cleaner could go through the areas we were in, so we finally exchanged twitter id’s and waved goodbye everyone. I went back to the hotel as fast as I could so that I wouldn’t be mugged by any of those strange characters that you can find in San Francisco, and found mr.doob there, furiously working on the ROME project (he actually went as far as staying up the rest of the night, and even made and commited some last minute fixes while waiting for boarding the plane to New York, where we are now for the Seven on Seven event).

But before leaving San Francisco I had the opportunity to briefly meet the super cool guys from the Data Arts Team at Google, which came up with the most super awesomely geek farewell ending that one could say these days:

See you at github!

It was a pleasure to meet you guys! :-)

To sum up: a very intense event. Maybe a bit too intense for only two days. Yes, the sessions are recorded and published almost immediately, but what I appreciate most from this sort of events is being able to talk with the speakers and ask them the questions, get their instant feedback, and maybe ask them another question, which I can’t do if I just stay home and watch prerecorded sessions. Most of the times there were many interesting sessions happening at the same time, so deciding which one to attend felt like a little sacrifice as I mentioned before. I understand the cost of running an event such as this one is quite high so probably they worked out that two days was the optimum amount of days in economical terms, but still, the suggestion is there for them to pick (or ignore, haha).

In regards to the goodies: wow, that even felt indecently rich. While other events do not even give you a sandwich, Google I/O feeds you and gives you stuff to develop with, apart from providing you with knowledge, which is the main point of a tech conference, of course. And it not only encourages to develop for these platforms, but also really helps a lot. First, because acquiring hardware is always an extra expense we cannot always afford, and secondly because as they are early versions of the hardware, when the final users got those “new” devices they won’t have to wait for applications that exploit it. So it’s not as if they are frivolous goodies–they are useful, and will be fed back into the system, somehow, as we develop and test applications with that new hardware we’ve been given. For example, we’ve been testing every app with the Evo 4G mr.doob got at 2010 I/O, and actually found differences that were impossible to notice (or very hard to track unless you get a report from a user) if we hadn’t tested the apps in the device.
is
So do I recommend it? Absolutely! I am super thrilled with all the knowledge I’ve acquired and I’m so looking forward to come back to London and start applying it (and watch the sessions I couldn’t attend). Meeting so many developers was also amazing. It really gives you a strong sense of community and involvement that I think is very important for any platform to succeed.

I still have a sort of doubt, and it is what is really Google’s strategy. Because they are really, really promoting Android, but obviously their business is in getting everyone to use the web more and so they are promoting the Chromebooks with everything in the cloud and etc… The best explanation I can think of is that they are taking risks (albeit quite huge obviously) and betting for several things to succeed instead of just resting on their laurels. Whoever strikes first… as they say. Let’s see what happens, but right now it is definitely disconcerting, both as user and as developer.

NOTE: This was supposed to be finished and published on the very day that the I/O ended (Wednesday the 13rd), but we spent almost the entire Thursday traveling and I didn’t finish revising it until today (Friday). So apologies if you were waiting for this second part desperately!

And it also looked like it was using the NDK, I thought upon reading this post.

Then somebody at that forum suggested they are implemented with Processing, which made me kind of laugh internally. But the very same source he used (Romain Guy’s blog post about live wallpapers) denies that and gives some details about the Android implementation:

The prototypes are written in Processing. I did port Processing to Android to run live wallpapers and performance was not on par with what we wanted, so we implemented something called RenderScript #

Digging deeper, I downloaded the /system/apps/LiveWallpaper.apk file from the phone to my computer (using the DDMS perspective from within Eclipse), uncompressed it (it’s a ZIP file in disguise) and inspected its contents to see if I could locate where was the code the guy in the first post shown. And I indeed could :-)

The .rs files (for “RenderScript”, I deduct) are all in res/raw. They have names such as galaxy.rs, grass.rs, nexus.rs and so on. And they look like this:

It might be baptised as RenderScript but it no doubt smells like C from a couple of miles away: #pragma’s, #define’s, struct’s and ->’s for pointing to members? You can’t help thinking it’s C, no matter how hard you try.

More deductions: either this RenderScript uses a gcc compiler in the very phone (not that unlikely since it’s a Linux system after all?) or it parses the contents of the script on loading time. Then it’s “just” a wrapper for OpenGL calls and generally cumbersome stuff such as preparing textures, vertex shaders etc (I can see something related to vertex shaders in the galaxy wallpaper, for example).

I’ve copy-pasted the full galaxy.rs source code into a gist, just in case you want to see the whole thing but don’t have a phone and a DDMS environment handy :-)

• gl.glLineWidth is ignored in the HTC Magic (all lines have width = 1.0), whereas it is honoured on the emulator
• it also seems like the emulator performs some sort of polygon clipping instead of culling triangles when at least one of the vertexes is out of the frustrum — so you get different output in some cases

Drawing text with OpenGL ES’ glDrawTexfOES vs the classic OpenGL orthogonal view methods

There’s no need for setting an orthogonal view when using glDrawTexfOES for drawing text into the screen, since it seems to be ignoring any existing view or projection matrix and simply drawing into the screen buffer (and that’s probably why it is so fast!).

So no more structures like this:

It will get reduced to just…

Interestingly though, if you’re using fog you’ll need to turn it off or you may not see the text. So we’ll end up with this:

Modifying the buffers after they have been created

In classic OpenGL immediate mode we use glBegin/glEnd liberally. But we can’t keep on going on like that with OpenGL ES: we are forced to convert our glBegin/glEnd calls to the glDrawArrays or glDrawElements style.

I believed that this would derive in only being able to show [boring] static geometry, but I have been messing with buffers and found out that you can for example modify the vertex buffers once they have been allocated and the data put into them. So you can not only do this:

but you could even do this afterwards:

Or in other words: buffer[index] = value is buffer.put(index, value) in buffer terms.

I haven’t tried adding more elements (the above example doesn’t add more, just replaces the current vertex values with randomized ones). The performance doesn’t seem to plummet (FPS counter shows a decent 57-60 fps) when changing all 24 vertices in my test mesh, in every frame. But I haven’t tried with larger models. And I’m not sure about the possible concurrency issues that might arise either. So it’s up to you if you want to use this — it feels a bit hackish to me :D

“Seen, gone.” is my first (serious) incursion in Android development. Yeah!

As the description says:

Take a picture, watch it morph into something different – yet related to its true origin. And before you can blink twice, it’s gone, destroyed by the very same hands that created it.

To escape from the usual demoscene non-interactive demonstrations, I decided to do something interactive but that still used a bit of processor power, so that I could see what could the platform do. I had already tried to do some audio stuff, but the results were a bit disastrous. I might come back to that field again; maybe I will be more inspired or I will know how to do things ‘the proper way’ and it will end up being a more satisfying experience.

For this, I began using Canvas and only integer math to speed things up but the results were horrible; using Canvas for this was just too much and there weren’t available cycles for anything else. It was unacceptably jerky. I even showed the app to my favourite betatester and he told me that he would uninstall the application immediately.

Since I was determined to improve things, I watched the mighty session by Chris Pruett at past year’s Google IO and understood why things weren’t quite working the way I expected them to do. After much cursing myself for not having watched the presentation before, I replaced Canvas with OpenGL ES –in which I still miss good old immediate mode, but hey… it’s way faster!– and float calculations (to my surprise, you can even afford a few float operations!), plus reorganized pretty much everything, and rewrote the rest. Core calculations could probably be optimized with native C code but I didn’t want to limit myself to non-portable code yet. Although… are there any Android devices which are not ARM based? Heh!

It’s been a very instructive experience; I’ve learnt a lot doing this –the Garbage Collector and I have become almost close friends, so to say– and obviously it will help me to create more Android applications in the future.

But in the meantime, there’s another demo waiting to be finished!

And yes, this app is what I wanted to finish a couple of days ago, just in case you missed that post.

Today I decided to do something different. And I thought: Okay, I’ll try and sort out this compiling for windows issue, so that I can focus on the rest of more important things without having to worry about it any more.

And guess what…? I think I managed to do it :-)

Roughly, these are the steps I followed, just in case someone else wants to compile for windows with opengl and sdl support, using [ubuntu] linux:

• install mingw (I did it with Synaptic Package Manager so that I didn’t have to go through the ./configure and ./make hell)
• get the dev libraries from sdl for windows/mingw –this file– or check their downloads page
• uncompress the file and locate the bin, include and lib folders within, and…
  • copy bin/SDL.dll to the folder where your win32 .exe will go — so that the exe can pick and load the dll when executing
  • copy the include and lib folders to a folder in your project’s src folder — or anywhere you’ve got access to! For example: project/src/libs/sdl/
• now in your main.cpp, include SDL’s header files like this:
  #include <SDL/SDL.h>
#include <SDL/SDL_opengl.h>
• And the makefile could be something like this too:
  WINDOWS_SDL = ./libs/sdl/windows

windows:
        i586-mingw32msvc-g++ -I$(WINDOWS_SDL)/include -L$(WINDOWS_SDL) \
main.cpp $(WINDOWS_SDL)/libSDL.dll.a -o ../test.exe\
 -lmingw32 -lSDLmain -lSDL -mwindows -lopengl32 -Wl,-R.

(ugly hard line returns added by me so that you can see all parameters in one go).

This assumes you are invoking make from the src folder. The output will go to the parent folder. But well, the most important things that need to be highlighted are the bunch of switches you need to include in order to get the program to link:

-I$(WINDOWS_SDL)/include — this tells the compiler where to look for additional header files. This way it can find <SDL/SDL.h> and you do not need to modify the file or add #define’s when building for linux.

-L$(WINDOWS_SDL) — pretty much the same but tells the compiler to look for static libraries in the WINDOWS_SDL folder too

$(WINDOWS_SDL)/libSDL.dll.a — links the library into our binary!

-lmingw32 -lSDLmain -lSDL -mwindows -lopengl32 -Wl,-R. — these are magic – remove any of them and the linker will complain about missing symbols ;)

I still have to test this in a real windows machine; so far I have just tried with Wine. The output is a little jerky and a bit slower than the native (64 bit) counterpart, but I guess this will do much better than compiling in Virtual Box and testing with Wine :D

I’ll try to upload a test .exe when I test it on a real windows box myself, so that you can test it and see if it works in your computer (if you want, of course!). It’s ages since I compiled anything for win, and I truly wonder whether it will work with Vista/7… my last demo for Windows was done in 2005 and XP was in full glory back then :P