Month: March 2021


The Book That Every Programmer Should Read

No, it’s not Knuth’s “The Art of Programming”. I’m talking about quite an easy-to-read (compared to TAoP) book, which, in fact, does not require any engineering or mathematical background from the reader.

I am talking about C. Petzold’s “CODE”. It is a truly remarkable book about how computers work. Let me explain why I think this book is so awesome.

The book starts from the very beginning, from explaining what code is, bringing several examples, like Morse code and Braille’s system. It then goes on to explain how electricity works and how it can be used to represent information with binary codes.

In later chapters, Boolean algebra is explained and the author shows us how to build basic components of circuits (logic gates) with battery, wires and simple relays. Those are used later to build an 8-bit adder circuit and a RAM array. Eventually, the author describes a computer with a simple instruction set and random-access memory.

This book is so amazing because it shows how simple principles can be combined to create the basis of the complex modern technology. You should read it to (at least approximately) understand what really goes on behind all the loops, pointers, variables, jumps and complex data structures. It won’t give you insights about the inner workings of Intel’s processors, but you will understand the basic things which make that pile of plastic and metal do math, display pretty moving pictures and download pr0n from the internets. Which is very important.


During my second year at the university we were taught a course which was called “Computer Architecture”. What we really did during that course can be summarized as (painful) memorization of 8086′s instructions and writing a few programs in freaking Turbo Assembler (the year was 2008, by the way).

If only instead of all that crap we were taught what was written in Petzold’s book, it would’ve been one of the most useful courses ever, because:

  • It would really be about computer architecture and not about memorizing instructions or writing programs for a painfully outdated compiler;
  • I would actually learn something

Assembler for DCPU16

I have implemented an assembler for DCPU16 in C++. It can be found here: The assembler receives the source code from the standard input and writes the ROM to standard output. It supports labels too. To compile, you’ll need a C++ compiler with C++11 support. I was in a hurry, so the code is sort of slapped together with duct tape, but I hope to tidy it up a bit and add more features as Notch releases more specs.

A number of emulators are already available, I think I’ll pick one of them and extend it to support GUI for easier debugging.

UPD: Someone actually wrote an LLVM backend for DCPU16 –, which pretty much renders all the assemblers obsolete, so I’m discontinuing this one.


Brave Ball

It began in summer 2012, during a 12-hour layover in Moscow. After wandering around the airport for about an hour I got bored, so I broke out my laptop and started coding. I wanted to write something that had interactive graphics in it – I still remember how fun it was to follow NeHe’s tutorials years ago, and I wanted to re-capture that feeling.

Anyway, I ended up with a blob of messy C code that displayed a bunch of moving colored rectangles. I left it untouched for several months, but later I decided to come back to it and actually finish what I started. Ultimately I decided to rewrite it from scratch, this time using C++. So I tried to spend an hour or two after work writing code, drawing sprites and experimenting. If I actually worked every day, I’d finish in about a month, but actually the process took longer than that because I’m a lazy bastard.

The game has a sad excuse for a plot: the happy colorful world of Weird Little Creatures has been invaded by dark evil Meanies. You have to run and save all the defenseless younglings. Basically you just jump from platform to platform, avoid contact with the enemies and save the little creatures. In the end, there is an exit portal that you must step into.

I thought the game was pretty easy, but a couple of people I showed it to told me it was really hard. I don’t know, maybe I have played it so much that I got used to it. You can download it and see for yourself!

Some random stuff:

  • I used MS Visual Studio to write code, SDL/OpenGL for graphics, DevIL to load images, BASS to play sounds and music, mtPaint and GIMP to draw sprites.
  • I thought I’d eventually have to write collision detection between various geometric shapes, but it turns out you can do pretty well with rectangles too, if your art lends itself well to it.
  • You can actually draw sprites for your game, even if you’re not an artist. Just pick a simple visual style. I’ve never drawn sprites before, so I tried to have as little detail as possible, and compensate the lack of detail with motion, for example the antennae on the characters move, if the “protagonist” stops, it starts looking around, etc.
  • The mountains in the background are loaded from an image, but that image was generated procedurally (thanks to this great tutorial). Fractals can help you a great deal with creating art.
  • I rolled my own “packed file” format to store assets in a single file, but I’m probably going to use PhysFS in my next project.

The source code for the game (including assets) . I’m not particularly happy with the “engine”, but hey, it’s the first version. Anything you make for the first, and even second time, is gonna suck.


C++11 Smart Pointers are Not Just For Memory

RAII is a useful idiom. It helps prevent resource leaks by making sure that resources are freed when they are no longer needed, and as such, provides a simple form of garbage collection.

The C++11 standard library provides a number of class templates (shared_ptr, unique_ptr, weak_ptr) to use this idiom for memory management.

However, memory is not the only resource that we have to manage. Sometimes we have to make sure a handle (e.g. a file descriptor, an OpenGL texture object, a HWND, etc.) returned by some library is freed properly.

There is a useful trick that allows you to use the standard smart pointer templates to manage such handles as well.

To accomplish this, we need to do two things:

  • Specify how the resource should be freed;
  • Make sure that internally, the smart pointer stores a handle, not a pointer

All smart pointer templates have an additional template parameter that allows us to specify a custom deleter type. A deleter type is basically just a class that has an overloaded operator() which accepts a pointer (or a handle, in our case), and frees the resource associated with it.

Let’s show this on a simple example. In this example, I’ll write a custom deleter for an OpenGL shader:

1 2 3 4 5 6 7struct ShaderDeleter{ void operator()(GLuint shader) { glDeleteShader(shader); }};

view rawgistfile1.cpp hosted with by GitHub We can then use it with a smart pointer to replace the default deleter:

1std::unique_ptr<GLuint, ShaderDeleter> smart_shader(glCreateShader());

view rawgistfile1.cpp hosted with by GitHub

But we’re not done yet. This unique_ptr will store a pointer to GLuint internally, but we really want it to just store a GLuint, our handle. So how do we accomplish that?

The internal “dumb” pointer of std::unique_ptr<T, D> doesn’t just have the type “T*”. Its type is std::unique_ptr<T,D>::pointer, which is defined by the standard to be std::remove_reference<D>::type::pointer, or, if such type does not exist, T*.

In other words, if you add a typedef named “pointer” to your custom deleter, it will be used by the smart pointer internally. So, to get the desired behavior we just have to do this:

1 2 3 4 5 6 7 8struct ShaderDeleter{ typedef GLuint pointer; // Note the added typedef void operator()(GLuint shader) { glDeleteShader(shader); }};

view rawgistfile1.cpp hosted with by GitHub So, now our trick works! We create a new OpenGL shader during initialization and it will be deleted once the smart pointer goes out of scope!

1std::unique_ptr<GLuint, ShaderDeleter> smart_shader(glCreateShader());

view rawgistfile1.cpp hosted with by GitHub

There still is one caveat. The indirection operator won’t work as expected with this pointer. Writing something like:

glAttachShader(p, *smart_shader);

yields a somewhat cryptic compilation error in Visual Studio 2012. You should use the get() member function instead, like so:

glAttachShader(p, smart_shader.get());

It’s pretty easy to understand why this is happening by taking a look at the implementation of operator* in unique_ptr:

It’s trying to apply the indirection operator to a GLuint. Clearly, this should fail.

So why does it work when we don’t invoke the indirection operator on the smart pointer? That’s because the compiler won’t even attempt to generate code for a non-virtual member function of a class template if it’s never used (this behavior is, in fact, enforced by the language standard). Incidentally, code for virtual member functions will ALWAYS be generated (I’ll let you figure out why :) )