New blog series on Unreal engine and C++ coming up

unreal-logo-small

Hi there people!

Thanks to my loyal followers for bearing with me with not posting much of anything lately.

I’ve decided to start a new series of posts dedicated to the Unreal 4 game engine and programming it in C++.

I’ll keep things simple, as I’m learning about Unreal 4 as I keep going with the posts, so don’t expect any Unreal expert trickery to be exposed in this series!

I do believe that creating simple games can be a great way to learn about programming in C++ and if you’re new to either C++ or Unreal
(or both), and wish to get going with some coding and simple game development, there should be something interesting in the posts to come!

I’ll be back!

 

Parallel Computing With CUDA Extensions (Part 1)

cuda_spotlight

Parallel Computing With CUDA Extensions (Part 1)

First, let’s see how to rate a CPU in a parallel way of thinking.

Let’s say we have an eight Core Intel CPU.
That’s:

With eight cores, you can execute 8 operations (Wide AVX vector operations) per core,
and each core has support for running two threads in parallel via Intel “HyperThreading” technology, so you get:

8 cores * 8 operations/core * 2 threads and end up with what’s called
“128-Way Parallelism”

For more about AdvancedVectoreXtentions (AVX) in CPU’s, check this page.

Programming without taking advantage of ANY multithreading / parallel processing
techniques, means that for each program you run, you use

2/128 = 1/64 of your CPU’s total resources (including the automatic “HyperThreading”).

In an ordinary C/C++ program you can only run code that uses the CPU as
the computing resource.
If people really took advantage of their cores and threading capabilities, this would
probably be enough for most regular applications, but for applications that does a lot of
heavy calculations, like video / image processing or 3D graphics it’s way better if you could
offload some of these tasks to the simpler (in terms of instructions), but well capable GPU(‘s) in your machine.

One way to do this is through the use of CUDA extensions.

In this model, the CPU is considered the “HOST” and each GPU is a “DEVICE”
in your system that can be used for doing calculations.
When such a program is compiled, instructions for both the HOST and any DEVICE
is created.
In CUDA the GPU/DEVICE is seen as a “CO-PROCESSOR” to the CPU/HOST.
The processor also assumes that the HOST and DEVICE has access to separate physical
memory where they can store data.
The DEVICE memory is typically a very high-speed block of memory, faster than the one
on the HOST.

The HOST is “In charge” in CUDA and sends messges to the DEVICE telling it what to do.
The HOST keeps track of:

Moving data:
1. From CPU memory -> GPU memory
2. Grom GPU memory -> CPU memory
CUDA’s version of C’s memcpy() is cudaMemcpy()
3. Allocating GPU memory
Again CUDA uses cudaMalloc() instead of malloc()
4. Launch “kernel” on GPU (in CUDA, the HOST launches “kernels” on the DEVICE)

A Typical flow in a CUDA Application would be something like:

1. CPU runs cudaMalloc on GPU
2. CPU copies input data from CPU->GPU with cudaMemcpy
3. CPU launches the transfered “kernels” on GPU (kernel launch)
4. CPU copies results back with cudaMemcpy

So, what is this “Kernel” stuff all about?

Guess we’ll find out in part 2 of this series…

Using the Digia Qt Framework (LGPL) for “commercial” applications

This post is targeted at any developer that needs a good framework to develop true cross platform applications.

With “true cross platform” I mean that you can build for Windows, Apple OS X, Linux, Android and other mobile platforms from the same code sources.

The licensing terms of Qt is the same whether you’re an “indie developer” or a team of developers.

There are many people out there, unsure if they should learn / use the Qt Framework, because of the relatively unclear definitions of the different licensing options.

Many feels that it would be a waste of time if they can’t sell the application in the end, without paying for a rather expensive Qt developer license or get legal problems if they include a certain part of their code.

The aim of this article is to clear up some of that uncertainty.

Qt isn’t just a GUI Framework.
You can use it to create just about any modern application with networking capabilities, 2D / 3D graphics, sound, you name it.

It’s a really nice way to get applications working on multiple devices and platforms, in the shortest time possible, and without resorting to some JavaScript “miracle application” that turns your source code into “working applications” for both desktop and mobile units and costs a fortune.

The user interface part (gui) of a Qt application looks really good and integrates with the platform it’s running on, so you won’t notice any difference from using an application created to run native on that device, like an OS X application written in Objective-C using Cocoa.

Qt isn’t only for C++ developers!
You can (and should) also use an XML like language called QML to create the user interface part of the application.
It’s even possible to create a complete simple application using nothing but QML if you wish.

This opens up for closer collaboration between designers and back-end coders.
It must be said that Qt is mainly a C++ framework, and to get access to the full functionality you need to use C++,
but for the user interface interface part, QML is the way to go for most projects. It saves you many hours of C++ coding.

So, what about the licensing question, man?

Oh, off course…

If the scenario goes something like:

“You’re a single developer or a team of developers that needs to use some functionality of Qt (like QtWidgets) in your application…”

The short answer is:

Relax, learn and use Qt, you can make money on the applications even if you use the LGPL version of the framework.
You need only be aware of two very important “limitations”.

1. Your application must be dynamically linked to the Qt components that came with your downloaded LGPL Qt distribution. No static linking allowed.

2. You can’t make changes to the Qt source code itself and sell your application based on the changed version of Qt.

3. Inform users of your application that Qt is used in the application in some licence text or in a readme somewhere within your distributed application files.

4. Provide a copy of the Qt LGPL licence file together with your distributed application files.

Other than that, you’re free to distribute your application as a commercial closed-source application, using any licensing you may want.

There are also corner cases, such as if you’ve made changes to Qt and those changes has been officially accepted as part of Qt, but this is not the case for most developers.

Hope this cleared things up a bit.

So start learning Qt and happy coding!