Intro

This deals with rock internals, so fasten your seatbelts and expect many weird things along the way. I’m not necessarily proud of the state of the implementation, I’m just rolling with it and trying to improve it gradually rather than throw everything away.

An error out of nowhere

While working on my current game, John Q. Adamant, I was looking to extract a class into another module - this is routine refactoring and shouldn’t be too hard.

It happened when I least expected it.

Someone, somewhere (above me, presumably) made a decision. “From now on”, they declared, “all our new stuff must be written in Rust”.

I’m not sure where they got that idea from. Maybe they’ve been reading propaganda. Maybe they fell prey to some confident asshole, and convinced themselves that Rust was the answer to their problems.

I’ve been banging the same drum for years: APIs must be carefully designed.

This statement doesn’t resonate the same way with everyone. In order to really understand what I mean by “careful API design”, one has to have experienced both ends of the spectrum.

But there is a silver lining - once you have experienced “good design”, it’s really hard to go back to the other kind. Even after acknowledging that “good design” inevitably comes at a cost, whether it’s cognitive load, compile times, making hiring more challenging, etc.

In the Day 13 problem, we’re trying to take the bus.

Our input looks like this:

939 7,13,x,x,59,x,31,19

The first line indicates the earliest minute we can leave from the bus terminal, and the second line indicates the “identifier” of the buses that are active.

Each bus departs every “bus ID” minutes - bus 7 leaves at minute 0, minute 7, minute 14, minute 21, etc. The question is: which bus can we take first (apparently they either all go to the same destination, or we don’t really care where we’re going), and how long do we have to wait for it?

Time for the Day 12 problem!

In this problem, we have a ship. And we have navigation instructions:

• Action N means to move north by the given value.
• Action S means to move south by the given value.
• Action E means to move east by the given value.
• Action W means to move west by the given value.
• Action L means to turn left the given number of degrees.
• Action R means to turn right the given number of degrees.

I love diagrams. I love them so much!

In fact, I have fairly poor visualization skills, so making a diagram is extremely helpful to me: I’ll have some vague idea of how different things are connected, and then I’ll make a diagram, and suddenly there’s a tangible thing I can look at and talk about.

Of course the diagram only represents a fraction of what I had in mind in the first place, but that’s okay: the point is to be able to talk about some aspect of a concept, and so I have to make choices about what to include in the diagram. And maybe make several diagrams.

In part 1, we’ve looked at three executables:

• sample, an assembly program that prints “hi there” using the write system call.
• entry_point, a C program that prints the address of main using printf
• The /bin/true executable, probably also a C program (because it’s part of GNU coreutils), and which just exits with code 0.

We noticed that when running entry_point through GDB, it always printed the same address. But when we ran it directly, it printed a different address on every run.

In the previous article, we saw how to use NaturalDocs, a language-agnostic documentation generator. Today we’ll see how to use brummi, a tool specific to ooc, written by Friedrich Weber.

Generating .json files

The first step to generate docs using brummi is to use rock, to generate a set of .json files describing the code. The --backend command-line option allows to select which backend you want rock to use (the C backend is the default).

There’s a question that always comes up when people pick up the Rust programming language: why are there two string types? Why is there String, and &str?

My Declarative Memory Management article answers the question partially, but there is a lot more to say about it, so let’s run a few experiments and see if we can conjure up a thorough defense of Rust’s approach over, say, C’s.

While looking to write a pure ooc version of ftgl, I was reading the source of ftgl-gl3 and I stumbled upon this piece of code:

static inline GLuint NextPowerOf2(GLuint in) { in -= 1; in |= in >> 16; in |= in >> 8; in |= in >> 4; in |= in >> 2; in |= in >> 1; return in + 1; }

This is needed because dealing with power-of-two textures (32x32, 64x64, 128x128, etc.) is more efficient with OpenGL (some implementations don’t even support non-power-of-two textures!).