10 thoughts on “Building Agressively Compatible Android Games

  1. As Chris Pruett says must developpers write their games in C++ to be easily present on different mobile OS (android, iOS). As a professional game designer porting games on these different markets is for me a major concern. Consequently, how would you consider the iOS port of an Android game built with libgdx?

  2. Libgdx is running on Windows, Linux, OSX and Android. It’s a mix of Java, C and C++. Given Apple’s stance on VM’s on iOS there is no way to port libgdx apps to iOS due to libgdx being a Java API at the end of the day. The same is true for WP7 which does neither support native code nor OpenGL ES to my knowledge.

    We focus on the Desktop and Android, iOS and WP7 will most likely never be a target. Check out Battery Tech by Battery Powered Games. It’s probably exactly what you are looking for.

  3. In fact i was underwhelmed by the presentation. The two he did last year and the year before where way better in that time.

    This presentation did have very little new stuff i think.

  4. I think the talk is excellent because it summarizes all the common pitfalls and gotchas you as an Android game developer have to watch out for. I’ll update the post with a textual summary of what was said (plus my own bullshit were appropriate).

  5. That was an awesome presentation. I like how he takes it all a bit more loosely then the other users, and he seems more dynamic during the presentation. Also, the questions asked afterwards were interesting, too.

  6. Hi,
    after watching his talk I started looking for a way to ask him a question, but that seemed to be very hard to do so I’m gonna go ahead and ask it here hoping that you can help me instead. 🙂

    Anyway, at around 11:05 he mentions that what he would have liked to do differently was to ship it with high-resolution graphics to avoid it looking pixelated on high-resolution displays such as tablets, and that makes sense of course. My questing is how you would actually do that? If I would just do like he did, but target a higher-resolution display, and simply let OpenGL scale it down on smaller displays I would end up wasting huge amounts of vram on lower-end devices (due to having loaded the high-resolution graphics).

    If I however would scale down the graphics on load time or simply ship it with several different resolution graphics, how would I make it the correct size on all screen sizes? Like, let’s say I target 320×480 like he did, and have a player asset that is 32×32 as well as a high-resolution version of it that is, let’s say, 512×512, would it look alright if I simply set the scale of the 512×512 graphic to 0,0625 (32/512) and then let OpenGL scale the entire “window” to the high-resolution display?

    (These measurements are probably not correct to any resolution, it’s just an example)


    I am using libGDX of course, if that matters.

  7. I m specially concerned about the new native architectures as commented on the last question. The speech was very good overall… with points that even if you already know, you would be sure they are worth remembering.

  8. Anton, you are pretty much spot on. I wouldn’t be to worried about wasting VRAM actually. However, prodiving multiple sets of assets would probably be the best solution. You don’t necessarily need one assets set for every resolution out there, but rather have one set per screen class (e.g. QVGA, HVGA, WVGA etc.).

  9. Bira, i wouldn’t be concerned about the new architectures at all. Unless you wrote some ARM assembler to speed things up everything should be fine. We’ll have to adjust some things in our native code (mostly the Tremor ARM optimization and similar stuff) once x86 is officially supported by the backend. But that’s about it.

Leave a Reply

Your email address will not be published.