Sign in to follow this  

dev'ing for Android (or other bigger platform)

This topic is 2799 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey there. * Say, I'd like to make small games for mobile devices. * And I don't like to port to a thousand different devices, I'd rather prefer to have one sort of platform that's big enough to have some significant potential audience. * Also, I can't use a Mac for dev'ing, only PC. So it's not iPhone/iPod, heh * More or less easy & inexpensive online distribution of the software would be nice (since I wouldn't be publisher-bound then, which I like. But let's see.) * The games are envisioned as incorporating 3D graphics, so hardware support in forms of eg. OpenGL ES would be nice. Doesn't have to be next-gen powerful, though. I'd even prefer them not to, to make less than state-of-the-art gfx games acceptable From what I gathered, Android looks promising, but feel free to make other suggestions. So I have, for now, a few questions about Android. 1) Java, C++ ? I've read comments somewhere, seemingly by first-hand experienced, that Java, on the Android, is, for games, really damn slow. The guy saying it didn't sound like a newbie. True? I have also heard that, meanwhile, it's possible to write C++ apps for it. But my impression was, that this path is somewhat troublesome... What can you say? 2) Hardware 3D support? I read that HW 3D is not guaranteed. BUT. How common is it nowadays? Am I safe to assume that most widely spread Android devices will have 3D HW ? 3) OpenGL ES version Still version 1.0 only, really? Ugh. Can someone point me to some of the better to best (technically) 3D games on these things, to see what I can expect? Feel free to add important points I might have forgotten :-)

Share this post


Link to post
Share on other sites
You know I was wondering the same thing.

Google had just recently released the NDK (Native Development Kit) for C/C++ code in "performance critical" parts of your Java Android App.

What they mean by that is, that you cannot develop an Android App in just C/C++ code. Which makes it difficult to do if you are porting a game thats built with C/C++ with C/C++ libraries(OpenGL or SDL).

But it can be done! People have done it before, but they've stated how difficult it was because:

1) Some didn't know Java and had to learn [enough of] it, which is not hard "stand alone" but learning it while learning the Android SDK [also the NDK for C/C++] is not easy, you are pretty much diving in, hard.

2) Like you said 3D hardware may not be supported, depending on who made the phone with Android on it.

I want to develop something for the Android device(s) too but... learn Java? I just don't have the time for that personally, to learn Java while learning SDK/NDK. It would be a different story if I had $10,000 to get the Playstation SDK, they have good support for C/C++ and would be easier [and less time consuming] to port.

Share this post


Link to post
Share on other sites
I believe if you're literally looking for the biggest market (available to non-Mac development of course), RIM's Blackberry is the right platform.

Going beyond just the numbers, I would agree with your assessment that Android is the most promising platform. I suspect its growth will outpace Blackberry OS's growth and that the people using the Android phones are probably more interested, willing and able to access the marketplace and buy your game (or app in general).

Share this post


Link to post
Share on other sites
AirPlay definitely sounds intriguing. I would definitely like to know how the process of using it and ultimately deploying to the iPhone goes for you helmi_shariff!

Another cross-platform, mobile development platform I remember hearing about around a year ago was Rhodes. It launched last year and I, honestly, haven't had the time to pay it a lot of attention. Its pricing structure seems far more expensive than AirPlay SDK's approach though.

Share this post


Link to post
Share on other sites
Wow! dude. Airplay. if < 100k / year, then free for iPhone only? And c++ dev on PC, ARM code debugging on PC, this sounds too good to be true.
I'll check that one out.
If it's as good as it sounds, I will be making iPhone apps I guess :-D
Thanks for that hint, man.

Share this post


Link to post
Share on other sites
Most android devices does support GLES 2.0 in hardware, but it's not officially supported by the NDK yet. You can still use it though, by either extracting the libraries you need from the device, to link against for gl2 commands. Or, extract the functions from the gles2 driver in runtime. The later is probably to prefer since it seems that different devices have different versions of the driver, and an application linked with a library from one device may not run on another.

Share this post


Link to post
Share on other sites
Quote:
Original post by UnshavenBastard
Hrm, blackberry.
I guess you're right that owners of Android devices might be more interested.

If iPhone dev wasn't Mac-only, I'd develop for that. But I'm not going to buy a damn ugly overprized Mac just to be able to make iPhone software...

One option is to get a special copy of OSX that can run on a PC. I think the web page is osx86 project. There is also a version that can run on a emulator like vmware. I tested it and it worked.

Share this post


Link to post
Share on other sites
Quote:
Original post by V-man
One option is to get a special copy of OSX that can run on a PC. I think the web page is osx86 project. There is also a version that can run on a emulator like vmware. I tested it and it worked.


Do not do this. You will be violating the Mac OS X terms of use, Xcode terms of use, iTunes app store developer agreement, countless other EULAs, TOS, and maybe even breaking the law.

Share this post


Link to post
Share on other sites
Quote:
Original post by UnshavenBastard
I've read comments somewhere, seemingly by first-hand experienced, that Java, on the Android, is, for games, really damn slow.


I don't know if you are refering to my unanswered post:
http://www.gamedev.net/community/forums/topic.asp?topic_id=559770
:P

But Java is a NO if you plan making your game in OpenGL and use some sort of particle system. If your scene is mostly static, or 3D, then Java will be good enough.

But in my case, our game was on iPhone. Moving to the NDK for Android was a better solution because the code was already all in C++!

The game I'm talking about:
http://www.youtube.com/watch?v=Xpk751kljvs

This video is on an iPhone, but after a few optimization, I got similar performances on my HTC Magic. So Android is definitively a good platform to run games with that amount of things going on. But you have to use the NDK, and beleive me, it's a pain. Some of the clib functions that Google implemented are broken, and absence of the STL libraries.

Share this post


Link to post
Share on other sites
Quote:
Original post by Daivuk
I don't know if you are refering to my unanswered post:
http://www.gamedev.net/community/forums/topic.asp?topic_id=559770
:P


no, that was not on gamedev


Quote:
Original post by Daivuk
The game I'm talking about:
http://www.youtube.com/watch?v=Xpk751kljvs


I have a hard time, playing or just watching these "Japanese epilepsy test" games, hehe. All that flashy stuff!
I would not want so much going on in a game of mine. Yes, OpenGL + mostly static 3d scene was what I was thinking of. I don't foresee the need of a particle system ATM.

The development pains you mentioned don't sound appealing ^^

Share this post


Link to post
Share on other sites
You can do your app in "mostly" C++ on Android, AFAIK, even though it's discouraged.

Android can be found on many different processor architectures in theory (though some ARM variation is most likely, there are x86 devices and MIPs devices as well) which is the reason native code is discouraged -- different native code needs to be provided for each platform, so it makes porting and distribution more of a pain.

That said, if you're satisfied choosing a minimum spec (Say ARM Coretex A-8) and only working on those devices, or others that you specifically support, then you probably only need as much Java on Android as you do Objective-C on iPhone/iTouch, possibly less.

Share this post


Link to post
Share on other sites
Android supports OpenGL ES 2.0 with Android OS version 2.0 and later on the NDK, so you can use shaders on android!

I am really pissed though, that the Java VM is slow on these devices. I have a cellphone from 2005 that can run a gameboy color emulator written in java at playable framerates, yet this 2010 smartphone JVM can't update a particle emitter without crumbling down to low fps. No surprise everyone starts thinking Java is slow :(

Share this post


Link to post
Share on other sites
yes...
This is going to sounds like trolling.
since I've been banned before at GD.

Java is a horrible horrible horrible language to work on and JNI isn't that perfect if you want to create games on it.
I only use JNI to do calculations just like what Google said.
"Critical Performance" for 3d maths

OpenglES 1.0 is horrible
You use arrays to draw now, Blending is limited and there's no display list.

and the Emulator is also not perfect
unless you have a very fast PC

Share this post


Link to post
Share on other sites
(1) The Android UI is all Javalike. It is not Java, but looks very similar. It is different enough that many Java apps will not port.

(2) The underlying OS (Linux) is written in C. If you want to interface with the surface flinger (ie. do accelerated graphics, 2D or 3D) you're going to have to stick to the Javalike API. The surface flinger does not provide documented C bindings as far as I can tell, so you need to read the source code if you plan to talk to it directly, and then you lose things provided by the framework, like locking. You will also be hosed on the next point release from Google, since they do not guarantee any sort of API or ABI compatibility between releases at that level.

If you want to target Android, stick to using Android. Don't pretend it's Windows or IS X.

Share this post


Link to post
Share on other sites
The other disadvantage when developing for Android is that there is already a huge difference in devices. So if you want to develop Android Apps/Games you are going to have to do a few ports(not nearly as bad as J2ME but, still worth considering).
Nobody has mentioned Windows Phone 7 which although there are no devices available for another few months, has a really easy to use XNA setup.

Share this post


Link to post
Share on other sites
Android.
NDK is fiction. You write by hand. C++ with no exception mechanism. Couple of dumb examples using their 'rendering' surfaceflinger 'engine' of some rectangles with textures. JNI interfacing is lame and slow. The data flows ping pongs between C written libraries and Java modules several times. Data passed between modules is packed in a 'Parcel' that comes with a magic number message, hard coded all over the place. Serializing and de-serializing in dump parcel make it slower. Framework architecture is 'google style' all over the place. They know Python, not C not Java and certainly not C++. The 'c' (that's not C, uses C,, well )with classes, the code is terrible (Indentation is the only thing consistent). I think on the whole project someone tried to learn programming and I think finally gave up, and left the mess. With millions you can sustain even shit to be a phone. (I am covering surfaceflinger here...)
Global variables, and gloabal 'smart' pointers, templates, hundreds of lines functions switches, sallow logic and mutexex lockong almost any functionm makes this code the worst I ever seen in the open source community. Let's finish with something good anyway. standard C library has been rewritten: reason to speed the things up, then ober-loaded with JNI and java to slow them down.
And all of this to have a simple 3D rendering engine.
Personally I 'like' this article from their site. Is cool, but the year is 2010 not 1994 and anyway has nothing to do with the code.
http://developer.android.com/guide/practices/design/performance.html
See it for yourself:
http://www.netmite.com/android/mydroid/frameworks/base/libs/surfaceflinger/SurfaceFlinger.cpp

-look at the goto statements in this creation.
http://www.netmite.com/android/mydroid/frameworks/base/libs/ui/SurfaceComposerClient.cpp

Share this post


Link to post
Share on other sites
Quote:
Original post by gyula
Personally I 'like' this article from their site. Is cool, but the year is 2010 not 1994 and anyway has nothing to do with the code.


Actually it *is* 1994 for Android phone hardware, well mid/late the 90's anyway. Those tips are definitely applicable to the embedded hardware found in Android phones, or the iPhone/iPod, or the Nintendo DS, or Sony PSP.
They're all a lot slower than the PC's many new Android developers are used to writing code for with hardware quirks (lack of a floating point unit sometimes) which requires careful thought.

Andy

Share this post


Link to post
Share on other sites
too late now... XD
I've used way too much of float

I've to rewrite or see what I can salvage for Frustum culling and MS3D model rendering
using glDrawElements and other stuff needed for Android.
Now I've some doubts on doing key frame animations on Android

so do you people think it's worth it to use 3d animations in android games?

Share this post


Link to post
Share on other sites
Listen to helmi_shariff above, and check out Airplay SDK:
http://www.airplaysdk.com

It's an amazing product. You can developer Android apps in pure C++ - it uses the NDK under the bonnet but you never need to touch it. And you can deploy to iPhone and all the other platforms listed.

I've been using it for a while and it's a complete revelation compared to using the mobile platform SDKs themselves.

Share this post


Link to post
Share on other sites

This topic is 2799 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this