I am planning to develop a game for all of the mobile platform and have pretty much zeroed down on the concepts of the game. but the only issue I'm facing as of now is that I have no idea what would be the best libraries + 3d Engine to us to achieve the best results on the hardware on some of the upcoming mobiles. I'm talking about the iPhone 3GS, the new WinMo and Android devices with the famed Snapdragon, other processors from Samsung, ARM, Qualcomm and even Intel and AMD.
as of now i plan to use the ogre libraries for now, but then what will offer portability?? This is much more of a design question rather than just coding. Any help is appreciated, others who wish to collaborate are very much welcome too. just drop me a mail.
I don't know much about Window Mobile, but (right now) there is a barrier to compatibility between Android and the iPhone: managed vs. native code. Android highly encourages you to write in Java, whereas the iPhone requires Objective-C or C++ (or C). Though Android does have a native development kit, they don't currently expose many libraries. They will add more APIs over time, but the Android devs will continue to encourage Java development, since Dalvik bytecode will run on any new device.
This is just my opinion, but I would focus on just one platform at the start. Pick your primary platform, write your core game code in portable C++ if you can, and keep the platform-specific parts separate from your core game code. Your goal is to get your game published. Once you have some money coming in, then start focusing on your second platform's port.
I would recommend you to use OpenGL ES and STL. Both Android and iOS platforms become more compatible with OpenGL and STL library, and it looks like every other mobile platform would follow this course (except, perhaps, Windows Phone 7.)
Related
My question is - is it possible to compile a C++ library that uses some desktop features on mobile device - in this particular case the Irrlicht Engine? I know there is a port out there that uses OGLES drivers, but it also combines using the NDK. I would like to know if there is a possibility to build that library with such a tool like CCTools despite the fact that mobile devices use OpenGL ES - maybe some kind of equivalent libraries, that fit both mobile and desktop environments? There may be some incompatibilities, I know.
The system of input and output doesn't matter at the moment.
And of course - I haven't found the question that fits my expectations.
I wrote an article about porting desktop OpenGL apps to Android that might help:
http://software.intel.com/en-us/articles/porting-opengl-games-to-android-on-intel-atom-processors-part-1
I don't see the advantage of using CCTools rather than the NDK. I think the differences between OpenGL and OpenGL ES would be the biggest problem.
I need to develop application that has a lot of sliding graphics and 3d animations for showing pictures representing products in a very interactive and fancy manner.
Here is a sample of what I'm trying to do http://www.youtube.com/watch?v=ZKCAPSzgoHM&feature=related
I heared that adobe air can do the job perfectly, is that true ? the application is not just sliding of course, it will connect to a server, synchronize some data, log information and so on
So, what is the best solution to accomplish this task?
Short answer, Yep it can. and yep it's true.
Long answer, since AIR3.2 stage3d was introduced to the air platform. Now AIR (as the flash player does) can takes advance of the gpu to render complex 3d content.
Molehill is the new codename of the 3d framework for AS3, you for sure find lot of material on it.
What i suggest you more is using a library/framework built above Molehill (that is indeed just a set of primitives with a low level style syntax). Flare3d, Starling (for 2d), Away3d (4.0 or above) are just few names.
Using this libraries will allow you to fast develop what you had in mind.
All the other tasks you mentioned (connection , log, sync) are pretty easy to do on air.
Now downside of choosing the AIR platform for mobile development on android. Since the introduction of the 3d is pretty recent, it is hard to say exactly the devices supported and the devices that simply fallback to the common 3d rendering system (that is cpu hogging, so not a good choice for mobile).
If you aim to target last generation devices you'll be pretty ok, and you'll find in AIR + flash platform tools a strong benefit in terms of development speed.
I have been developing for Android since some time now and I found Java as proper way of doing development in it. But, now there are number of options available for developing in Android such as Titanium, PhoneGap and Adobe AIR.
The question is who will come as a winner for Android development. I have read lot of comparisons between Titanium, PhoneGap and native Android development. Now, with Adobe entering into it too, what is the future of Android Developers who develop with Java as the programming language.
Since, if one can develop for Iphone and Android with Titanium and Adobe AIR then why will one want to waste time and money for separate development.
The biggest reason I can think of is that using the native language/libraries of the platform (in this case iPhone or Android) is that it will allow you to provide a user interface/experience that is more in line with what the system designers intended over what will likely be possible with something like Adobe AIR.
That doesn't necessarily mean that AIR is bad, or that you might not be able to develop a good application, but since you'd be targeting multiple platforms with the same application code, and each platform has it's own subtle (or major) differences that you can't always account for, you will inevitably be forced to take a "least common denominator" approach to building an application that will run on all of your target platforms and behave consistently across them as well. This might not sit well with some users who expect a certain level of capability as you may not give them a consistent user experience compared to other native applications.
This is a long-standing issue with cross-platform application development -- the design philosophies and behavior of each system are intentionally different (otherwise why would anyone use them?), so your bound to run into problems making an application work 100% the same across them all.
As someone that has done cross-platform development in the past, I can say that while you can do it well in some cases, and using something like Adobe AIR might be a good avenue towards getting more familiar with a particular platform, but a lot of times it's just more prudent to buckle down and build an app using a system's native libraries/languages over a cross-platform solution.
It is quite simple actually. Developing an Android application using Java (the normal APIs) will allow you to a) target possibly all Android devices as all share the same base API and b) it won't put limitations on your application (or at least no limitations with the only limitation being the API).
Now PhoneGap, Titanium and Senza are all web-based frameworks which have certain limitations. You can't access certain functions of your phone as they simply are not some kind of replacement API it's just a framework.
Now Adobe AIR is another story. I'm not sure what functional limitations Adobe AIR will have but I know that there is quite a limitation when it comes to what devices you can target. There are some minimum requirements for Adobe AIR to operate which are
Android Device Requirements for Adobe
AIR
Google Android 2.2 Operating system
ARMv7-A Processor OpenGL ES2.0 H.264 &
AAC H/W Decoders 256 MB of RAM
Which means you can target devices with earlier API versions.
Titanium compiles to native platform controls, but you must to use web languages like HTML and js to develop your application.
With special version for each platform you can design UI following system guidelines.
There seems to be an overall confusion regarding what Titanium is... It compiles to native platform controls.
The majority of the respondents have incorrectly stated that it is web based and that is not true.
However, that is true when it comes to phoneGap
Has anybody blogged about this comparison, or does anyone want to give it a shot here? Would be nice to see some reasoned thoughts on Adobe AIR on Android vs. the "native" Android SDK (in Java).
Edit: Despite few views and no answers, I'm leaving this question up here since it's a topic that needs to be covered at some point... but if it gets no attention I'll delete it in a few days.
I think it's ultimately very similar to the question of whether to use AIR or Java for a desktop application. Ultimately it comes down to three points:
Does AIR do everything you need? Obviously the android SDK gives you complete access to device capabilities, but AIR purposely doesn't, in order to stay portable. For example, AIR may not support intents, at least initially (I don't think Adobe has announced yet one way or the other). Also, AIR requires Android 2.2. If those limitations are troublesome, regular android SDK may be best.
Are you looking to make something that would be well-suited to doing in Flash? If you're planning a design-heavy app with animations, video, sound, or the like, then building it in Flash may be significantly easier than using Java. On the other hand, if your app will be pure code using only standard visual components, then it might not make a lick of difference which platform you use. Or on the gripping hand, if you'd have existing Flash animations or the like, then trying to shoehorn them into a Java app will be bothersome.
Are you targeting other platforms besides Android? If so, AIR may be a big win, as the same app content should run on windows, mac, linux, and later on, other devices that plan to support AIR, like Blackberry, some TVs, blu-ray disc players, etc. If you are only targeting Android, AIR may lose some of its appeal.
I hope that helps some. Realistically, unless you're effectively locked out of using AIR because you need something it doesn't give you, or effectively locked into using AIR because you're doing design-heavy work and you need the tooling, then I think the pros and cons of the two SDKs are largely questions of convenience. Either platform will work, so it's merely which will get you to the finish line the fastest and most reliably.
One issue to consider is compatibility with Android devices. Both fancy smart phones and cheap phones run in Android, but they don't have the same capabilities. Even if you application is simple or can be done beautifully in AIR, its relevant to mention that AIR is not compatible to all Android devices.
Some very popular devices currently sold (such as Samsung ACE and other "cheap" devices) use ArmV6 chips, and AIR or Flash are not compatible to this architectures, even when running on Android 2.2 or so.
AIR is interesting because same development works in different technologies, but consider that AIR doesn't run on "old" iPhones either, its only guarantied to work on new technology with big processors.
Check this Adobe link http://www.adobe.com/flashplatform/certified_devices/
AIR should be ruled out in your decision of technology if in your requirements you are targeting as much phones as possible, including those that are not so fancy or new.
I have experience with AIR mostly and little with Android SDK when I was building a native extension to AIR. My biggest hurdle with AIR is it's immaturity, it's bugs, and it's inconsistent behavior. Yes, you can go to the shiny page at adobe.com and see how cool is the AIR... All bright with tons of features which seems to cover all your needs. Yet, once you start building your app you'll find many ugly surprises:
Stage text in not working appropriately. link besides this bug StageText has few other bugs, like behavior in Scroller for instance.
Sound() object doesn't play the stream (it does on emulator only). link
Lack of features like AEC makes AIR useless to whole list of chat applications, as you'll will hear echo and screaming noise. link
Overloaded (and immature for mobile) Flex SDK (I hope folks at Apache will rewrite it from 0 and make it more manageable).
No H264 support on iOS devices: link (yes, I know it's Apple problem, that they want to control HD delivery on their platform, still it's Adobe problem too, as they couldn't fight right to bring their technology to forefront).
Sound object doesn't take variable bidrate (only 44.1KHz is possible). Flash "second generation" Speex codec samples at 16Khz. Now, try playing this back through Sound and you'll enjoy a funny circus. At the end you will need to write your own upsample algorithm.
I'm sure people will add more to this list. So, my answer would be native SDK is more preferable for anything serious. You won't work like a QA person with it - testing countless little examples trying to understand why an AIR feature not working, shuffling internet for answers and looking at AIR bug database... only to find that critical bugs are sitting there from release to release. That is my experience with AIR. Going native SDK makes your application not really "cross-platform", but AIR SDK can't claim this title anyway for anything more serious then couple of "Employee directory" examples. And if you will need to build for the other platform, you will just use native tools for it.
GL.
I am going to develop a handheld device which has an Atom processor. I am thinking of using Android embedded OS for running telecom applications on this device. I have heard from my friends that Android is good for wireless applications. But my device does not need any wireless application. I will need only data (ping, traceroute...), IPTV and VoIP applications to run on this device. So is it advisable to use Android for my device?
In my opinion the biggest benefit you get from running a OS like Android as opposed to a tailored Linux distribution are:
An application ecosystem, that integrates well
A UI environment suitable for small screens
An Application SDK that makes developing new apps pretty straightforward
Drawbacks of using Android IMHO:
No standard libc. That means you will have to do some porting, to get mplayer or something similar to play your media content
Way less libraries than you have, when you use a "regular" Linux distribution
You can only create apps with UIs using Java (well there are other possibilities but you probably wouldn't do it)
It comes down to choosing what hurts less. My estimate if you have powerful hardware and a big screen (the combination of Atom and IPTV sounds like that) than using a LFS (Linux From Scratch), Ubuntu or something similar and create a flashy UI on top of that (using QT, OpenGL, GTK, Swing, ...) is less pain than porting your libs & apps to Android.
Of course you loose the sexy Android label which decreases probability of making it to Engadget :-)
Have fun tinkering!
Android uses a Linux kernel, and is designed to support Java applications. So perhaps you need to consider whether Linux and Java are suited to your application. You may be better off with a straight Linux kernel.