C++

Some C++ tests

Well, after a while of faffing about with other things, I thought I’d go through some of the new features of C++17 and just a quick play about I found some very interesting new features.

#include <cstdlib>
#include <iostream>
#include <string>
#include <vector>
#include <tuple>

using namespace std;

int main(int argc, char** argv) {
    vector<string> strings = {
        "Hello",
        "World",
        "This",
        "is",
        "the",
        "best",
        "I",
        "can",
        "do"
    };
    
    for (string str: strings) { // I now know
        cout << str << endl;
    }
    
    cout << strings.size() << endl;
    
    // https://www.geeksforgeeks.org/tuples-in-c/
    // makes it more interesting with tuple_cat
    
    auto mytuple1 = make_tuple("triangle1", 't', 10, 15, 20); // interesting...
    auto mytuple2 = make_tuple("triangle2", 'b', 1, 2, 3);
    cout << get<0>(mytuple1) << endl;
    mytuple1.swap(mytuple2);
    cout << get<0>(mytuple1) << endl;
    cout << tuple_size<decltype(mytuple1)>::value << endl;

    return 0;
}

First off the std<vector> initialisation can now be done as it is with Java, but more interestingly is the for loop which works with any class list. That makes life so much easier for C++ handling data.

The next bit was the tuples. For some reason I always associated tuples with a set of 3 items. But after this… This allows for a quick, and maybe dirty way, of avoiding setting up a new class to handle short bursts of data. Very simple.

Now I’m going to play around with some more C++17 features. I may end up moving completely back to C++ and away from Java again.

EDIT:

The output:

Hello
World
This
is
the
best
I
can
do
9
triangle1
triangle2
5

RUN FINISHED; exit value 0; real time: 0ms; user: 0ms; system: 0ms

Java ‘long’ to C++ ‘int64_t’

Hallelujah!

For the last two weeks I’ve had an intermittent problem with my C++ version of the crypto socket client, and tonight I finally cracked the issue.

The Java version is using ‘long’ for doing it’s calculations and the C++ version was using a 64 bit integer, which should have been fine until tonight I realised that Java was using its ‘long’ values as signed. Whereas I had been using ‘uint64_t’ in the C++ version.

This caused the C++ version to work once in every 5 to 10 tries. Just by removing the unsigned, it now works flawlessly.

Phew! Now I can blitz the rest…

(Yep, it has been a while since the last post)

TCP C++ server upgrades

A quick snippet from tonight’s diary entry:

20:30 – I’m still reading up on some stuff about non-blocking TCP server programming and so far the best examples come from http://developerweb.net/viewtopic.php?id=2933. Ideally what I want is NOT to have a shed load of threads running, which I’ll be using a thread manager for, but a way of quickly determining if a connection is valid before shutting it down.

By the looks of the examples,  a continuous loop could be checking upto 1024 connections at any time before sending them off to another thread. This method has caught my attention big time because I should be able to setup some kind of timeout very quickly to close the connection if it doesn’t respond to the initial connection request. And I can still serve 100 to 1000 devices without any problems at all.

The same single thread can be constantly checking for connections and readability. It’s the readability part that matters the most here because it will be timed very precisely. Once a connection passes the readability test by passing the initial CSPRNG test, then it can go to a thread handler. Otherwise it gets closed. All of this a single core/thread can easily handle.

I will be studying this a lot further as this looks to be the way forward for a tcp server.

And this is just from my crappy laptop at home.

Basically, the new software upgrades to the server will be 1000 times more efficient than the current Java version. Although once in the cloud, the Java version can easily serve over 500 devices because of the bandwidth increase.

The updated C++ version will increase that significantly as well as handle dodgy connections better. Once a connection has passed the CSPRNG test then the TIMEOUT increases a smidgen.

I’ve already got the CSPRNG functions running and tested and written in assembler code to reduce that bottleneck too.

Until next time… WLGfx…

Eclipse Oxygen and NASM

Tonight I set myself a mission of getting any IDE to build assembler files alongside my C/C++ code.

Find it here: Eclipse Oxygen and NASM

I tried NetBeans at first but the IDE isn’t good at all, actually quite useless for setting up NASM. I spent about half an hour trying this out and eventually gave up. Apparently there are plugins out there, but I wasn’t going to try them out as they were not part of the NetBeans official plugins.

So I look into Eclipse and initially I was put off because there was nothing in the official plugins. A few searches later and I got it. It was already built in to the CDT plugin for eclipse. I only had to make a minor alteration to get it working.

Now I can have a C/C++ project that will also automatically compile and link my assembler source files.

Here’s me thinking I was going to be stuck over the weekend finding this out. Took an hour. What’s next to move on to? Oh yeah, my project. he he…

Java vs C++ for 3D mesh building

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…

Only a minor update

After work today I was zapped, but I got the file structure tested and confirmed on the server side for the initial testing. Everything is using Linux so it is easy to set up the testing grounds. I’m trying to make the device installation as quick as possible with minimal fussing about.

Oh and I also fixed a bug with the ‘~’ (home) location in java. Using ‘user.home’ gives me the home directory (actually on Windows too I found out but not tested, no need).

Eventually all of this will be in C++ so I’m 0% stressing at the moment. The servers will need to be C++ because of the JVM overhead.

I also fixed my PC in Linux which was not connecting to many websites. I had set up the fixed IP for testing without setting the routers gateway correctly. Chrome seems to mask this by loading up some websites but the rest it couldn’t find. The fix was done by assigning the fixed IP on the routers side. Eventually a VPS will cause me a few headaches.

I think tomorrow I will get back down to using Blender because that is the main source for this project. Royalty free 3D models/animations I want to test out.

Not been that busy lately this time

I had 2.5 days carried over for holidays so I took a long weekend off beginning half day on Friday. All to go for long rides with the missus on our motorbikes. And she was very happy because she has only been riding for almost a month now.

Anyway, documents have been written up towards this project and a very important document that I created regarding it from about six years ago needs altering. No database plan has been setup yet until the spreadsheets are finalised. Number crunching has been pretty good.

At the moment I have four sample videos created, although I need a lot more, to which a demonstration setup can be made. When all the sample videos have been produced, they will range through all categories of businesses.

My Intel tiny PC turned up and I am not disappointed. I may as well stick to 30 frames per second instead of 60 as the current videos play perfect. I’ve got it to boot up in Linux and auto run my software to play the videos on a loop. No screen tearing and running all over these last four days.

Over the next one to three weeks I should have the server infrastructure in place where I can live test my new system. As mentioned above, the documentation has been more of an important matter over this weekend off when I’ve had the time. The infrastructure will include storage, database solutions, communications, security protocols and a users interface to the server.

Throughout this entire project I’ve kept to a strict diet of royalty free and open source. In the future, the software I have used will get donations.

PS…

The initial test was a single ‘cpp’ program which links to ‘libvlc’ and ‘X11’ which opens a full screen window and attaches each instance being played to the full screen window. Now it gets complex. (not really)…

Libvlc and my Odroid

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.

 

Fullscreen video playlist done

Using Linux and libvlc I’ve finally got what I was aiming for. A full screen video playlist player. And it was quite easy.

The steps to get here:

  1. Monday: Play a media file. A few lines of code did this. And with the addition of one extra line of code made it full screen.
  2. Play a playlist of videos full screen. This is where things went wrong. After one video had finished, the vlc player would quit fullscreen, flash the desktop and then play the next video in full screen. This was not acceptable.
  3. Tuesday: Using the stock Linux libraries to go full screen. This took all of about 20 minutes from start to end. And again, in just a few lines of code. It was a chaotic night at home so I just finished up there.
  4. Wednesday: Just chilled out and watched TV after work instead.
  5. Thursday: I now needed to use the full screen window and attach the videos to it so that the desktop doesn’t appear. By just passing the window ID to the vlc media player, this was done.

Now all I need to work on the managing the playlists over the internet. And order myself and Odroid C2 with a few other gadgets. So far, this is going 100% perfectly.

By my reckoning, I should have a media player that boots up in less than 10 seconds and playing. How awesome…

The hefty part of the coding is about to start…

Linux X11 full screen

Wow! Just how easy was it to have a full screen window in Linux?

In windows, you had to include a shed load of libraries and link to them. In Linux you just link to X11, one or two parameters, and that’s it.

All I required was a basic window that I could attach the VLC player to, similar to any 3D API requirements, so that I could bypass VLC switching from full screen to desktop all the time. And all in 20 lines of code, not obfuscated, and one instruction per line, with a while loop for a pause, I got it. Windows couldn’t do that. It would take, erm, lots of, erm, junk to do it. erm 😉

Again, not a lot of time tonight to do stuff, so by the time I came round to getting this done, I thought I might as well set a target for this step to be done by tomorrow night. Now it looks like tomorrow night I can attach VLC to play a playlist.

See what happens tomorrow if chaos don’t arise.