Qt handles it’s own threading and signals so both OpenMPT and Raylib run on their own thread.

All I need to do next is to extract the current row from the pattern which it is playing and handling each note for each channel differently for displaying. As used in a lot of old-skool demos.

Playing back mod files on PC’s nowadays is nothing, the old days of the Amiga 1200 I had, it would not leave much CPU left.

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.

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…

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.

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…

ShaderFrog

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.

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.