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
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.
I've been searching solutions for my enterprise apps, at least 3 platforms need to be supported, which are iOS, Android and Window Phone. After a whole day's search, I finally set my eyes on 2 promising cross platform solutions, one is monocross and the other phonegap.
monocross seems to use c# and .net at all, is it possible to access native libraries and languages? I read somewhere it's compiled directly into binaries that can execute on target platforms.
And about phonegap, it uses webviews on each platform to provide the capabilities of presenting user interfaces to final users. As it's implemented via interpreted language and high level apis, the performance may not meet our needs.
Finally, we(my team) decide to give it a try with mono, the architecture is illustrated as bellow:
+++++++++++++++++++++representation layer++++++++++++++++++++++++++
[monotouch,monodroid,silverlight]or [native gui calls] or [html5/js/css]
+++++++++++++representation controller/business logic layer+++++++++++++++
[ mono/c# ]
++++++++++++++++++++++++++++server side+++++++++++++++++++++++++++
[ the cloud ]
I want to use mono/c# to write some common purpose business logic and data structures, and when it comes to some common platform features, like storage service, notifications, I'd like to wrap them up on each platform and expose uniform apis for c#(business logic layer) to use. As to the representation layer, we decide to choose from the 3 optional solutions listed above.
To make this happening, first I have to figure out if it is possible to call native frameworks.
So, my questions are:
1, How does mono work, I mean, are the c# codes compiled into binaries that can be executed directly on iOS, Android and Windows Phone?
2, Is there a mechanism to make native invocations? Like in cocos2d-x, I can call java methods via JNI, and in iOS, c++ can call oc directly. Can I call cocoa touch stuffs in mono with c#?
3, Is it possible to manage all these stuffs in one single project, and how to build them?
4, Are there any better solutions?
Any suggestions will be appreciated, thanks for your patience!
I wonder why Xamarin does not land on the first page of your search result,
http://xamarin.com/features
But that's what the Mono guys created for the C# developers that want to target mobile platforms. MonoTouch and Mono for Android are there each featuring a common library base with Microsoft .NET, and also platform specific bindings.
Your non-UI code should be able to be used in portable libraries and share among them. Microsoft's portable library is Windows specific, and right now I am not sure how much Mono guys can embrace that, but even if PCL fails, you can create multiple platform specific projects based on the same copy of source files (which I did in #SNMP). The remaining task is to develop platform specific UI for Windows Phone, iOS, and Android.
There are tons of articles showing the features,
http://docs.xamarin.com/
and also many successful apps
http://xamarin.com/apps
The best way to learn a product is to try it out (for free in Xamarin's case). This also applies to MonoCross (which is a framework built upon Mono).
I am not familiar with PhoneGap, so you need someone's advice on that.
Disclaimer: this is not a complete answer - but I do hope it answers at least part of your question
I encountered a similar problem when I started cross-platform dev using the Mono products 18 months ago.
The approach I've built since is called MvvmCross - it forked off of MonoCross a long time ago - now shares no code with it (but maybe we'll team up again one day!).
The approach uses PCLs to share code. This is not entirely painless, but is easy after you've done a few setup steps - http://slodge.blogspot.co.uk/2012/12/cross-platform-winrt-monodroid.html
You can learn more about this approach on this video: http://slodge.blogspot.co.uk/2012/12/mvvmcross-video-presentation-xaminar.html
I'm developing an application separately for both Android and iOS using their native SDKs.
However, there's a some module in the application that should support basic 2D (it can also be 3D) abilities such as tilting, scaling, rotating of vector graphics + all kinds of optional fancy effects on simple textured planes for example.
I'd like to host this module inside some kine of a view and that its code will be shared between both the iOS and Android platforms, as much as possible.
I've been lurking around the web for all kinds of solutions.
First of all there's OpenGL, the problem is that I'm not familiar with coding for OpenGL and I wasn't able to understand if the code I will be writing with OpenGL will be shareable between the 2 platforms. It seems like no one actually had really tried to do it with NDK and such.
There are platforms like
a. Clutter (http://www.clutter-project.org/) - Which I couldn't find any example for its usage on mobile devices.
b. Platforms like Unity3D, though I don't think they could help me much because as far as I understand the whole application must run on their platform, and that's not what I'm looking for.
So, do you guys think that it is feasible to share 2d/3d code between the iOS and Android?
If so, is there any method you could recommend?
Or should I just go with each device's native method for 2d or 3d graphics?
Thanks!
Kivy: an open source cross-platform programming language for writing OpenGL-powered drawings, interfaces, visuals, anything, for Linux, Windows, MacOSX, Android and iOS. kivy.org
You can potentially drop using Android or iOS native widgets for Kivy widgets and you're apps will have the same OpenGL-powered interface on all platforms.
EDIT 9/27/11 1pm: I've done some more research. All in all, you should check out these 4 open-source frameworks for yourself and decide which one is best for you (I could list commercial frameworks, but those are easy to find):
Kivy (kivy.org)
Amazing GUI and Widgets library.
HaxeNME (haxenme.org)
Very nice 2D/3D API for making OpenGL graphics.
Amazing cross-platform support. The best of all the frameworks.
Unfortunately, no GUI or Widget library is built in though.
Qt Quick QML (qt-project.org)
Very nice 2D/3D API for making OpenGL graphics.
Similar to HTML, but for OpenGL. Already know HTML and JavaScript? QML (Quick Markup Language) includes basic necessities like text fields, radio buttons, check boxes, etc, which can be animated and controlled with event handlers. Animations, event handlers, etc, in your QML application are written in JavaScript; the difference is the JavaScript gets compiled instead of interpreted.
Qt Quick is really amazing; my personal favorite. Read up on Qt Quick QML then try the Animated Tiles app for Android to see Qt Quick's potential. The newest release of Qt (coming very soon) support iOS, Android, and Blackberry, and all desktop OSes. Windows Phone is a work in progress but will arrive soon considering that Qt Quick already supports Windows 8's Metro platform. Qt Quick is very nice, but it doesn't work on every single platform like HaxeNME does.
MoSync (mosync.com)
A hidden gem. This framework needs more exposure. The MoSync SDK provides a cross-platform OpenGL framework, an HTML/JavaScript framework similar to PhoneGap, a NativeUI framework for writing apps across platforms that use each platform's native UI widgets, and MAUI for writing C++ GUIs.
If you were gunna settle on just writing pure OpenGL, then I'd at least recommend checking out MoSync, as it provides a 1-to-1 implementation of OpenGL ES 1.0/2.0.
Also, if your app will be form based (not so much animated like a game), then PhoneGap might suit your needs. If you use the right features of HTML5, you can make apps that feel native (unlike the many horrible and discouraging examples out there). If you'd like to try an app made with PhoneGap that feels "native", try "Go 2012". The Go 2012 apps proves that if you use HTML5 correctly, you can take advantage of hardware acceleration across platforms (iOS, Android, Blackberry, and Windows Phone (I tested it on all)). The animations (scrolling, etc) in Go 2012 are all CSS3 hardware-accelerated animations. Don't let the poor quality of most of the app in the PhoneGap showcase fool you!
Use OpenGL ES and write the code in C. Write a NDK wrapper for Android. Theoretically, your open GL C code should be reusable between the 2 platforms.
Have you ever herd about small company name Adobe
Try using Air.
People do not appreciate the hard work that Adobe did, but it is the most strong cross platform available in market!
It support:
Windows with DirectX access to speed up your app, both in 3D and 2D.
Linux
Android (2.2 and above) with OpenGL background
iOS with OpenGL
BlackBerry
And many more... If you wish to work on the high level, use Air!
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.
Is there a way to develop classes for Android and BlackBerry ? In this I mean that BlackBerry and Android have different collections.
So I would like to know what is the best way to develop such files (reflection, different files, ...)
Your best bet is to write to a common interface, so that your higher-level code can be consistent, and the parts that will be different, will be abstracted into their own libraries. This way you can write applications that use a common codebase, though most of the work will take place in your libraries, as that is where you connect to the platform.
This way you can try to minimize redundant work, but take advantage of each platform more completely.
If you limit yourself to what each can do then you are shortchanging your users as there are a great deal you will not be able to do, or do well.
We have common code for Android and BlackBerry. You know that BlackBerry is J2ME based so its Java 1.3 compatible, and Android is Java 1.6 I think. This places significant limitations. I will list what I remember below.
All common modules you code has to be Java
1.3 compatible if you want it to work on both platforms. This means
no collections framework, no
reflection, primitive string
handling/localization with strings
in class files etc.
It will be very hard to have ALL code that is works on both platforms. So it is better to have some common packages, then BlackBerry and Android packages that work on those platforms.
Nightly build system is really helpful as it will catch errors that break one platform build, caused by changes for the other platform.