Good progress - Mixtikl's Audio is now working under the Airplay ARM simulator, so I now need to get it all up-and-running on an actual Android device. Fingers crossed. :)
Edit: Mixtikl is running under the Android simulator using Airplay - amazing. :-D
Many congratulations to Ideaworks!!
Friday 30 April 2010
Thursday 29 April 2010
Mixtikl Airplay port - to Android/Symbian
I've been porting Mixtikl to Qt and Airplay DK in parallel.
Now that the Qt port is done, I've also got the Airplay SDK port running in the ARM debugger emulator.
I've yet to add the audio hooks, and there are a couple of rough edges, but I'm looking forward to trying it all out in a few days on my HTC Hero Android phone!
Due to a weird problem with the Airplay SDK, I'm unable to link for X86 target (I'm waiting for a solution at http://airplaysdk.com/node/761). The same code builds fine however for the ARM Debugger - so at least I'm able to make progress. :)
The documentation has been pretty frustrating, so here are two useful tips to save you time!
- to blend-in an image, use Iw2DSetAlphaMode() to set a colour with the appropriate alpha channel setting before calling Iw2DDrawImage(); the alpha colour setting is used to blend the bitmap! Also, set the rgb values to other than 255, to scale the colour; useful to draw a white coloured bitmap in different colours, for example.
- if you want to clip, then call IwGxSetScissorScreenSpace(...) to define a clip window before any calls to Iw2D*(...).
The routine to query for pointer support didn't work for me - maybe I made the call wrong - I'm having to ignore the result from that call, I need to raise that in the forum once my build issue is resolved. :)
Anyways, Mixtikl now runs on the ARM emulator, so the next step is to complete the audio hooks and try on Android and Symbian devices!
Note: lack of support in Airplay for threads and clipboard will cut-back on some of the Mixtikl functionality for now on Android/Symbian... until those items are exposed in future Airplay updates!
Now that the Qt port is done, I've also got the Airplay SDK port running in the ARM debugger emulator.
I've yet to add the audio hooks, and there are a couple of rough edges, but I'm looking forward to trying it all out in a few days on my HTC Hero Android phone!
Due to a weird problem with the Airplay SDK, I'm unable to link for X86 target (I'm waiting for a solution at http://airplaysdk.com/node/761). The same code builds fine however for the ARM Debugger - so at least I'm able to make progress. :)
The documentation has been pretty frustrating, so here are two useful tips to save you time!
- to blend-in an image, use Iw2DSetAlphaMode() to set a colour with the appropriate alpha channel setting before calling Iw2DDrawImage(); the alpha colour setting is used to blend the bitmap! Also, set the rgb values to other than 255, to scale the colour; useful to draw a white coloured bitmap in different colours, for example.
- if you want to clip, then call IwGxSetScissorScreenSpace(...) to define a clip window before any calls to Iw2D*(...).
The routine to query for pointer support didn't work for me - maybe I made the call wrong - I'm having to ignore the result from that call, I need to raise that in the forum once my build issue is resolved. :)
Anyways, Mixtikl now runs on the ARM emulator, so the next step is to complete the audio hooks and try on Android and Symbian devices!
Note: lack of support in Airplay for threads and clipboard will cut-back on some of the Mixtikl functionality for now on Android/Symbian... until those items are exposed in future Airplay updates!
Porting Mixtikl to Qt
It didn't take me long to port Mixtikl to Qt: just a few days to get it all running. Of course, it helps that Mixtikl was designed to be portable. :)
The biggest gotcha was shown-up by a weird linker error relating to missing vtable for a class.
It turns out that this was for a few reasons!
1. If your class implements slots, the declaration *must* be put in a header file; put it in a .cpp file, and qmake won't won't find it and you get the vtable link error.
2. That header file MUST be in your .pro file's list of header files; forget this, qmake won't won't find it and you get the vtable link error.
3. Make sure your class has a special line added. You must have the Q_OBJECT line as the first line in your class prototype, as shown below - no punctuation at the end of the line!
4. The class must be derived from a class that ultimately derives from QObject
5. Your slot implementation method must have a "slots:" line before it. e.g.:
6. You must then run qmake from the console/terminal, while in the folder that contains your .pro file (that will rebuild the makefiles to pull-in the neceesary bits).
One more thing to mention: I found using QTimer to be problematic if using threads; use QThread instead to roll your own timers if you have problems. I had similar issues with NSTimer on iPhone...
Once you've figured that out, Qt is a piece of cake to use. A very easy to use, powerful, flexible C++ framework.
The biggest gotcha was shown-up by a weird linker error relating to missing vtable for a class.
It turns out that this was for a few reasons!
1. If your class implements slots, the declaration *must* be put in a header file; put it in a .cpp file, and qmake won't won't find it and you get the vtable link error.
2. That header file MUST be in your .pro file's list of header files; forget this, qmake won't won't find it and you get the vtable link error.
3. Make sure your class has a special line added. You must have the Q_OBJECT line as the first line in your class prototype, as shown below - no punctuation at the end of the line!
class myclass : public QObject
{
Q_OBJECT
// ... rest of class follows
};4. The class must be derived from a class that ultimately derives from QObject
5. Your slot implementation method must have a "slots:" line before it. e.g.:
public slots:
void setValue(int value);
6. You must then run qmake from the console/terminal, while in the folder that contains your .pro file (that will rebuild the makefiles to pull-in the neceesary bits).
One more thing to mention: I found using QTimer to be problematic if using threads; use QThread instead to roll your own timers if you have problems. I had similar issues with NSTimer on iPhone...
Once you've figured that out, Qt is a piece of cake to use. A very easy to use, powerful, flexible C++ framework.
Wednesday 21 April 2010
Airplay SDK - building C++ apps as Android .apk files - first impressions
I noticed the other day that the Airplay SDK now uses modern C++ with STL - nice, and essential for my code. I already knew that the Airplay SDK supported Android, and having taking a look at my Android porting options I really didn't want to directly port my own C++ app code to Android using STL and JNI - there would be too much pain involved. :-0
So, having just installed the latest Android SDK on Windows 7 and Mac, I figured it was time - finally - to download and install the Airplay SDK evaluation.
In installed the Windows version on my Mac under Boot camp. This requires Visual Studio 2008 (the Express edition should work, if you're interested...).
Installation on Windows was easy, the eval license registered properly and I was soon following the instructions to build my first basic demo project. [I actually started with the Mac version - still in Beta - but it failed to register my eval license! Serves me right for starting with Beta software :)]
I double-clicked the example project file for a 3d demo game, which automatically constructed and opened a suitably configured Visual Studio project. Building this for the x86 target was as easy as building any other Visual Studio project - very simple.
Running-up the project under Visual Studio debugger for Windows, ran the app through a device emulator, which worked smoothly.
I next trivially rebuilt the app for ARM Debug target, ran under Visual Studio under ARM emulator on Windows - again this was easy and worked fine - it runs the app through an arm device Emulator, with a graphical version of GDB as the debugger.
Having rebuilt the app for ARM Release target, I next used a simple utility that comes with the Airplay SDK, to bundle-up the app an a .apk file (the installer format for Android). This was really easy. Note, however, that I first had to rename the Android SDK 1.6 folder on my PC (see the Airplay SDK forum for details on how/why!), and had to install a couple of other tools that are clearly documented in the Airplay documentation). Anyways: once your system is configured, building the .apk file is very easy. :)
I next installed the .apk to the Android SDK's emulator using the "adb install" command, and ran-up the application directly from Android SDK emulator. This worked OK, albeit with a slow frame rate I've been told that on devices the frame rate is very, very much faster than the emulator).
So, a really good experience so far. I'm looking forward to finding out more in due course. I was impressed enough to get a 99 dollar "indie" license; the "iPhone" license is actually free, which is very cool.
I'll need to find out how well it all works on a real Android device, and try some complex 2D graphics and heavy-duty audio, but the Airplay SDK so far looks very promising. It is powerful enough that it even looks like it'd be relatively straightforward to port frameworks like Qt to the Airplay SDK.
I found the online documentation to be a pain to navigate, but the documentation in Windows CHM file format (in the SDK) is pretty good.
The bottom line for me is how easy it was to get from generic C++ code, to a .apk file for Android - very impressive indeed. Not only that, the SDK supports buildling Symbian .sis files, Window Mobile .cab files ... and various other platforms. Plenty here to keep me busy and productive!
Edit: I've just discovered that Airplay doesn't support threads at the moment... which is problematic, to say the least!
Edit: I've heard via the Airplay forums that Thread support is coming in a few months ... which is very good news. :) Meanwhile, the port of Mixtikl to Android/Symbian via Airplay (and also a port of Mixtikl via Qt...) is coming along well, so maybe we'll have something to report in a few weeks...
So, having just installed the latest Android SDK on Windows 7 and Mac, I figured it was time - finally - to download and install the Airplay SDK evaluation.
In installed the Windows version on my Mac under Boot camp. This requires Visual Studio 2008 (the Express edition should work, if you're interested...).
Installation on Windows was easy, the eval license registered properly and I was soon following the instructions to build my first basic demo project. [I actually started with the Mac version - still in Beta - but it failed to register my eval license! Serves me right for starting with Beta software :)]
I double-clicked the example project file for a 3d demo game, which automatically constructed and opened a suitably configured Visual Studio project. Building this for the x86 target was as easy as building any other Visual Studio project - very simple.
Running-up the project under Visual Studio debugger for Windows, ran the app through a device emulator, which worked smoothly.
I next trivially rebuilt the app for ARM Debug target, ran under Visual Studio under ARM emulator on Windows - again this was easy and worked fine - it runs the app through an arm device Emulator, with a graphical version of GDB as the debugger.
Having rebuilt the app for ARM Release target, I next used a simple utility that comes with the Airplay SDK, to bundle-up the app an a .apk file (the installer format for Android). This was really easy. Note, however, that I first had to rename the Android SDK 1.6 folder on my PC (see the Airplay SDK forum for details on how/why!), and had to install a couple of other tools that are clearly documented in the Airplay documentation). Anyways: once your system is configured, building the .apk file is very easy. :)
I next installed the .apk to the Android SDK's emulator using the "adb install" command, and ran-up the application directly from Android SDK emulator. This worked OK, albeit with a slow frame rate I've been told that on devices the frame rate is very, very much faster than the emulator).
So, a really good experience so far. I'm looking forward to finding out more in due course. I was impressed enough to get a 99 dollar "indie" license; the "iPhone" license is actually free, which is very cool.
I'll need to find out how well it all works on a real Android device, and try some complex 2D graphics and heavy-duty audio, but the Airplay SDK so far looks very promising. It is powerful enough that it even looks like it'd be relatively straightforward to port frameworks like Qt to the Airplay SDK.
I found the online documentation to be a pain to navigate, but the documentation in Windows CHM file format (in the SDK) is pretty good.
The bottom line for me is how easy it was to get from generic C++ code, to a .apk file for Android - very impressive indeed. Not only that, the SDK supports buildling Symbian .sis files, Window Mobile .cab files ... and various other platforms. Plenty here to keep me busy and productive!
Edit: I've just discovered that Airplay doesn't support threads at the moment... which is problematic, to say the least!
Edit: I've heard via the Airplay forums that Thread support is coming in a few months ... which is very good news. :) Meanwhile, the port of Mixtikl to Android/Symbian via Airplay (and also a port of Mixtikl via Qt...) is coming along well, so maybe we'll have something to report in a few weeks...
Monday 19 April 2010
Port Qt and/or SDL to Android
I've been looking around to see if there are any ports of Qt or SDL to Android. This is by way of comparison to the Airplay SDK.
There are a couple of open-source projects that have been working towards this... though neither look pratical to my eyes at the moment.
Qt port to Android:
http://code.google.com/p/android-lighthouse/wiki/QADK
SDL port to Android:
http://www.anddev.org/viewtopic.php?p=40838
It is a shame that none of the bigger software development companies haven't done this already - the port of Qt would be especially useful!
There are a couple of open-source projects that have been working towards this... though neither look pratical to my eyes at the moment.
Qt port to Android:
http://code.google.com/p/android-lighthouse/wiki/QADK
SDL port to Android:
http://www.anddev.org/viewtopic.php?p=40838
It is a shame that none of the bigger software development companies haven't done this already - the port of Qt would be especially useful!
Sunday 18 April 2010
Airplay, Android and in-app advertising
I've been thinking around the subject of Android, and am pretty certain that the only tenable model for app distribution on this platform is with in-app advertising.
Of course, porting of a C++ app to Android is a complete pig, and I guess the option is either maybe via a port of SDL, or via Airplay.
The issue with Airplay is how to display in-app advertising; there is no way that I can see to invoke native code from Airplay!
Thinking around the subject, I was wondering if it were possible to install a native Android service that listens to a particular socket.
My thought is that Airplay could communicate with that service via the socket, to send request to display an ad in a native pop-up Window (the service handles the display of the ad, outside of the context of Airplay).
Anybody care to comment on this idea...? :-D
Pete
Of course, porting of a C++ app to Android is a complete pig, and I guess the option is either maybe via a port of SDL, or via Airplay.
The issue with Airplay is how to display in-app advertising; there is no way that I can see to invoke native code from Airplay!
Thinking around the subject, I was wondering if it were possible to install a native Android service that listens to a particular socket.
My thought is that Airplay could communicate with that service via the socket, to send request to display an ad in a native pop-up Window (the service handles the display of the ad, outside of the context of Airplay).
Anybody care to comment on this idea...? :-D
Pete
Subscribe to:
Posts (Atom)
