This incredible video was created by filming a series of nights in Norway.

I first saw this video here.

Today I came across a video in YouTube featuring the history of Ken Silverman’s Build Engine.

I remember spending countless hours, when I was young, using the Build tools for designing and scripting levels for games such as Duke Nukem 3D and Shadow Warrior, as well as creating new artwork and even editing the game configuration files (CON files).

Build Engine’s CON files were my first approach to programming, way before I learned how to program using C++. They used to have a weird syntax, but you could do all sorts of changes to the game. Even defining new monsters and items was possible thanks to CON files.

Here’s the video. It’s about 10 minutes long, but completely worth it.

The Linux Journal Magazine is currently running my article in their November issue. The articles features an introduction to Parallel Programming using the NVIDIA CUDA technology. I wrote this article for RealityFrontier and was kindly sponsored by CoroWare Inc. The Linux Journal introduces the article in their latest issue:

“If all that seems a bit too fluffy for your technology taste, you might just love Alejandro Segovia’s in-depth piece on parallel computing with NVIDIA’s CUDA technology. Video cards are great for gaming, but it’s amazing how powerful they can be when you use them for straight up mathematical processing. Alejandro shows how to take advantage of the little powerhouse sitting inside your computer case.”

As Raphael states in his post at the RealityFrontier website, a big thank you to CoroWare for the opportunity to write the article and to the Linux Journal for publishing it!

Some time ago a friend from Colombia asked me how to create a Shared Object under Mac OS X in order to be able to use it from a Python application (via ctypes).

Although the compiler most commonly used on Mac OS X is the GCC compiler, the version supplied by Apple has a handful of modifications which are specific for OS X. In particular, the -shared compiler flag, used to create Shared Objects under GNU/Linux based systems, has no effect.

In spite of this, Apple did introduce its own mechanism for creating Shared Objects along its GCC extensions. Assuming we have a file called mylibrary.c, which contains the source code for our library, we should invoke GCC like so:

gcc -dynamiclib mylibrary.c -o mylibrary.dylib

If the compiling process succeeds, this command should create a file called mylibrary.dylib, which can now be dynamically linked from other applications.

Unlike Linux based Operating Systems, Mac OS X seems to automatically add the current working directory to the DYLD_LIBRARY_PATH environment variable (an equivalent to Linux’s own LD_LIBRARY_PATH), thus it should not be required to modify this variable in order to have our applications link against the newly created library at runtime, unless, of course, we wanted to move the Shared Object to a directory different from where our process will be executing.

Finally, it should be taken into account that this mechanism is just a simplified example. A correct way to manage the library creation process would be by means of make or equivalent software construction applications, which provide several advantages to software developers.