Saturday, 19 October 2013

Depth testing in Android / Qt 5.1 / C++ / OGLES 2.0

I'm experiencing a bit of a difference btween the way that my Qt5.1 / C++ / OGLES2.0 app works on Android compared to say BB10, Harmattan or even the desktop.

Picture 1 shows what the model looks like when viewed on Harmattan. Note OGLES2 depth testing is working. Picture 2 shows the same model viewed using my app compiled under Android. Note that depth testing is not working (ignore colour changes it's just depth testing that I've got an issue with).
To initialise the depth testing on Harmattan / BB10 / desktop I'm using:
  1.       glEnable(GL_DEPTH_TEST);
Do I need to initialise it using extra commands? I’ve also tried:

  1.       glEnable(GL_DEPTH_TEST);
  2.       glDepthFunc(GL_LEQUAL);
  3.       glDepthMask(true);
But it still doesn’t work. Any advice appreciated. I've posted this question on the Qt project forums.

Figure 1 - Model viewed using app compiled for Harmattan / BB10 / Win 7 dekstop

 Figure 2 - Model viewed using app compiled for Android 4.3

Sunday, 13 October 2013

Files paths using Qt/C++ and Android

Today I've been mostly looking at the storage of my app data files within Android.

The two alternatives distribution systems for data files seem to be:

(i) using the Qt resource system (.qrc files)

(ii) adding the files to an android/asset directory and referencing these files from the code directly (see PDF in previous post for more details on how to set your .pro file to do this).

Method (i) seems to be best for files that will not change much between distributions and which the user is not much interested in (e.g. icons, shader files etc).

However, for example files (which the user may wish to edit), I think a better alternative is to keep them explicitly in the main file system so that the user can take a copy.

The difficulty with this method is that Android doesn't seem keen on you doing this.

I put my example files in the android/assets directory prior to packaging using Qt. Once installed the Qt functions can then acess them using the assets:/examples/ file path. However, standard C++ file types don't seem to work with this - perhaps because Qt has a link to the Android API that resolves the assets link back to an absolute link on the system.

The QDir::homePath() function seems to be able to help (see discussion here) - although I haven't been able to get it to work. I'll post back if I do.

Saturday, 12 October 2013

Qt on Android

Now that I'm used to Qt Creator and publishing apps to Harmattan and BB10 I'm pleasently surprised by how easy it is to get something up and running with Android. 

Not that the app works 100% yet, but to get something runnning on the previous mobile platforms required a lot of dreary legwork.

Some of the online articles I've found useful in converting an Qt/C++/OpenGL app across to Android are:

The Qt Android Platform and Compiler Notes

Kiril Kulakov's presentation on some of the changes you need to make

and finally the Qt blog:

I've used many other resources too and will post them here when I come across them again.

Saturday, 9 February 2013

This time you can trust us

Corporate Lucy and naive developer Charlie. Every time she gives you a ball to kick at, or a 'leap of faith', she moves the ball away. Charlie runs for it an kicks only to end up flat on his backside with the ball just as far away as ever. Lucy wonders why noone else wants to play.

In this story Charlie has been worn out staying up all night working out how to use the 'supported' framework, signing process and app approval system. He despairs as he has to find information by trawling support forums, interpreting rumours and fishing for corporate leaks on mobile websites. He dreams of the day when his app is being used, getting feedback and he can enjoy improving it. The cause of his problems, Lucy, is the very thing that should be helping him.

Why is it that great technologies are exploited by these corporate Lucys, yet at the same time neglected? Is it that they don't understand the motivation behind developing apps? Charlies can see potential and are excited by it. The possibility of achieving something is there - but Lucy's not bothered that it's tantilisingly out of reach for Charlie. In fact, she finds fun in making it unavailable. Is there an inate need for corporate Lucy to feel superior and powerful? She demonstrates it at conferences, in Youtube videos and on technology websites. But will Lucy ever make these technologies truly available?

Take these problems Charlie (and others) might face with a Lucy's hypothetical company:

(i) two similar devices, from the same company, with similar operating systems, use different IDEs, different versions of the same framework and subtley different signing processes. One device, which has been available for longer, has worse support for the heralded framework than the first. But Lucy says come and develop for one and you'll effectively be developing for both. "Same framework. Same OS. Same signing process. Don't believe me? We'll eventually provide an update for the first device. It'll be great. Thanks for your loyalty." What she doesn't say is that there are still, now, many seemingly 'secret', badly documented, methods necessary to get the earlier IDE installed, the app compiled in release mode and signed for the app store (not to mention bugs in the newer OS). Implicitly Charlie has to run all over the place just because Lucy won't tell him where the ball is or indeeed where it will be and when.

(ii) so you got your app to compile? Great! Oh, but Charlie found a bug with the OS. No problem - just stick it in our bug tracker. What's that? Other people have the bug with the 'supported' framework too? And when will we look at it? Well we're very busy right now. Why? Well we're launching a new operating system. Oh, but wait, you're not sure if you'll get bad feedback because of the bug? Oh well. We'll fix it Charlie, don't worry...

(iii) so you've got a signed, compiled app? Great! (How did he do that?!) Just submit it on the app store and we'll take a look at it. When will you find out if it's been approved? Oh, well we'll let you know. [Hours go by. Days go by.] What's that Charlie you want to update a bug? Okay, yes just wait for this version to be approved. [Weeks... A month...] We're very busy right now. Lots and lots of apps. [Moment of luck] Hey, hang on - how did you get that approved??! Okay but didn't you want to get a new improved release on there? Okay ...

Never mind Charlie, at least this Lucy is seemlingly playing some kind of ball. Even if the rules aren't clear, it feels extremely slow and you don't trust them 100%.

It shouldn't be like this though. It should be EASY to play ball and developers shouldn't be made to feel suckers because they got undermined at the last moment. What Lucy doesn't realise is that people get fed up and go elsewhere.

The last Lucy really made people feel like they fell on their backside. That was a real way to wreck  brand loyalty. Mind you she's suffering now (these days people don't like play ball as much with 'Redmond' Lucy).

But hang on there's a Lucy from Finland and a Lucy from Africa that want to play. Rumour has it they'll be along in a year. And their devices might be available in Europe. What do you think Charlie? Charlie? ...

Saturday, 12 January 2013

Hopes for Qt/C++C on BB10

I had only moderate hopes this morning when downloading the latest Dev Alpha updates (Native SDK and Dev Alpha A with OS My app suffers a bit on BB10 as the Qt4.8 integration doesn't seem to be fully integrated yet.

The NAVIGATOR_EXIT, grabGesture() and landscape orientation bugs I've suspected for a while weren't fixed. This is frustrating as I end up spending hours trying all sorts of permutations of code and Natice SDK options to get the thing to work. I could do with spending the time elsewehere on the app to be honest.

The night before I discovered a summary of what BB understand the latest Qt/C++ support to be. This is a positive move because it recognises that there are issues for people that use this approach and implies that more will be done to address this issue. The post is here: 

I'm still disappointed that my issues don't seen to have been fixed. Not sure how this affects my app submission either. However, it seems that the overall message is still positive, so still looking forward to  BB10 release. And Jolla... And UbuntuPhone...

Sunday, 9 December 2012

I prefer QtCreator and Playbook

It's been a frustrating weekend. Even though there are many other Qt based Blackberry projects out there it still feels like mine is the first and I'm breaking new ground. Issues to date:

(i) what do I licence my project under? Luckilly apart from some LGPL libraries and other more permissive code the rest is mine so I can pretty much use whatever I like. Oh, except for GPL. And a whole load of other licences. (see here)

(ii) Qt Gestures don't seem to be being picked up correctly from one instance of my program to another. I can fire the app off once and it's fine - the QGLWidget works a treat. Next instance - doesn't work - gestures aren't handled. I don't want to release my app in this state. The problem is less obvious on my Harmattan build, but I think I've had it once or twice before. On Playbok it's pretty much 50:50. Qt help seems a bit vague about what's going on here. I sporadically look at the help for things such as this, but always give up once I realise it's not ready yet.

EDIT: it appears this is a problem others have had here

(iii) whatever debugger is in the QtCreator Playbook edition doesn't want to run on my Windows 7 desktop. Debugging and QtCreator (i.e. GDB) always seems a bit flakey to me.

That's the state of play at the end of today. But I don't want to end on a downer, so my positive from this weekend of hacking away at my app is:

QtCreator edition for Playbook is fantastic and I really prefer it to Momentics. I hope people at RIM are listening :O)

Sunday, 11 November 2012

Building for the Playbook - Tweak 1

Starting to try and compile for my new Playbook and just encountered this error:

Deployment Failed: Info: Sending request: Install and Launch
failure 533 Application-Requires-System: version [DevAlpha version number][Playbook version number]

Well, anyway, the solution was to open the bar-descriptor.xml file using the graphical interface (click the 'General' tab at the bottom of the screen) and select the 'Blackberry Tablet OS 2.1.0.xxxx' option under 'Required Platform'.

I'm looking forward to having one IDE for Playbook, Dev Alpha etc and being able to get rtid of multiple installations of the NDK scattered across my hard drive!!