While evolving miniMIXA into Mixtikl at my company Intermorphic, I've encountered quite a few issues porting Mixtikl to the various mobile platforms, and I thought it'd be useful to be able to share some of this with those of you interested in writing trans-platform applications. I hope you find this of use! If you have any comments, please let me know!
A bit of background
Before I start, the first thing to note is that for implementing any trans-platform application of this complexity (750K++ lines of code!), you'll need to start with a common UTF8 library. I wrote that when I first started Liptikl, so didn't have to worry about that this time round!
I started by implementing Mixtikl to sit on top of the trans-platform graphics layer that I'd already written. The first implementations of this layer were for Juce, Direct X, Windows Mobile GDI, and SDL. Symbian will come soon; iPhone is ongoing, and hopefully Android at some point. The Juce version of the graphics layer for Mixtikl were really easy - Juce is a really great platform for desktop apps. Hence, Mixtikl for Windows and Mac desktops were relatively straight-forward (considering the complexity of Mixtikl!) And, of course, it made the plug-in variants of Mixtikl relatively easy to sort-out.
What do I like about writing for Windows Mobile?
- Great tools: Visual Studio is simply superb.
- Fabulous documentation - mostly. I love MSDN, but the API documentation is light on in-situ example code, and I have had to spend a lot of time surfing for solutions to problems. I still rely on my old Windows API Bible (by Jamle L Conger) - certainly the best API guide I have ever seen, packed with examples of every API call; no longer in print, but amazingly still relevant to graphics coding for Windows Mobile!
- Windows Mobile supports full-duplex audio, which is more than can be said for Symbian...!
- Windows Mobile devices are very consistent
- Windows Mobile devices have good user input: joy pads for control, and keypad/touchable screens where appropriate.
- Windows Mobile allows users to copy data freely to-and-from their desktop computer (via Internet Explorer), which is more than can be said for iPhone...!
- End-of line Windows Mobile 2005 devices are really, really good value.
What don't I like about writing for Windows Mobile?
- Graphics APIs: it took a while to get our Windows Mobile graphics layer sorted-out.
I wasn't able to use Direct X out-of-hand for a couple of reasons. The biggest consideration is that we think that it is useful from a usability perspective for an application like Mixtikl to be able to use the mobile device's soft menus, and to display the status bar. However, Direct X apps on Windows Mobile only run full screen, which made it a non-starter. On another point, there is no PNG import support, the blit routines are not flexible, and I'd have had to do a lot of blitting through my own generic blit functions anyways.
So, we used the standard win32 GDI API for Windows Mobile. The biggest problems I faced here were twofold: I had to implement my own png importer (it is a huge oversight for this not to be built-in to Windows Mobile 2005!), and I didn't realise that when constructing an in-memory bitmap on Windows, I had to WORD-align all lines in the bitmap. That latter problem actually had me stumped for a few days! Also, you need to know to create your bitmaps where possible as 565 BGR bitmaps, as this is the most memory format for Windows Mobile; transparent bitmaps must be stored as 32-bit ABGR bitmaps.
- Problems with the Visual Studio 2005 C++ compiler
Even though the port to Windows Mobile wasn't so hard, I faced some serious problems with Visual Studio 2005. The first problem is that the emulator is so *slow*; I ended-up having to get a top-of-the range Mac Book Pro to get the emulator running fast enough for real-time debugging of my audio engine under the emulator. And far more seriously, there is at least one horrible bug in the compiler ... you can read more about the bug here:
http://vividos.wordpress.com/2007/12/06/the-infamous-arm-by-value-compiler-bug/
http://vividos.wordpress.com/2007/12/09/in-depth-analysis-of-the-arm-by-value-compiler-bug/
The bug is fixed in Visual Studio 2008...
- Visual Studio 2008 Pro is required for Windows Mobile 6 development
Due to the compiler problem in Visual Studio 2005, we upgraded to Visual Studio 2008 Pro; it fixed our compiler problems, and you need at least the Pro version of Visual Studio 2008 to develop for Windows Mobile 6. It is a shame that Microsoft didn't include the Windows Mobile support in the Standard Edition; only the Pro edition (or even more expensive versions) contain Windows Mobile support; I'm sure this puts-off a great number of hobby developers from developing for the platform.
I've taken a close look some of the ARM code generated by the Visual C++ 9 compiler, and it looks really good; the code it makes for maths routines is as good as (or better!) than I can write by hand, so I'm happy to say that I'm keeping clear of assembler on this platform!
- The lack of build-in profiler; you don't get a profiler without paying for an even more expensive version of Visual Studio. This seems a shame for hobby developers.
What do I like about writing for Symbian?
- Symbian allows users to copy data to-and-from their desktop computer (via Internet Explorer), which is more than can be said for iPhone...!
- Symbian devices have good user input: joy pads for control, and keypad/touchable screens where appropriate.
- Based on the Gnu tool chain, so the compiler is good!
What don't I like about writing for Symbian?
- the lack of full-duplex audio support. This is a crazy omission in the Symbian APIs. If anybody out there is listening, you should commission Intermorphic to provide you with a decent audio library. :)
- the need for multiple SDKs. Series 60, UIQ, and variant sub-variants of each... that is a lot of stuff to keep track of.
- if you put your software code a little too deep in your file/folder structure, the Symbian build system falls over!
- documentation nowhere near as good as what is available on MSDN or Apple's site.
- the user interfaces. Why is so much screen real-estate wasted on the title-bar and soft menus, for example?
- the really weird idiosyncracies in their use of C++...
- Symbian doesn't allow full browsing of the local file system from the device; if you want to see what is on a storage card, you have to pop-out the card and look at it with Windows Explorer using a card-reader!
What do I like about writing for iPhone?
- XCode is free for all Mac users!
- It uses a good development environment. XCode is quite nice, though the debugger drives me potty compared to Visual Studio when browsing variables in the application code.
- XCode has a really, really good build-in code profiler. Well done Apple!
- No need to write graphics importers; image loading is pretty easy.
- Based on the Gnu tool chain, so the compiler is good!
What don't I like about writing for iPhone?
- The real killer, show-stopper, "I don't believe it" problem is that the user can't copy data to-and-from the desktop and any data area that can be seen by an iPhone application. This is a *massive* problem with writing software for iPhone. Why even bother attempting to write creativity software for iPhone, if you can't transfer data between your desktop computer and your mobile? Why didn't Apple provide for a common area to which all apps can read/write, and where Windows Explorer and Finder can also read/write. That seems a complete no-brainer to me.
- You're not allowed to use interpreted languages or scripting engines in your applications (other than those in Apple's own APIs - which aren't adequate). Which is not good news for games that rely on scripting engines to get their behaviours, or the user Lua scripts in Noatikl pieces, to give just two simple examples! I am really puzzled by why there would be such a restriction...
- No support for storage cards. No doubt to force all content to come via the Apple Store...
- No clipboard support. Presumably this is part of a cunning plan by Apple to prevent applications sharing data with each other. :-)
- Objective C. It is a great language that seems very well suited to development in a wide range of contexts. It is a whole lot cleaner than C++ (IMO!). It is great that you can mix objective C and C++ in your code (if you first remember to rename your files to have .mm extensions, rather than the default of .m!). However, it just wouldn't be cost-effective to write a new application purely in Objective C; so you have to write most of your code in C++, and implement a very thin adaptor code layer to the iPhone APIs. Fair enough!
- the touchable user interface can't be operated with a pointer stick; that makes high-precision user interfaces a no-no
And to close with a slightly off-target point: why doesn't my Mac Book Pro have a built-in 2-button mouse? Drives me potty.
What next?
The Antix Game Player looks interesting! Android is also on the near horizon; but, and here is a show-stopper: it looks like it only allows apps for it to be written in Java ... which seems crazy!
Hoping this is of interest!
Pete
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment