Mixtikl - added clipboard support

The new version of Mixtikl adds Intua Clipboard support for the iPhone/iPod/iPad version, amongst many other updates! This Mixtikl update is a big step forward for us, we're really looking forward to releasing it in a few weeks!

Android version of Mixtikl coming along

The tidy-up phase of the Android port of Mixtikl is coming on nicely. My shortlist of things to do is getting very short. :)

Customized Android NDK r3 with enabled support of C++ exceptions, RTTI and Standard C++ Library

This looks very useful... (thanks to Chris for the pointer!)

Customized Android NDK r3 with enabled support of C++ exceptions, RTTI and Standard C++ Library...


http://www.crystax.net/android/ndk-r3.php

Mixtikl on Android

The Mixtikl port to Android has been making further good progress; I think we're now only a couple of weeks from first release... it is working pretty well on my HTC Hero device, as I type this.

Hopefully we'll be able to follow-suit with Symbian once the Android version is out of the door...!

MeeGo - how to download the source code using Cygwin / Windows

You can get the very latest MeeGo source code from here:

http://repo.meego.com/MeeGo/devel/trunk/repo/source/

I downloaded all the rpm files easily enough using wget (under cygwin, on my Windows machine).

To extract the contents of the downloaded rpm files, do this for each rpm file (assuming you have the rpm tools installed with cygwin!):

rpm2cpio filexyz.rpm | cpio -idmv --no-absolute-filenames

Then...

For each extracted myfile.tar.gz file, do this:
tar -xvf myfile.tar.gz

And...

For each extracted myfile.tar.bz2 file, do this:
tar -jxvf myfile.tar.bz2

You will then have all the latest MeeGo source code extracted to your computer!

Mixtikl on Airplay - audio now working too!

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!!

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!

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!

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.

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...

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!

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

Performance-tuning example with gcc

From time to time, I need to rip-apart functions to do some old-school performance tuning. This is really easy to do.

Here is an example file, called perf.c ... in it, I have two versions of a function. One is inefficient, the other is more efficient by virtue of being written slightly differently.


typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;


// Inefficient inner loop

void byteswap (const uint8_t *PpFrom, uint8_t *PpDst, uint32_t PBytes)
{
    long i;
    long lWords = PBytes >> 1;

    for (i=0; i < lWords; i++)
    {
        unsigned lWord = ((const uint16_t*)PpFrom)[i];
        ((uint16_t*)PpDst)[i] = ((lWord & 0x0ff) << 8) | lWord >> 8;
    }
}

// Efficient inner loop

void byteswap_2 (const uint8_t *PpFrom, uint8_t *PpDst, uint32_t PBytes)
{
    uint32_t lWords = PBytes / 2;

    uint16_t* PpDstPtr = (uint16_t *)PpDst;
    uint16_t* PpDstEnd = PpDstPtr + lWords;

    const uint16_t* PpFromPtr = (const uint16_t *)PpFrom;
    for (;PpDstPtr < PpDstEnd;)
    {
        unsigned lWord = (*PpFromPtr++);
        (*PpDstPtr++) = ((lWord & 0x0ff) << 8) | lWord >> 8;
    }
}

From the command-line, run this command (assuming you have gcc!)

gcc -c -g -gstabs perf.c perf.s

This takes your source code (perf.c), and outputs the disassembled output to a file called perf.s ... which you can take a look at with your text editor.

In the file, the code generated for the first function looks like this:


.globl _byteswap
.def _byteswap; .scl 2; .type 32; .endef
_byteswap:
LFB3:
.file 1 "perf.c"
.loc 1 9 0
pushl %ebp
LCFI0:
movl %esp, %ebp
LCFI1:
subl $16, %esp
LCFI2:
.loc 1 11 0
movl 16(%ebp), %eax
shrl %eax
movl %eax, -8(%ebp)
.loc 1 13 0
movl $0, -12(%ebp)
jmp L2
L3:
LBB2:
.loc 1 15 0
movl 8(%ebp), %edx
movl -12(%ebp), %eax
addl %eax, %eax
leal (%edx,%eax), %eax
movzwl (%eax), %eax
movzwl %ax, %eax
movl %eax, -4(%ebp)
.loc 1 16 0
movl 12(%ebp), %edx
movl -12(%ebp), %eax
addl %eax, %eax
leal (%edx,%eax), %ecx
movl -4(%ebp), %eax
movl %eax, %edx
sall $8, %edx
movl -4(%ebp), %eax
shrl $8, %eax
orl %edx, %eax
movw %ax, (%ecx)
LBE2:
.loc 1 13 0
addl $1, -12(%ebp)
L2:
movl -12(%ebp), %eax
cmpl -8(%ebp), %eax
jl L3
.loc 1 18 0
leave
ret



The code generated for the second function looks like this:


.globl _byteswap_2
.def _byteswap_2; .scl 2; .type 32; .endef
_byteswap_2:
LFB4:
.loc 1 21 0
pushl %ebp
LCFI3:
movl %esp, %ebp
LCFI4:
subl $32, %esp
LCFI5:
.loc 1 22 0
movl 16(%ebp), %eax
shrl %eax
movl %eax, -20(%ebp)
.loc 1 24 0
movl 12(%ebp), %eax
movl %eax, -16(%ebp)
.loc 1 25 0
movl -20(%ebp), %eax
addl %eax, %eax
addl -16(%ebp), %eax
movl %eax, -12(%ebp)
.loc 1 27 0
movl 8(%ebp), %eax
movl %eax, -8(%ebp)
jmp L6
L7:
LBB3:
.loc 1 30 0
movl -8(%ebp), %eax
movzwl (%eax), %eax
movzwl %ax, %eax
movl %eax, -4(%ebp)
addl $2, -8(%ebp)
.loc 1 31 0
movl -4(%ebp), %eax
movl %eax, %edx
sall $8, %edx
movl -4(%ebp), %eax
shrl $8, %eax
orl %eax, %edx
movl -16(%ebp), %eax
movw %dx, (%eax)
addl $2, -16(%ebp)
L6:
LBE3:
.loc 1 28 0
movl -16(%ebp), %eax
cmpl -12(%ebp), %eax
jb L7
.loc 1 33 0
leave
ret


I've highlighted the assembly of the code generated for the two inner loops. Look how much more efficient the second version is, with only a simple bit of re-coding!

It should be easy using this approach to learn how to make your code more efficient, without much effort.

VisualBox, VMWare Player and Parallels

I've done quite a bit of work over the past year with PC-hosted Linux (Ubuntu) VMs under VMWare Player, mainly for Android work. I got so fed up recently with the poor system integration (poor Mouse and Keyboard transitioning when moving to/from host and the VM, no copy/paste between Windows and the VM, limited support for VM desktop resizing, not easy to share file data between host and VM), that I decided to spend some time looking at VirtualBox.

After a day evaluating, I've now moved entirely to VirtualBox! I was even able to (easily) set-up 64-bit VMs running on 32-bit Windows, which was very handy; and it was simple to set-up a shared file area between host and VM.

I haven't yet tried VirtualBox on Mac, but I'm perfectly happy with Parallels 5 at the moment so haven't felt the need to use anything else on Mac...

Windows 7 on my Mac

I finally took the plunge a few weeks back, and upgraded my Mac Book Pro hard drive (requiring a week with the Apple repair center to do the upgrade!), in preparation for replacing the Windows XP Boot Camp partition with a Windows 7 installation (with Windows XP moved from Boot Camp to a Parallels VM).

The transition was fiddly; I used Parallels Transporter to copy the Boot Camp XP to a virtual machine image on an external USB drive (which I then copied to the Mac Hard Drive). I had to use a USB drive, as I couldn't get Parallels Transporter to work over my LAN. Once I'd proved that the VM started OK (and was backed up to my RAID drive!), I then got rid of the boot camp partition, and tried to install Windows 7 in a larger Boot Camp partition. However... I found was that the Mac drive was too fragmented to resize the Boot Camp partition (!).

I did some reading around the subject, and was surprised to find that Macs don't have a defragmenter option...! My solution was not much fun, but was easier than it sounds: I cloned-off the hard drive using the incredible Super Duper! to another spare USB drive, double-checked that I could boot off that drive; then cloned-back the Super-Dupered drive back to replace the contents of my Mac Book drive. That fixed the fragmentation, so I could finally configure the Boot Camp partition as I wanted and proceed with installing Windows 7.

I chose a 64-bit install of Windows 7 so that I could use Mixtikl and Noatikl VST plug-ins in 64-bit mode under Windows.

Using 64-bit so far hasn't caused me too many problems; Beyond Compare (which is still isn't available in a 64-bit version) did't integrate at first with Windows Explorer. However, thanks to a comment from Aaron from Scooter Soft (see below), I found the configuration option that let me re-configuration as a shell extension, which now works perfectly!

There is also a 64-bit version of Tortise SVN which integrates with Windows Explorer OK. There is also a new version of Cygwin that works fine with Windows 7, and I found a 64-bit copy of GVim that integrates with Windows Explorer.

All in all, Windows 7 is quite a bit faster than XP (though still not as fast as Mac OS!), and is in general easier to use now that I've customised Windows Explorer to work more like that in Windows XP. After a week of use, XP already seems dated and I have no intention of going back to it other than for occasional software testing! I also love the way that out-of-the-box, Windows 7 gave me a read-only view of the HFS partition on my Mac.

So, what about a Windows 7 virtual desktop manager (Mac has the wonderful spaces built-in)? Well, simply install VirtuaWin - it works beautifully, and is open source!

Finally, you'll need Cygwin to get a greate scripting environment, which lets you share scripts between Windows and Mac.

That said, there are far more tools for Windows than for Mac... so I am happy to use both Windows and Mac, mixing-and-matching where required. Where would I be without Beyond Compare and Tortoise SVN on the Windows side, for example? :) The combined Mac OS X/Windows/Parallels/Bootcamp system really is a good one for code development...

64-bit Noatikl and Mixtikl...

I'm currently working on creating 64-bit versions of Noatikl and Mixtikl...

This is made easier for us on the Mac, which supports the use of Universal Binaries; there is quite a lot more fiddling around to do on Windows, where I have to build both separate binaries and a dual-configuration install that includes both 32-bit and 64-bit components.

Incidentally, using Inno Setup makes building a mixed-mode install very easy; what a great tool.

Of course, having both 32-bit and 64-bit binaries makes testing even more time-consuming than usual...!

cygwin - alternative shells

While I love cygwin, I've never been totally happy with the standard Cygwin Shell Console, mainly in the way that it handles copy/paste, fonts and colour setting. But mainly copy/paste. :)

Well, I've finally got around to reseaching some replacements, and like what I've found!

Basically, I found a couple of good alternatives: mintty and rxvt. Neither of these require use of X, and both are available as optional packages that you can select from the standard cygwin installation.

Note: neither of these work right with non-cygwin utilities that require piping. You need to keep the normal Cygwin Shell Console for that.

mintty (http://code.google.com/p/mintty/)

When you install this as a cygwin component, you'll find a shortcut created for you automatically under the Start menu.

Next, I modified the shortcut to look like this:

C:\cygwin\bin\mintty.exe bash -li

However, when I started cygwin using this shortcut, my normal .profile scripts weren't picked-up properly. To fix this, I had to modify /etc/profile and add a line like this...

export HOME=/cygdrive/c/home

mintty then launches.

What I love about this is that it gives a fully UTF-8 enabled shell, where it is really easy to cut/copy/paste text, and very easy to change colour schemes.

Just right-click on a mintty window to see the copy/paste etc. options; dead easy.

If you want to spawn-off a new console, use an alias like this:

alias mintty='mintty --size=100,70 bash --login -i &'

mintty

rxvt

This is also available under cygwin, but isn't fully Unicode aware, so isn't as good as mintty. You'll see problems for example when you try viewing a manual page; look at the funny text you get when you try this...:

man bash

That said, here is what I did to get it working.

Basically, I took a copy of the cygwin.bat file, and modified part of it like this:

rem bash --login -i
rxvt -sr -sl 2500 -sb -geometry 100x70 -fg black -bg white -tn rxvt -fn "Lucida Console-12" -e /usr/bin/bash --login -i

I also created an alias in my .profile file, that allows me to launch new rxvt windows easily.

alias rxvt='rxvt -sr -sl 2500 -sb -geometry 100x70 -fg black -bg white -tn rxvt -fn "Lucida Console-12" -e /usr/bin/bash --login -i&'

With rxvt, you get a paste operation in one of two ways:
- Ctrl-Shift-LeftButton
- middle (press mouse wheel) - no good for MacBook devices with Track pad!

Debugging Android native code - another useful link

Another Android native code debugging link that you might find of use...:

http://pdk.android.com/online-pdk/guide/debugging_native.html

vim - how to force .cpp files to have Objective-C syntax highlighting

This one has bugged me for a while - how to make vim and MacVim display .cpp files with full Objective-C++ syntax highlighting.

This is actually really easy to do; I can't believe it took me so long to figure out! Especially as I try to avoid using .m or .mm files in my projects, and almost exclusively use .cpp source files in all that I do to make my cross-platform work easier...

Anyways: all you have to do, is put these three lines in ~/.vim/filetype.vim (you'll almost certainly first have to create the .vim folder under your home directory...)


au BufNewFile,BufRead *.cpp set filetype=objcpp
au BufNewFile,BufRead *.h set filetype=objcpp
au BufNewFile,BufRead *.c set filetype=objcpp


Sorted! Whenever you use the built-in vim, or MacVim, to edit a .cpp/.c/.h file, you'll see any Objective-C code in your editor displayed with nice syntax highlighting; your C++ code will also look lovely too!

Mixtikl update for iPhone coming soon - and Liptikl!

Tim and I both had a good break over Christmas; I think we both earned it after the long, hard push to releasing Mixtikl 2!

Now that we're refreshed, we've been busy working on an update to Mixtikl, which tidies-up various loose ends and generally makes it easier to get into! We're aiming to release this in a few weeks.

We've also been working on an iPhone version of Liptikl, which is fun and easy to use, so we hope to release that at some point after first releasing the Mixtikl update.

For those who are interested in the technicalities of such things things, most of the primary development for Mixtikl is done under Xcode on the Mac, targeting the iPhone version. Because Mixtikl is 95% cross-platform, I actually have the option to work under either Windows (with Visual Studio) or Mac OS (with Xcode). Despite Visual Studio being hugely more powerful than Xcode (with a far nicer editor model, debugger etc. etc....), I find myself working mainly in Xcode. Why? Simply because Mac OS is a great deal faster than Windows for running all my development scripts. Xcode is a lot less nice to use than Visual Studio, but overall I'm faster on the Mac because Mac OS mainly because shell scripting runs so much quicker...! Because I use the same editor on both platforms (vim ...) I can move easily between the two whenever I need to. I must say however, that if cygwin scripting were a lot faster under Windows, then I'd be back to Windows. :)

Android - NPAPI plugin - how to make a callback from the main thread

If you happen to be writing a browser plug-in using NPAPI/JNI for Android's built-in browser, and are doing some processing in the native side in C/C++ in a separate Posix thread; and want to get a callback into your native code from the main browser thread; you want to use this NPAPI function...!

void NPN_PluginThreadAsyncCall(NPP instance,
void (*func)(void *),
void *userData);

You can find some documentation on this if you search your Android source code for the file called npapi.cpp.

Basically, you call the above function from your native thread to register a callback function; the call to NPN_PluginThreadAsyncCall returns immediately. At some future point in the very near future, the browser will call your supplied function from the main browser thread, supplying the userData that you provided when you registered your callback.

Incidentally, if your Plug-in method is passed a JavaScript object that you're going to need to do something with at a later point (e.g. if you want to issue a deferred callback, through use of NPN_PluginThreadAsyncCall), you need to remember to keep your JavaScript object alive until you're ready to use it, by calling:

NPObject *NPN_RetainObject(NPObject *npobj);

Once you've used the object, remember to release it with:

void NPN_ReleaseObject(NPObject *npobj);

Hopefully that'll be of use to some people!