Mar 08 AT 8:10 PM Taylor Wimberly 33 Comments

Android games to get a boost thanks to latest NDK

The Google sponsored Game Developers Conference starts tomorrow and we are expecting some major Android announcements. In anticipation for tomorrow, Google has updated the Android NDK (r3) so applications can now directly access OpenGL ES 2.0 features. To put it simply, developers have greater control to program for the hardware and can create more robust games (Watch for Mike Leahy’s thesis paper in the comments).

My prediction for tomorrow: Epic games unveils the new Unreal Engine for Android (see Tim Sweeney’s comments).

Source: Android Developers Blog

Most Tweeted This Week

White Nexus 4 and Android 4.3 coming June 10th

Updated: HTC employee teases Google Experience HTC One

Google updating Android without updating Android is the biggest news out of I/O 2013

33 Comments Join the discussion!

Mike LeahyGuest 03/08/10 8:53 PM

Thumb up Thumb down 0
>Watch for Mike Leahy’s thesis paper in the comments

Hey… ;P

This is like good news and stuff… No problems here! ::2 thumbs up for big G::

Err they just gotta now rev the Java API in the OS 2.2 release and get the 2.0 ES bindings accessible for all of us now.. ahem… listening big G? ;P

Keep us posted as always Taylor on the happenings this week, hopefully they are big! I’m going to try and have a demo out this week or imminently too that will include some multitouch coverage.

Reply
- 100 Taylor Wimberly 03/08/10 8:58 PM
  
  Thumb up Thumb down 0
  Haha we love you Mike.
  
  Reply
12 jasonlee 03/08/10 9:34 PM

Thumb up Thumb down +1
This would be very nice indeed we could use the boost in gaming. After all polarblit can’t carry all the weight

Reply
Mike LeahyGuest 03/09/10 1:44 AM

Thumb up Thumb down 0
You knew it was coming; I don’t want to disappoint after all.. Hopefully not thesis paper length; just an abstract really! Read on.. ;P

The following is an interesting observation that does have a lot of impact for Java game dev on Android regarding OpenGL ES 2.x… The situation of NDK support for all 2.0+ devices does point out a weakness in exposing APIs of this nature at the Java level tied to OS version.

As things stand now all 2.0 level devices will have OpenGL ES support natively for ES 2.x. It is wholly unknown when a Java API will be available to use ES 2.X. In fact the outlook is kind of dismal considering that it likely won’t be available at the earliest until Android 2.2 (by the “gods” lets hope it actually is implemented at that point in time). The unfortunate situation is that the majority of devices in the wild won’t get a “2.2″ update until if even likely at all the end of this year and conceivably never for certain manufacturers/carriers/devices. Most devices won’t even have a 2.1 update until later this year.

This move now favors native game development and is a major shift away from Java API level support for low level OpenGL applications. It is MAJOR fragmentation especially since devices will need at minimum OS 2.2 level support to work with an OpenGL ES 2.x Java API if it is even exposed at the next OS release point.

This is a great (unfortunate perhaps) example of the negative aspects of tying Java API level support to a particular OS version release level. I would like to see more Java API support that is not attached to the OS release.

In my perfect world I am using OSGi with Typhon. OSGi allows dynamic loading of components. The Dalvik JVM could be potentially slightly redesigned to work with OSGi or similar technology where new Java API level support could be added dynamically to any Android OS level release and made transparently available to any higher level Java app. A particular device could expose new APIs as they become available and this also would make it possible to back port new APIs to older devices that may never see a new OS update.

This is a fantastic example of how the above strategy could also expose OpenGL 2.x at the Java API level to _all_ 2.x devices immediately. It is one I knew would come into direct practicality with OpenGL ES 2.x support.

Without more information regarding Google’s future plans of which us “common folk” have no visibility into or understand any sort of implementation time line we are SOL.

The only hope now for wide 2.x GL support at the Java layer for all 2.x devices is with the independent Android community. I will investigate this issue regarding support with the Typhon middleware in the coming months as broad availability of OpenGL ES 2.x at the Java API layer is important for the future of real time applications and gaming on Android. We all don’t want to have to write our games in C++ now do we.. Yech.. Let’s keep the work of satan (C++) to a minimum at least for those real time app & game devs that prefer a dose of sanity… ;P

With any luck and I have yet to investigate this angle yet, but if a GL context can be shared with the NDK / native code and the Java layer at the same time (and it seems so.. I just haven’t tried anything yet) it will be possible to create an add on Java API w/ NDK peer that exposes OpenGL 2.x separate of the underlying OS release version. In my case the NDK peer and Java API will be add on components that one can drop into any 2.x+ development project using Typhon.

Hrmph.. More middleware work to do less time to write apps… This is hardcore fragmentation at it’s painful worst… I would love for big G to provide OpenGL 2.x at the Java level for all 2.x devices, but something tells me they are not going to service this need in a sane manner thus perhaps even delaying official support for more than a year before Java level APIs are exposed.

Like I said… HRMPH… ;P

Reply
- 100 Taylor Wimberly 03/09/10 2:49 AM
  
  Thumb up Thumb down 0
  So you are saying some of us might not see the true benefits of this till a year later if ever?
  
  I have the N1 so I don’t really care but still curious.
  
  Reply
  - Mike LeahyGuest 03/09/10 3:29 AM
    
    Thumb up Thumb down 0
    To some degree yes, but the burden on this one is really on developers and not end users unlike multitouch support for instance which affects developers and end users with fragmentation woes..
    
    As things go all 2.0+ devices that support OpenGL ES 2.x can have native / NDK applications written right now. So all 2.0+ devices regardless of future OS version have native access to OpenGL ES 2.x.
    
    The majority of games up to this point quite likely use the Java API / entry points to utilize OpenGL ES. The big problem is that Google is only adding new Java API additions with new OS releases or at least this has been the case up to this point. Unless big G creates a separate Java API not attached to OS revisions then Java level API support will only come at a later OS version such as 2.2 or later. To further complicate matters it’s not likely that the majority of devices in the wild even 2.x compatible ones will see an update to 2.2+ Android OS anytime soon considering 2.2 doesn’t even have a release date as far as I know presently and we all know rolling out OS updates universally has been worse than pulling teeth…
    
    This is a big problem as developers working on the cutting edge now that need OpenGL 2.x support can only create their apps with C/C++. A 2nd problem is that there will be the nasty issue of devices in the wild quite likely even 2nd gen devices not receiving universally updates beyond 2.1. So these devices with 2.1 can have native OpenGL 2.x and not Java level apps/games that utilize it. That is MAJOR fragmentation.
    
    This announcement and functionality definitely benefits commercial game developers as it’s quite likely they will not be switching to Java and reimplement their game tech. This is obviously going to be the case if Unreal is ported to Android.
    
    So while this announcement is positive overall and great to see progress with the NDK / native possibilities it quite likely will lead to a stonewall of Java developer houses with fragmentation of OpenGL ES support at the Java API level.
    
    There is a good chance that myself or another independent Android developer could provide an add on for all Android 2.x devices by the end of summer if not before.
    
    As things stand right now it looks like Google has no definite plans or time line to expose this level of tech at the Java level. Even if they did by the additive process they are using with exposing new Java APIs with new OS releases it won’t reach the larger part of the ecosystem for 1 to 1.5 years (yowza!).
    
    This can neutralize forward looking Java real time app / game development and/or put it way behind the curve compared to native development.
    
    So yes while awesome that initial support is available it’s far from comprehensive support for OpenGL ES 2.x that will cleanly roll out to the ecosystem.
    
    This is another major issue I’ll try and solve with Typhon, but hey I’d be stoked if big G can solve it before me in a way that doesn’t create massive fragmentation at the Java API level.
    
    ——-
    
    As an interesting perhaps more technical tangent each GPU has custom extensions to OpenGL functionality that expose functionality that is only available on that GPU. For instance with the PowerVR GPU in the Droid there is an extension to enable antialiasing that is specific to that GPU. This is simply not available at the Java API level because it is specific to the Droid/PowerVR GPU. The solution I mentioned which can dynamically load Java API support and conceivably any native peers as necessary could also be used to expose hardware and device specific APIs.
    
    Reply
    - 100 Taylor Wimberly 03/09/10 3:53 AM
      
      Thumb up Thumb down 0
      So here is the tougher question. Do all these first gen devices really deserve OpenGL ES 2.0 features via a Java API? I mean will their slower CPU and less RAM be enough to power most of the new games?
      
      Adobe cut off Flash 10.1 for first gen devices, so why should Google support the older devices if they can’t deliver “consistent experiences”?
      
      Reply
      - Mike LeahyGuest 03/09/10 4:30 AM
        
        Thumb up Thumb down 0
        Well.. The problem goes a little deeper than that. All current 2.x devices / 2nd gen devices such as the Droid and the Nexus One and any other 2nd gen device released with 2.1 will not receive OpenGL ES 2.x support at the Java API layer until quite likely at the earliest Android OS 2.2 is deployed to them. This could be quite some time before we see 2.2 deployed to even leading edge 2nd gen devices such as the Droid and Nexus One.
        
        So this potential problem affects all devices 1st & 2nd gen.
        
        Now a particular device has to have a GPU that supports OpenGL 2.x.. Most 1st gen devices indeed do not have this support available, so are unaffected by GL 2.x availability at either the native or Java layer. Insofar you are correct in stating that there are some 1st gen devices that this isn’t an issue for such as the G1 and all other devices using that particular combination of processor/GPU.
        
        The problem is that all devices despite capabilities will not receive a potential update for the Java OpenGL ES API until Android OS 2.2. And as a Java developer this is hoping that big G even updates the Java OpenGL ES API for the 2.2 release.
        
        The problem of exposing new APIs and even custom APIs for a given device at the Java layer is a weakness of the rigid architecture defined as of current by Android and the stock Dalvik VM. Simply put some old school / lowest common denominator software architecture practices are being applied to Android making it inflexible to change without rolling out a whole new OS version with additive additions to the Java API.
        
        I knew this was going to be a major pain point from day one unfortunately and why I really got cracking with Typhon and focusing on middleware support for Android.
        
        There is hope for 3rd party add on support for all OpenGL ES 2.x capable devices including the Droid and Nexus One and any other device running an Android OS version between 2.0 and 2.n when then Java APIs finally appear..
        
        The bummer is that any game dev right now can target all 2nd gen devices running 2.0+ Android OS regardless of OS version only with native code. Java support will lag way behind and only be released in a future OS update and at that that OS update may not propagate through the majority of the ecosystem very quickly.
        
        Basically Google has made leading edge Java game development a 2nd class citizen on Android for the next 1.5 to 2 years or until a 3rd party addition is available. Hopefully they wise up and come out with a solution as soon as possible, but erm… I’d love for them to give a date and acknowledge the issue. As things go we’ll just be surprised one day as they announce any support on a whim just before release. It’s a little irresponsible to developers who need to plan for next generation OpenGL ES titles and engine development.
        
        It gives an implicit unfair advantage to commercial game companies too that have the existing C/C++ tech and or larger teams and budgets to develop for that language. The great thing about Java is that an average developer can write more trouble free code fairly quickly. An advanced Java developer can pull off “miracles” with Java writing tons of bug free code compared to C/C++.
        
        So, in my opinion this issue classifies as super major fragmentation… I’m pretty certain a 3rd party fix to roll out OpenGL ES 2.x support to all devices that support it will come from a 3rd party 1st and not Google. They can prove me wrong though and I’ll thank them; much less work for me… ;P
- Another voiceGuest 08/12/10 7:18 PM
  
  Thumb up Thumb down 0
  I have no problem with c++ since virtually every desktop app and every game uses it. i think visual basic for android would be suitable for you.
  
  Reply
RichyGuest 03/09/10 5:00 AM

Thumb up Thumb down 0
So Mike, the big question (after skim reading your thesis) is:

Am I going to have a game with motion blur in it soon, like need for speed on the iphone?

(Milestone).

Reply
Mike LeahyGuest 03/09/10 5:37 AM

Thumb up Thumb down 0
@Richy

Yeah.. I guess it kind of turned into a thesis didn’t it.. hrm…

>Am I going to have a game with motion blur in it soon, like need for speed on the iphone?

I’ve not checked out that particular app, but quite likely not unless a game uses OpenGL ES 2.x.

Motion blur is possible with OpenGL ES 1.x, but not the same kind as seen in shader based engines which is likely the example you are referring to above. Velocity buffer based motion blur and there are many other techniques as well fall in the domain of shaders / OpenGL ES 2.x.

—-

Now there will be OpenGL ES 2.x games available for Android.. Even right away… There may be a demo of Unreal running on Android very soon for instance.

OpenGL ES 2.x apps & games just won’t be written in Java for conceivably 1 to 1.5 years for most devices in the Android ecosystem unless 3rd party Java API support w/ it’s own native bridge is released for Android. I’d love to see Google support leading edge Java game development on Android, but they may let it slip away and let it devolve to a 2nd class citizen which is really sad if you ask me.. Of course I’m a little biased here having professionally focused on real time app/game dev for Java game over the past 10 years. Java game dev has always had its hurdles to overcome.

I do believe due to architecture constraints and general 80% (just good enough) engineering as practiced by Google will handicap the Java APIs for OpenGL ES on Android with them getting the short end of the stick.

Again don’t get me wrong.. I’m amazed at what is possible with Android, but it is frustrating to see a whole area of development (GL 2.x Java based engines) become a 2nd class citizen on Android and not be possible to pull off for quite some time. I’d love to be proved wrong as that means I won’t have to devote significant development time to creating a 3rd party solution. If I do it at least I’m doing it with the intention to share it as middleware for all Java real time app / game devs to utilize.

Reply
- RandyGuest 03/09/10 7:04 AM
  
  Thumb up Thumb down 0
  I do not have any experience as a game developer but..
  It is my understanding that (just about all) the high quality, 3d games on android are written in native c++ anyway.
  
  For instance ExZeus, 3d homerun battle, exforge 3d….
  Polarbi, uses their own cross-platform engine but it is still written in native c++.
  
  I think this is done primarily because all of these games are simply ports from the iphone. This is probably the way it will be done (porting) as long as the iphone is dominate and it’s easier to port to C++ than it is from java.
  
  For instance, look at game loft. The have the majority of high quality games on the iphone and pre. If and when they do bring them to android, I’m almost certain that they will be ported using native C++, even if the java API’s were available.
  
  Also, only the droid and nexus one are the only devices to support 2.0 on the hardware level so 1st gen devices don’t apply anyway you look at it..
  
  Over all, i think the new NDK is much more of a positive than a negative.
  
  Reply
  - Mike LeahyGuest 03/09/10 7:45 AM
    
    Thumb up Thumb down 0
    You are indeed correct in most of what you bring up above Randy. The NDK update is all positive… The only negative that I perceive is that Google is going to drop the ball and not make an effort to expose quickly the OpenGL 2.x API at the Java API level.
    
    As things go, yes, the majority of games on Android will be C++ if they come from the commercial game industry and quite likely developers who are working mainly focused on the iPhone.
    
    And yes… 1st gen devices are out as far as OpenGL 2.x is concerned; GPU has got to support it… The problem is that all devices that currently run 2.0.1 & 2.1 will not receive OpenGL 2.x support at the Java layer until at minimum Android 2.2 OS release. You are right that luckily we are really just talking about the Droid and the Nexus One plus any other 2nd gen devices that ship before 2.2 OS appears. Xperia X10 and any other OMAP3 or Snapdragon based device as there are several on the market or soon hitting the market.
    
    Quite likely I’ll have to come up with a native GL 2.x bridge and Java wrapper to use 2.x from Java as Google likely can’t be counted on to provide this support in the reasonable foreseeable future.
    
    It only is a couple days work to do this or thereabout if it is possible to share a GL context between native code and Java (all present indications seem positive, but I got to try it out).
    
    It’s just a major disappointment for Java developers.
    
    So yeah.. I never said the NDK is bad or the update is unnecessary.. My main point is that Google likely will let the Java API become a 2nd class citizen as far as real time app / game development goes for the next 1 to 1.5 years. This hopefully being at the worst considering roll out and updates to Android OS 2.2 or later will take time to hit the larger ecosystem of 2nd gen devices.
    
    C++ will reign supreme and is immediately applicable to supporting all 2nd gen devices right at this very moment.
    
    Big G could pretty easily create a 3rd party native library and Java API for GL 2.x and release that separate of the OS… Will they do that though or just make Java a 2nd class citizen for real time app / game dev?
    
    Reply
    - SkynetGuest 03/09/10 9:44 AM
      
      Thumb up Thumb down 0
      @Mike
      So you basically wrote an essay with hundreds of words to say:
      “I hate c++ and I love java.”
      I’m sure almost every programmer will agree with you that java is easier, but come on.. Any serious game developer has had c++ as their only real option for decades, this not as big of a deal as your making it out to be. The only types of developers this hurts are the hobbyists and the rookies, two groups I wouldnt bet on exactly making a masterpeice anyway.
      
      Reply
      - Mike LeahyGuest 03/09/10 11:20 AM
        
        Thumb up Thumb down 0
        @Skynet
        So you basically wrote an essay with hundreds of words to say: “I hate c++ and I love java.”
        
        No.. I wrote an essay on how Java could be made a 2nd class citizen overnight on Android for leading edge development.
        
        Besides you’re statement is kind of loaded cause I’m not making the case that one language is better than the other per se nor do I care to argue about religion either…
        
        I do pick the most effective tool for the job though and regarding my goals desktop and with Android dev that is Java. For a C++ oriented development company that has a focus on consoles or the iPhone that obviously is going to be C++.
        
        >I’m sure almost every programmer will agree with you that java is easier, but come on..
        
        Come on what?
        
        Java is not only easier, but it is more scalable and there are obvious benefits especially with Android to working at the Java level rather than compiling for particular processors. The overhead to support different variety of ARM cores let alone Intel processors and any other processors that may require cross-compiling for native code is a pain.
        
        One would generally choose C++ on Android for a handful of reasons. If one already has a large body of work completed in C++, porting to/from the iPhone is a valid concern, or the Java API is incomplete and doesn’t have access to the latest device functionality (really only low level GL is of issue here though).
        
        >Any serious game developer has had c++ as their only real option for decades…
        
        This is part true and partly not. It’s kind of a loaded statement though. If Java was widely available on consoles it’d be a different landscape today as far as the game industry is concerned.
        
        The issue here though is that Java is widely available on Android, so despite the IF above regarding consoles there is no reason to hobble or accept an out of date Java API on Android regarding leading edge development possibilities.
        
        Java has been a perfectly fine language and platform to complete many types of games.. Crysis, perhaps not, but since 1.4 JVM release, introduction of NIO, and such performance is not far behind native code at all.. When you consider smart usage of VBO and other batching techniques on the GL side there is little overhead to Java.
        
        Besides the game industry in general is not the pillar of great software architecture.
        
        >this not as big of a deal as your making it out to be.
        
        Yes and no.. Perhaps a touch alarmist in presentation, but…. The parts that I specifically state as a big deal are a big deal. If big G takes a year to get Java API updates out to the larger ecosystem that is a big deal.
        
        I also clearly stated the interim solution which is no more than a weeks work of work _at first_. The interim solution is to create a library to marshal data to GL 2.x on the native side and Java wrapper separate of the OS API.. It’d be nice if big G took the initiative.
        
        As once you get to that level you’ve got to manage all the cross-compiling to various processors and all that jazz.. It’s a lot more work to maintain and make sure it works across the ecosystem.
        
        And what, now every _serious_ Java developer is now going to have to do this or sit on their hands?
        
        >The only types of developers this hurts are the hobbyists and the rookies, two groups I wouldnt bet on exactly making a masterpeice anyway.
        
        Huh? It doesn’t take all too much to create a hit mobile game. It’s more luck of hitting that sweet spot where things go viral.
        
        Java is perfectly suitable for _any_ game that can be made for Android. Not a single game available for Android right now requires C++. Not a single game in the future could only be possible because of C++.
        
        C++ / updated NDK is not a panacea for game developers. Because it is still a hybrid application requiring marshaling of input control and audio playback to/from the Java layer and that is a slight performance hit (especially the audio aspects though perhaps native audio support will soon be in the NDK) quite likely making a native app perform no better than the Java equivalent.
        
        There clearly are problems with Kwaak3 for instance between the Droid and N1 (not counting input controls).
        
        The lack and indeterminate time for an update limits all developers using Java on the Android platform from having access to full device capabilities. That is major fragmentation for developers. I’m sure the Java to C++ developer ratio is highly tipped towards Java regarding Android as well.. And like I mentioned if big G officially supports a Java API in OS 2.2 or eek later it’s going to take up to ~1 year at this point for it to make it out into the larger ecosystem.
        
        The missing Java API highlights a pretty large rift that is now showing its head regarding Android stewardship. I knew this was going to be a large pain point from day one. Luckily as far as low level dev goes there are not too many other gotchas like this…
RonGuest 03/09/10 6:42 AM

Thumb up Thumb down 0
It good to see gaming on the Android getting a boost, but there are some game that would take up a lot of space, and Google need to allow market apps to be install on sdcard.

Reply
Dean WilliamsGuest 03/09/10 8:55 AM

Thumb up Thumb down 0
Excited about the increase in games on Android (will be REALLY excited once I have an HTC Desire!), but Mike gives me tired head. And I just had cofffee!

Reply
treefqGuest 03/09/10 11:26 AM

Thumb up Thumb down 0
If the development keeps up Android will also be replacing gaming devices as well. Not only Apple is freaking out. Unless Sony and nintendo make the move to android based gaming.

Reply
Anton SpaansGuest 03/11/10 11:00 PM

Thumb up Thumb down 0
This message came from Romain Guy answering this question about OpenGL ES2.0 and Java bindings:

“I’d also be interested in the java bindings. A not so precise time estimate would suffice so that i can decide wheter i write my own bindings or not.”

Romain’s answer:
“FroYo *should* have these bindings”

http://groups.google.com/group/android-developers/browse_frm/thread/5e93f608ddaa10b1/ecc27511ceb8b639#ecc27511ceb8b639

Reply
Mike LeahyGuest 03/12/10 2:43 AM

Thumb up Thumb down 0
@Anton.. Thanks for digging up the dev email thread in the subject.

The “*should*” part is not a 100% relief.. To be responsible and provide the stewardship one expects from Google the message ought to be “it will be in 2.2″. As mentioned above even if it is in 2.2 it’s not likely we’ll see that on most devices until the end of the year at the earliest. The iPhone having over a 1.5 year OpenGL ES 2.x lead is a bummer at least for us Java devs.

I still think the proper answer is a community driven binding and Java wrapper using NDK r3. That could be done next week given the proper time/effort available (I don’t have it right now).. Even if this community binding only supported ARM processors for the Droid/Nexus One et al. At least having something where devs can develop the engines and next gen technology prior to a wide release of 2.2 / FroYo bindings out to the ecosystem. I still think an interim Java binding for GL 2.x is something Google could pull off with little effort and would be a gesture of good will to leading edge developers.

One just has to look at the LWJGL community as they successfully add the bindings to LWJGL immediately once the header files are available. On the desktop they trumped Sun’s stewardship of OpenGL (JOGL) often by months.

It’s a no brainer to support the latest tech the hardware makes available with software APIs. Often it’s the software getting ahead of the hardware, but in this case the software support is lagging behind far too long… It better be in 2.2! hrmph..

Reply
joeGuest 03/13/10 7:39 PM

Thumb up Thumb down 0
Why won’t google let devolpers put memeory on sd card they shoul support it righ?please answ er mike leahy

Reply
- 16 Mike Leahy 03/13/10 10:06 PM
  
  Thumb up Thumb down 0
  I just happened to be posting an update here, so you caught my attention Joe.. ;)
  
  The SD card is available for any developer to utilize.. The only problem is that every developer has to write their own bridge or system to store data on the SD card from their application and an online server / data store of some sort. As things go in general for development these days the majority of devs are “relatively lazy” (I say this in the kindest way!) and either want an API (application programmers interface / a library of already made code essentially) to be made for them or cut and paste code from somewhere to get the job done. There is a little too much dependence in the Android dev world on Google to provide new APIs and they don’t always get around to servicing particular pain points in a timely manner and quite often when they do Google only gets these additions into the latest Android OS. What they do is great for the most part though there are some cracks and seams here and there.
  
  I’m actually working on a premade component to sell for ~$20 to devs to accomplish this task and hook up downloading of content from Amazon cloud services to the SD card. This should keep event the most expansive games to below 1-3Mb with the rest of the content (any size) stored on the SD card.
  
  Right now there is not much of any middleware on Android which is software that fills in the gaps that the Android OS / and Google APIs don’t provide for currently. Hopefully that will change around a bit with Typhon (my fairly extensive middleware offering) being released darn soon.
  
  Reply
Mario ZechnerGuest 03/13/10 8:37 PM

Thumb up Thumb down 0
Fear not, I made some awesome OpenGL ES 2.0 Java bindings for you. You can find them at http://code.google.com/p/gl2-android/. Additional info can be found on my blog at http://www.badlogicgames.com. All hail Java :p

Reply
- 16 Mike Leahy 03/15/10 4:01 PM
  
  Thumb up Thumb down 0
  Heh heh.. Both of our comments were waiting over the weekend cause of the links and you beat me too it.. SXSW must be good! Thanks again Mario!
  
  Reply
16 Mike Leahy 03/13/10 11:09 PM

Thumb up Thumb down 0
So folks.. I’d like to follow up on the Java binding issue for OpenGL 2.x support in Android. Indeed the Android developer community surprises me at times and Mario Zechner of Badlogic Games the creator of Newton (awesome little physics game on the market; go find it now!) has released an interim OpenGL ES 2.x binding for Java. It took only a matter of hours to do it and I’m glad he did so _and_ released it for all.

It turns out in correspondence he further had with the Google engineer actually implementing this that indeed Google already finished the Java bindings and seemingly are just going to sit on them until Android 2.2 / FroYo release. That is all an well and reasonable from a consumer facing direction, but developers need early access for OpenGL 2.x because it is going to take time to create new games and engine suitable for Android using this tech.

Mario pulled it off in record time and more info can be found on his blog:
http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=343
http://apistudios.com/hosted/marzec/badlogic/wordpress/?p=347

Congrats to Mario and check out Newton. I understand the full launch of Newton will likely come in April, so this is a dev to support!

Whew.. Alright.. what next.. ;P

Reply
joeGuest 03/20/10 6:03 PM

Thumb up Thumb down 0
Mike leahy do u know any games coming out with java.????????

Reply
- 16 Mike Leahy 03/22/10 10:15 PM
  
  Thumb up Thumb down 0
  Not to get all too off topic, but here we go:
  
  If the game comes from a commercial game company or company with an iPhone release first quite likely it’s C/C++. A good deal of games currently on the market are likely Java and definitely they all were before the NDK was released. There will be more Java developers working with Android quite likely over time, so games and other real time apps will be done in Java. Once middleware / engine tech is available it will even be more popular.
  
  Take for instance the Crusade of Destiny and Welcome To Hell by DVide Arts.. Two iPhone games coming to Android.. Well, DVide Arts didn’t make the game engines. They are using ShiVa3D: http://www.stonetrip.com/
  DVide Arts will invest some time in the ports I’m sure, but the key factor is that Stonetrip has ported/released ShiVa3D for Android and that allows game companies using the tech to investigate a port to Android.
  
  ————————
  
  Replica Island is a good example of a Java 2D platformer and it’s open source with full source code and art assets.
  
  http://replicaisland.net/
  http://code.google.com/p/replicaisland/
  
  The developer works at Google and spoke at the Game Developers Conference…
  
  Java is not a disadvantage at all for games or real time apps. I’ll be spilling a good part of the “dark arts” about Java game dev in a detailed tutorial series as part of the launch of Typhon.
  
  I’m looking into converting Replica Island to Typhon and making it the 2D platformer example. Auriga3D will be a fully available 3D engine for folks to explore.
  
  The NDK is great and I’m satisfied now that the Java folks don’t have to wait forever to get at the latest features of GL.
  
  Reply
  - joeGuest 03/24/10 6:25 PM
    
    Thumb up Thumb down 0
    The top game on android market has hardly any sales and has doubled any other game so y would devolpers want to make games for android?
    
    Reply
    - 16 Mike Leahy 03/25/10 12:21 AM
      
      Thumb up Thumb down 0
      Again a little off topic…
      
      Momentum is gaining quite rapidly with Android. Commercial game companies may still wait to fully engage. It’s quite likely iPhone devs with games out and this does include mainstream commercial game dev companies too will be the 1st to bite in mass. The walled garden approach and other negatives for developing for the iPhone / Apple review process is wearing thin on iPhone devs.
      
      http://androidandme.com/2010/03/news/admob-70-of-iphone-devs-plan-to-develop-for-android/
      
      For Android only app developers and this includes Java game devs. Yeah. ROI is not exactly there right at this moment unless ones rent is $500 (good luck with that in SF Bay Area where I live!), but the scales will tip in the 6 month to 1 year time frame. My goodness some of the amazingly cool Android devices coming out by the end of this year will quite likely blow away this years iPhone. I personally can’t wait to get my hands on a device with HDMI.
      
      While Android fits my longer R&D plans which includes custom hardware development it certainly increased ROI on Typhon enough that I’ve taken a great amount of time prepping it for release imminently. Previously sans Android I was going to continue to sit on Typhon and only release it as part of the hardware I’ll eventually release.. Now because of Android there is ROI potential for real time app Java based middleware for game dev or other purposes.
      
      Once solid middleware is available on Android for real time app and game dev (C/C++ or Java) things will certain be on the up! Give it some time.. Android is just ~1.5 years old in the consumer space and has picked up fantastic momentum thus far. Check this simple graph / link on technology adoption. We are roughly in the middle of the early adopter phase right at this point. I expect things to be solidly in the early majority territory a year from now regarding game devs adopting Android.
      
      http://en.wikipedia.org/wiki/Technology_adoption_lifecycle
      
      Reply
joeGuest 03/25/10 5:43 PM

Thumb up Thumb down 0
I know a little off topic but could the droid become old software in a range of 1 to5 years?

Reply
音速工作室Android开发中心 » Blog Archive » Android NDK r3 发布，加入 OpenGL ES 2.0 支持Guest 08/05/10 3:06 AM

Thumb up Thumb down 0
[...] androiddeveloper, androidandme Related Posts:HTC EVO [...]

Reply
Alfonso McbratneyGuest 04/21/11 5:55 AM

Thumb up Thumb down 0
Hello just wanted to give you a quick heads up. The text in your article seem to be running off the screen in Opera. I’m not sure if this is a formatting issue or something to do with web browser compatibility but I thought I’d post to let you know. The layout look great though! Hope you get the issue fixed soon. Cheers

Reply
Peter BurandtGuest 04/21/11 6:21 AM

Thumb up Thumb down 0
Hi there! This is kind of off topic but I need some advice from an established blog. Is it very difficult to set up your own blog? I’m not very techincal but I can figure things out pretty quick. I’m thinking about creating my own but I’m not sure where to begin. Do you have any tips or suggestions? Many thanks

Reply

Android and Me

Google reveals Samsung Galaxy S 4 Nexus Edition

Android passes 900 million devices activated

Best no-contract plans for unlocked Android devices

Best unlocked Android phone for any budget

Android games to get a boost thanks to latest NDK

Most Tweeted This Week

White Nexus 4 and Android 4.3 coming June 10th

Updated: HTC employee teases Google Experience HTC One

Google updating Android without updating Android is the biggest news out of I/O 2013