I've been working on a game engine runtime environment in C++ for my future games, and have started to consider android as a platform. I noticed that it was tightly bound to Java and uses Java VMs heavily.
But is it possible to sustain a full C++ runtime environment in Android NDK? I have nothing against Java and am prepared to use it if I have to, but performance is one of my prime concerns (I intend for my games to be resource-intensive), especially on phones.
And if a full C++ environment is possible, how exactly would I implement it in Eclipse Indigo CDT? Would I be able to create a compiled game executable for Android ahead of time for maximum performance? And would there be any additional plugins I'd need to install in Eclipse? Could I use MinGW for compiling my games, or would I need to use a different compiler? If I had to use Java in one way or another, would compilation of the C++ code even be required? These are all questions I'd like to answer to get a sturdy development environment going in the Eclipse IDE.
Please know that I'm still fairly new to Android development, and multiplatform programming in general. My goal is to create a game engine that'll take the most advantage of the new hardware out there, especially on phones!
Thanks for any advice you guys can give!
NativeActivity, added in Android 2.3 (API 9) might be what you're looking for in terms of writing Android games using only C++. http://developer.android.com/reference/android/app/NativeActivity.html
However since you say you're new to this you may want to start with one of the currently available Android game engines instead of writing your own right away. Mobile devices have a very different set of constraints than other platforms. A phone isn't very useful if the battery dies mid-afternoon, so starting a project with the stated goal of being "resource-intensive" is already getting off to a bad start. Few people will want to play your games for 20 minutes here and there if it means they won't be able to make a phone call in the evening.
If what you meant is that you are shooting for high-end graphics, keep in mind that devices have a wide range of capability in this area and targeting only the high end limits your audience. Different GPUs have very different strategies and performance characteristics and all have cases where they shine or lag behind. The most successful mobile games aren't the ones with the highest polycounts or the most complex lighting shaders, they're the games that achieve a consistently smooth framerate and have a distinctive style.
Have a look at some of the existing game engines for Android and try them out. Write a couple small games to take them for a test drive and see where they do and don't mesh with what you're trying to do. If you find yourself feeling limited with what's available, take what you've learned and try to write your own engine that fits with the types of games you want to make.
Here are some links to get you started. These engines power some very popular games on Android Market and many developers have found them useful:
http://www.andengine.org/ andengine is written in Java and is open source.
http://unity3d.com/ Unity is based on C# and Mono.
http://www.madewithmarmalade.com/ Marmalade, formerly Airplay SDK is based on C++.
The answer you want to pay close attention to is #adamp's. Ignore his answer at your own peril.
To address a couple of other points in your question, though:
Would I be able to create a compiled game executable for Android ahead of time for maximum performance?
No, insofar as Android does not use "compiled game executables". Your C/C++ code will be compiled into a Linux shared object (.so) file and packaged with other stuff (like your manifest) in an APK file. Compiling the .so will be ahead of time, though.
Could I use MinGW for compiling my games would I need to use a different compiler?
I get the distinct impression that you will claw your eyes out trying to do NDK development in Cygwin on Windows. I heartily encourage you to do your NDK development on OS X or Linux. At least set up a VirtualBox with Ubuntu or something in it to do your NDK compiles.
Regardless, the NDK comes with its own GCC compiler. AFAIK, MinGW is not a cross-compiler, and most Android devices are not running on x86 CPUs.
If I had to use Java in one way or another, would compilation of the C++ code even be required?
Yes. Now, for Honeycomb, you have the option of using Renderscript for OpenGL work -- that amounts to a C99 environment whose code you will not need to compile with the NDK.
I've tried a bunch of them, and one of the best I found that cross compiles instantly to a bunch of other devices and let's you program your goodies in HTML5/C++ combo (sweeeeet) is MoSync (http://www.mosync.com/) and another little known one that is a little more setup friendly is MotoDev by Motorola (http://developer.motorola.com/tools/motodevstudio/?utm_campaign=mhp01092012&utm_source=mhp&utm_medium=mws)
I've noticed there is some virtual machine images and tutorials you can use to prevent the setting up hassle.
Related
I have a pretty large project written in C++ for Windows, with some MSVC-specific fancy things, like __declspec(property), usage of SEH, extra template and macro flexibility, intrinsics and etc.
In a nutshell it consists of various applications and a shared library (lib), which is a pretty large "algorithmic" code. It's written entirely in plain C++ (MSVC's version of it, as I said), not dependent on any 3rd-party, all the code is "hand-made", no stdlib, STL, Boost or etc.
Now this code needs to be ported to mobile platforms, namely Android and iOS.
The code should be platform-independent. No explicit dependence on OS, besides the very basic things, like heap memory allocation. It does depend on some Windows-specific things: SEH, TLS, but those are the things I can sacrifice, if they can't be replaced.
And I'm thinking about how to deal with it. Cleaning the whole code from MSVC-specific stuff is possible, but not convenient. I'd prefer to keep them, and definitely I don't want to keep several codebases for different platforms.
So, what are the options at my disposal?
As I understood, there are C++ compilers for Android (part of NDK), but they are probably standard C++ compliant. Anyway, iOS development is based on Objective-C, which is a superset of plain C.
This led me to an idea to "compile" the existing MSVC-specific C++ code into a plain C. There is an option in MSVC compiler to generate "listing" files, containing the assembler code. I guess if there's an option to create appropriate listings containing C-code. Or alternatively MSVC-compliant 3rd party C++ -> C converters.
Any thoughts?
So, what are the options at my disposal?
Write portable C or C++ code.
I've got C and C++ libraries that run on Android, iOS, Windows Phone, Windows, BSD, OS X and Linux. The library is written once and it runs everywhere.
While the "core library" is portable C/C++, the next layer up is not. That's where the libraries integrate with the platform. For example, the iOS test suite driver has a Cocoa/CocoaTouch UI on Apple platforms, and an MFC test suite drive on Windows and Windows Mobile. And the test suite drivers on Linux are command line because I don't waste time with GTK or Qt.
The routines to seed the random number generators are platform specific. I consider them a core function, so its in the core library and guarded by platform specific #defines.
Don't make the mistake of re-implementing your core library on every platform it runs on. That means you will need 4x to 8x the development cycles to duplicate the code and behavior. And there will always be small, hidden behavioral bugs that you waste countless hours tracking down.
And I'm thinking about how to deal with it. Cleaning the whole code from MSVC-specific stuff is possible, but not convenient.
Yes, do this. Pay the tax once and enjoy the benefits for the remainder of the code's life.
This led me to an idea to "compile" the existing MSVC-specific C++ code into a plain C.
No, I would not do this. Remove the platform specific stuff from the core library. Make the core library portable.
MSVC++ to C compilers come in the "if you have to ask, you can't afford it" category. Just too small a market.
A more realistic chance would be to wait what Microsoft is doing. They're seriously looking into targeting additional mobile platforms with MSVC 2015.
TLS is probably the easiest, as that is standard C++ (thread_local). SEH should be mapped to regular C++ exception handling, which means you need to trap pointer bugs before they happen. MSVC isn't exactly known for extra template flexibility, it's in fact rather inflexible. x86 intrinsics obviously are right out on ARM.
We have a working OpenGL project made for PC (works on MacOS and Linux under Wine as well) which we want to try to cross-compile to tablets. Delphi XE2/XE4 offers iOS support, but there's no Android yet and judging from iOS implementation history it might take 1-2 years. Now we start looking into other possibilities which will allow us to keep the majority of Pascal codebase (80k lines). So here's the question for the Oxygene:
Are there any examples of OpenGL applications made with Oxygene that can be cross-compiled to work on PC/MacOS/iOS/Android ?
If not, what alternatives are there (except Lazarus)?
AFAIK there is none.
Even the low-level Sugar cross-platform RTL is not finished. It would be a first mandatory step to be done before accessing higher level libraries in a cross-platform way (i.e. with identical source code), like OpenGL.
So with Oxygene, you have a great cross-compiler, but you are tied to use the RTL available on each platform.
You can compare with two object-pascal compilers:
With FreePascal, which has built-in OpenGL units, and already several libraries over it - one of the most powerful/known is GLScene;
With SmartMobileStudio, which has built-in WebGL support and can do amazing things on modern browsers - WebGL is a translation of the OpenGL API/concepts in HTML5.
Oxygene doesn't attempt to be source compatible with Delphi. What's more the runtime libraries used by the various Oxygene flavours differ entirely from those used by Delphi. So you won't find any serious libraries that have single source that can compile on Oxygene and Delphi.
The way that RemObjects have developed Oxygene on different platforms is quite interesting and radically different from the approach taken by Embarcadero with Delphi.
With Delphi the goal is that you can single source development for all the platforms. That is made possible by the FireMonkey framework which presents a common interface to all platforms. Obviously you need to vary some elements of an app to account for device differences.
With Oxygene, each platform is targetted separately. So for Windows, the runtime is .net. For Java it is the JVM and for Apple platforms you target Cocoa.
All this means that you cannot expect to write a GUI app in Oxygene and have it work on multiple platforms.
So not only can you single source your app between Delphi and Oxygene, you cannot readily single source multiple Oxygene targets.
Now, you can probably port to Oxygene or FPC without too much trouble. But maintaining single source is liable to mean a lot more effort. Whether that's worth the effort is debateable. In the long run you'll want a codebase in one of Delphi, FPC, Oxygene, or even something radically different. But you won't want your code spread out over multiple languages.
You can write or own OpenGL layer in Oxygene with the usage of mapped types like it is used in the sugar open source project.
It sounds pretty cool. In your code you have just to use one class which is during compiling direktly mapped to the underlying platform class method, without an overhead of that layer.
IMHO, when Oxygene is growing, we will then find a lot of such "suger" layers and write once compile anywhere will come closer :)
Edit:
Using OpenGL with .Net
OpenGL Java Tuturial
I have game (of cards based on Contract Bridge) written in Qt (QML) for KDE, now I'm supposed to port the entire game to Android (with Android apapted UI of course). At first I considered to use Necessitas (a Qt port for Android) but found that it is still under development and is currently in 3rd Alpha. I'm new to Android development (as well as game development), while I have experience working in Java, C++ and web technologies like HTML5, JavaScript.
Hence based on my skills, I considered using MoSync. But I'm not sure if I'll be able to use any existing modules of game already developed in Qt (while in MoSync its possible to invoke C++ code from JavaScript and vice-versa), and since I didn't worked on the Qt version of the game, I'll first have to refer to that code and then I'll be working on Android version of the same. So I need suggestion that from where should I start. Also, I have 1.5 months of duration to complete the project (without any working hour constraints), so also suggest me if its a good idea to work from scratch using Android APIs.
Please let me know if I need to elaborate the question even further.
Thanks.
I recommend taking a look at V-Play (v-play.net). It's a cross platform game engine based on Qt/QML .
If your game is already written in QML, you have the least porting effort because you can use almost all of your existing code, and use V-Play QML game components for handling multiple display resolutions & aspect ratios, animations, particles, physics, multi-touch, gestures, path finding and more (API reference).
You can also take a look at Benefits to find out if V-Play satisfies your demands.
Qt is more cross-platform than ever now. instead of porting, just modify it a little and continue with Qt, then compile for iOS, Android, etc.
I'm not sure if this is the best place to ask this question so if it isn't please let me know and I will move it. I am looking to create a game for both Android and iPhone platform. I know Unity is a great game engine and my question is how well does it work for creating one code base to build for both Android and iPhone platforms? Time is a constraint on this project so I am very interested in how smoothly the process usually is when trying to build both applications and how much custom code must be written for each specific application. Any insite that people have on this topic would be much appreciated thanks.
Unity, as implied by it's very name, is designed explicitly to facilitate such multi-platform development in little time. You can for example define for each platform what the max size of each texture is, and it will automatically resize them for you when you build for that target platform - the build process really simple too. Since both your platforms are touch devices, it should be easy to have just one code base working seamlessly for both platforms (and more if needed), with very few custom code for each platform.
Unity has a no-questions-asked 30 day trial of the Android and (I think) iOS versions - I encourage you to try them and see for yourself how little time it will take you to have a proof of concept build for both platforms.
I know C# rather well and just love Visual Studio as IDE. :) Yet now I want to start developing for android...
I found out about MonoDroid and wanted to ask if it has any downsides to it that would make Java more preferable, or should I uninstall Eclipse and dive straight into MonoDroid?
If I understand right, MonoDroid deploys/compiles native android applications and does not need any additional .net-like framework or anything?
Are there any significant limitations to what I can do with MonoDroid? For example, having the app run in the background or using some external .net libraries for image editing, etc. ?
I've been worrying about the same thing - productivity in C# instead of playing with an unfamiliar language, vs developing how the OS developers intended it to be.
Its easy to list pros vs cons -
pros (of monodroid, for C# developers)
familiar dev environment, can develop using Visual Studio
C# instead of Java
Reusable code assets - you can use a lot of code in your iphone project or Windows phone 7 project using monotouch and the WP7 SDK.
cons -
debugging could be difficult, due to lack of api documentation from Google. Will have to depend solely on monodroid documentation.
there could be a lag when it comes to latest cutting edge features - safe to assume that the monodroid team will require some time to wrap around the latest android features every time there is a new OS release
availability of libraries - I am not sure how you can use the open source libraries that would have evolved around the android platform, that could cut down on development time
Much of the documentation available is in Java: so if you run into difficulties with phone behavior when using MonoDroid you won't really find that much help or debugging information so you may want to stick with Eclipse.
There's a lot more than just a set of wrappers running under davlick, truth to be told, there is much more of a horizontal relationship between MonoDroid and Android;
When did using the same language as the OS developers become a big issue? There's lots of C++ programmers wondering how to use BSD or SVR5 and many C programmers who want to know what the heck to do on Windows++...
If you will write in c# anyway you will be have to wrap it into a Java code, so what's the point ? Also you may head with a very difficult issues while trying to understand the APIs who written for Java programming...
Here are some points that you can mull over:
Android applications are predominately written with Java. The Android SDK itself is natively written in Java.
Working in Mono may not provide all the functionality available in the Java SDK.
If you are a C# Developer you wont be able to find, in Java, some of the (cool) features available in C# (like Property Delegates etc).
Code written in .NET can be re-used for other environments - this may save a lot time that would have been spent learning a new language/environment (like Objective C), and coding in it.
.NET extends the Android development stack with it's existing libraries and API's.
I think both are good for certain reason. It will be very hard to say which one is preferable for Android development - in the end that is up to you too decide.
Also note that any release build using monodroid adds an additional 4mb to the apk filesize and increases app startup time with a few seconds.
For simple apps this can mean a 500-800% increase in filesize - whic is pretty bad in my book.