After a short time to install 5.9.2 of Qt and then without my fingers crossed even, I loaded up Qt and loaded one of the 3D Android compatible examples.
After the first build complaining about API level 1 I fixed that and ran it again. And voila! My phone ran it. All being very slow because it was that water demo one.
Woo hoo! Might be back to Qt for desktop and mobile app dev again.
A few days ago, playing around with LibGDX again I was getting back into 3D programming and created a very simple demo of a load of spheres and the camera rotating around the scene as below:
Which on my laptop ran just fine. It took about a second to generate all the meshes for each of the spheres.
Took bloody ages on my phone though, even though it’s a quad core 64 bit android phone. Approximately 5 to 8 seconds. Ouch.
None of this nonsense in C++ for starters. I know this from a very old project I was working back in the day. Procedural map generator. More about that here: PROCMAP DBP LINK
So for the last couple of days (actually on the evenings because of work), I’ve looked into creating a single sphere mesh and then duplicating it. In LibGdx
A minor problem to start off with is that a lot of LibGdx’s mesh generators have been deprecated and I don’t know how long for now, and I can’t find examples on how to use the new stuff. This would have made things easier, but that minor problem got bigger.
It seems that ModelBuilder only runs on the GL thread, so I tried the MeshBuilder. No luck there after trying to hunt info down on google, (Maybe google is hiding it from me :P) how to use the thing.
So I gave up, closed the project, might go back to it if the next step fails.
I’m waiting on a huge update from Qt. Oh! At this time it has finished downloading and updated.
The previous versions of Qt didn’t work with the latest Android SDK/NDK. Fingers crossed with this one…
Next…
Before I go ahead and actually buy the Odroid C2, I thought I’d dig out my U3 and try the vlc library on that. All I had to do was to copy the project folder over SSH to it and build it. At first it didn’t compile because I needed to install the X11 dev files, and then again I had to install the libvlc-dev files. And then it built just fine.
Major problem though, VLC doesn’t have hardware acceleration on any of the Arm processors yet.
Well, now it looks like I’ll either go down the Qt route, FFMpeg route, OGV decoder route, or find another player library.
One thing I do know is that I’d like to stick to a single video format, ie OGV. So that makes writing my own player easy enough.
My next step is to get a player working by myself and make it work on the Odroid. I’m going to see about the OGV sources before checking out other open source players.
I’ll keep you posted.
For the last two days I’ve been working on decoding video frames and displaying them. The idea is to run against the system clock which I’ve had working everytime so far. This time though, I decided to make a general decoder so that I didn’t have to worry about FFMpeg’s video decoded format which up until now has always been YUV420 which I just had a GL using SL shader convert on the fly. Everything gets converted to an RGBA bitmap so I don’t have to worry about it.
Anyway, variable names…
I buffer up the frames and then test them against the current system clock for a frame that’s ready to be presented. I had two variable names, frame and frame_temp which are pretty innocent. Unfortunately though, and which I kept missing whilst going through the code, I was grabbing a pointer in frame_temp and testing it. If it fell below the current system time then it would then be assigned to frame. If there was a previous frame then it would be cleared from the buffer queue and added to the unused buffer queue.
Now this is what I missed.
Frame_temp is first used, frame is unitialised (actually null), the tests are done on frame_temp and if failed then just exits with a null pointer. Fair enough.
It was a “typo”.
Hidden between four lines of code using frame_temp I had used the variable frame instead (which is null to start with). When I accessed a method on that class it would crash.
The error message was very obscure and nothing on google search or anywhere else was any help.
My mistake…
Most of the time I rely on debug log outputs. And whilst running this code, everything was running just as it should. It’s hard to follow multiple threads in debug output.
Finally, I ran it through gdb which took me straight to the line of code where it crashed. The line right after the “typo”.
Lesson learnt…
Just so I don’t lose or forget about it, I’ve found a very handy online openGL shader editor…
From basic shaders including texturing and lighting right up to procedural shaders and more.
All I need now is to run a sample project in Qt to test out some of these and then transfer them to GWT and Parallax. Good stuff can now be done.
Embedded Linux is the bees knees for doing a lot of things, especially when you really don’t want the Android overhead on top of it. For a device such as the Odroid range which can be used as a headless server providing and IPTV gateway and a web interface for controls, linux is the better option.
When it comes to graphical applications, for example decoding video streams and openGL rendering, it always becomes a toss up between Linux and Android. A lot of people who are familiar with Java will automatically pick Java and I have to say, I do actually like the Java Virtual Machine. The JVM is handy whilst developing because a crashed application just gets cleared out.
Qt can also be used for developing mobile applications and has a very extensive framework and because it’s C++, time critical code isn’t a problem.
The only issue I have with Qt is that when it comes the day when I do want to release and application for whatever it is I finally do, packaging it up for all OS’s becomes a pain.
Qt for Android is easy, just build the project and get the APK. Just one file and it can be copied to any Adroid device.
Qt for Windows is a nuisance because you have to faff about with the terminal (which is awful in Windows) to package all the required libraries, and then it’s not guaranteed to run straight out of the box. For Windows you have to use a dependency walker to find the missing libraries.
Qt for Linux isn’t too bad unless you want the latest libraries. At this moment you can install Qt5.5 from the Linux repositories and away you go. Unfortunately, the latest version of Qt is 5.7 with some very nice additions so it’s back to packaging stuff up.
For embedded Linux it would have to be Qt from the Linux repositories.
For Android it is still a toss up between Qt and Android Studio + NDK. Although if I could get away with it I would use Qt and Linux unless it was going to be an application for the Android market.