Probably Dance

I can program and like games

Category: Programming

Implementing coroutines with ucontext

Coroutines are a way of doing cooperative multithreading where each context has it’s own stack. And they can be incredibly useful for games. (I’ll use the word context as the coroutine equivalent of a thread) The basic idea of a coroutine is that you can yield from a context in the middle of a function, and then you will continue exactly at that point when the coroutine gets called the next time.
Imagine that you want something to happen in a sequence, for example you want to spawn an enemy, show a text for two seconds, then kill the enemy and show another text for two seconds. A trivial implementation would be this:

void sudden_exploding_unit(const Vector3 & pos)
{
    std::unique_ptr<Entity> guy = spawn_entity(pos, "grunt.entity");
    sleep(1.0f);
    show_text(pos, "oh no he is exploding!", 2.0f);
    sleep(0.5f);
    explode(*guy);
    sleep(1.0f);
    show_text(pos, "well that was underwhelming", 2.0f);
}

Even though this code is simple, you would probably have a large amount of pain to implement this in a game engine, because a game can never block, and this code is sleeping all over the place. You’d probably end up writing some kind of state machine (maybe using a kismet-like scripting system) or if you’re a terrible person you’d use asynchronous callbacks. State machines can be a fine solution, but they introduce way too much infrastructure for such a trivial piece of code.

Enter coroutines. If your engine has coroutines, you can write exactly the above code. With very little downsides. Because you could just sleep like this:

void sleep(float seconds)
{
    while (seconds >= 0.0f)
    {
        yield(); // resume here next frame
        seconds -= global_dt;
    }
}

Read the rest of this entry »

Learning D Part 3: Garbage Collection

Garbage collection is a red flag for any C++ programmer, simply because a garbage collector makes it more difficult to use the language for the kinds of things that C++ programmers like to program.

When I started programming in D, I was going to give the garbage collector the benefit of the doubt. The language has enough smart features that I figured that the designers must have had good reasons for including a GC.

But really, it’s a mess. In fact it’s a bigger mess than I have seen in other garbage collected languages. Fortunately that mess is solvable, and where it isn’t solvable the language designers could probably make it less of a problem.

Read the rest of this entry »

Learning D Part 2: Random Little Things I Like

D is better than C++ in many ways. Here are a couple examples that I have encountered so far.

Let’s start with the scope keyword:

void main()
{
    OSInterface.Load();
    scope(exit) OSInterface.Quit();
    //...
}

What this means is “at the end of the current scope, run OSInterface.Quit();. Meaning I can put the call to freeing resources right next to the line where I allocate it. There is also scope(failure) which only runs the when there is an exception, and scope(success) which only runs when the scope exits normally. This is a much better solution than try {} catch {} finally {}.

Another cool thing is lazy evaluation, for example in the function std.exception.enforce, which has this signature:

T enforce(T)(T value, lazy const(char)[] msg = null, string file = __FILE__, size_t line = __LINE__)

Read the rest of this entry »

Learning D Part 1: IDE and Libraries

I am learning the D programming language.

I’m a C++ programmer, and like most C++ programmers I am rather annoyed with C++. It can be a pretty bad language. The problem is only that all other languages are even worse for the stuff that you’d want to use C++ for.

But D seems promising. Reading through the features of the language, you notice that it has many smart solutions for things which are cumbersome or error-prone in C++. I’ll go into benefits and problems of features one by one as I am using them. But the D overview page says under “Who D is for:”

  • Programmers who routinely use lint or similar code analysis tools to eliminate bugs before the code is even compiled.
  • People who compile with maximum warning levels turned on and who instruct the compiler to treat warnings as errors.

Which sounds like me, or at least sounds like the programmer I wish I was.

But to start, you just want a simple “Hello, World” on the screen. And that already is kinda complicated in D.

Read the rest of this entry »

First Class Functions in C++

I’ve been working on a library that allows you to treat functions as first class objects in C++. Meaning you can assign to a function. Here’s a download link, and here’s a very simple example:

#include "fcf.h"
void foo()
{
    std::cout << "foo\n";
}
void bar()
{
    std::cout << "bar\n";
}
void main()
{
    foo(); // prints "foo"
    auto oldFoo = fcf::function(&foo);
    FCF_ASSIGN(&foo, &bar);
    foo(); // prints "bar"
    FCF_ASSIGN(&foo, oldFoo);
    foo(); // prints "foo"
}

If you have ever worked in a language with first class functions, you’ll know that you can do some quite cool stuff with this.

Read the rest of this entry »

How to make successful student games

I’m almost done with DigiPen. Time to write down some learned lessons. I was only at DigiPen for two years, so others could probably write this better, but until they do there is this post. In both years I was in the most successful game team of the Master’s program, which is my claim to being qualified to write this post. So here are a couple rules, starting with

1. Gameplay first

This is the first point on Blizzard’s mission statement, and they mean “prioritize gameplay.” Do that. But for student games I consider it even more important to interpret that as “work on gameplay first.” The biggest mistake I have seen on student games is wasting time on features that don’t improve gameplay in the end. You do not have time for a student game.

Now how do you finish gameplay first?  Obviously you need tech to do your gameplay. If you want to make a physics-based puzzle platformer, someone has to implement your physics. But I would consider it a mistake to work on the physics until you know that it will result in good gameplay. Which is a problem.

Read the rest of this entry »

Old Wisdom

I recently came across this article about 10 papers every programmer should read. Now I don’t necessarily agree with all of that list, but here is the important part: I am about to finish a Master’s degree in computer science, and I have never heard of any of those papers before.

That is a list of papers which are sometimes more than 40 years old. Some of these gave us the assumptions that are normal for us to make about programming these days. I learned programming in the past ten years, and I had to rediscover some of this knowledge myself. I have made mistakes in programming that should never have been made, because people had solved those problems years ago. And I still see people make those same mistakes that I’m now smugly smarter about.

So what is there to do about it?

Read the rest of this entry »

Expensive Cheap Code

I was going to write a blog post about how to avoid a specific problem, until I realized that I should probably outline the problem first. I call this expensive cheap code, and I realize that the name is not a good name. It comes from buying the cheap version of something expensive.

When you buy something expensive, you do not want to get the cheap version. Because the cheap version will work, it just won’t work well. For example if you buy a big screen TV, but go for the cheap version, you may end up with a bad image quality that nags you every time that the colors are wrong. Or the image is stretched and you can’t unstretch without ruining all other channels. The right thing to do would be to get a new TV and get rid of the old one, but you don’t want to do that because even though it was the cheap model, it was still pretty expensive. And after all it only has small problems.

This is even more frustrating if you buy tools at the hardware shop. Since you probably don’t use your tools all that often, you will be frustrated for years with something that works, but doesn’t work well. And you don’t want to throw it away, because it works after all, and you don’t use it all that often.

Read the rest of this entry »

Code ownership

I’ve had some frustrations with code ownership recently. I did not have problems where someone broke something in code that they were not responsible for. I’ve found that people tend to be pretty careful about modifying code that they don’t often work with. Instead my problems have always been that someone doesn’t want other people to touch their code. And then you can’t fix even simple things because you have never looked at their code before and then if a small problem is holding you back, you have to wait at least a day for it to get fixed by whoever “owns” that code.

The simple way to solve that would be to say “everyone can modify any code” and I do like that idea a lot. But let’s see what other people say about code ownership. I’m going to use this post to collect my thoughts on code ownership.

Read the rest of this entry »

Towards less side-effects

C++ has very little protections against side effects in programming. You’ve got const and that’s about it. And const doesn’t survive through pointers so there’s nothing to stop you from modifying other objects as you please. I like things that stop you from making mistakes. So I thought about how to introduce more things that would make it more difficult to have side-effects in your programming.

I’ve found that you can reduce the side effects in your code by being careful about which pieces of code get dt, and by making all globals const, so that you have to manually pass non-const refs around and make them conscious decisions.

Read the rest of this entry »