Probably Dance

I can program and like games

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 »

A simple jump

Here at DigiPen people make a lot of platformers. And I see them getting the basic jump wrong over and over again.

It turns out that you can write a whole lot about the implementation of jumps in games (ideal jump height and speed, amount of air control, double jumps etc.) but in this post I’ll just explain how to start a jump, because this is where I see people repeating the same mistake: If you have stepped just one pixel too far over the edge of the platform before pressing space, you will fall to your death.

Fixing that is fairly simple.

Read the rest of this entry »

Loving std::unique_ptr

I am falling in love with std::unique_ptr.

It’s part of the new C++11 standard and is pretty much a smarter way of doing auto_ptr. The main difference is that you can not assign or copy it. Meaning it really is just a handle for a pointer that deletes it’s content when it gets destroyed.

Which doesn’t sound like much, but it will stop you from making so many mistakes. The benefit of it is that now you have a clear concept of who owns the content of the pointer.

Any time where you used to do

class Foo
{
    Base * member;
public:
    Foo() : member(new Derived()) {}
    ~Foo() { delete member; }
};

should just be replaced with

class Foo
{
    std::unique_ptr<Base> member;
public:
    Foo() : member(new Derived()) {}
};

Read the rest of this entry »

SSE2 in Visual Studio

So for some reason I thought I should be using SIMD in my student projects because it’s something that I should learn about, and I might as well do that when I’m not bothering other people with it.

It turns out that Visual Studio will hate you for it. It will hate you for using objects that have a specific alignment in memory.

The reason I’m writing this post is because I just had to write my most ingenious (not) workaround yet for getting a SSE2 class to work with Visual Studio:

class Vector4
{
    union {
        __m128 xyzw;
        struct { float x, y, z, w; };
    };
    /* ... */
#ifdef DEBUG
// for some reason visual studio sometimes copies a Vector4 to a non-aligned position
// in debug mode. which is illegal and crashes the game. it never uses that Vector4
// though, so just changing the copy constructor to not use SIMD is enough
inline Vector4(const Vector4 & other) : x(other.x), y(other.y), z(other.z), w(other.w) {}
#else
inline Vector4(const Vector4 & other) : xyzw(other.xyzw) {}
#endif

Read the rest of this entry »

It’s not a generational thing

I’ve often heard that for games to be properly accepted, we just have to wait a couple of years until those people who haven’t grown up with games are no longer in positions of power and then we’ll be fine.

I no longer believe that. I think that a large part of the current generation of young adults actually has a pretty bad opinion of games.

Read the rest of this entry »

Storing information in a .png

Spore did a neat thing where they stored the creature information in a .png file that was a picture taken of the creature. So to share the creature you had to share the image, which is pretty cool. And it turns out that it’s really easy to do. Well if you are already using libpng that is.

I implemented it for the game Leshy, but we only used the feature for the auto save functionality of the editor, because the game didn’t have loading and saving. (simply because it would have been too much effort to program a menu that allows you to load and save)

Autosave file for Leshy editor

Auto save file for the Leshy editor. This is the actual save file. I could load the level from this image.

Read the rest of this entry »

My “Way Too Generic Serializer”

I wrote a serializer for my engine that is extremely convenient and generic.

A piece of serialization code in the engine looks something like this:

class PlaceMode
{
public:

    // ...

    SERIALIZE_FUNCTION(1)
    {
        SERIALIZE_START();
        if (version < 1) SERIALIZE_BASE(State);
        else             SERIALIZE_BASE(EditorState);
        SERIALIZE(archetypeNames);
        SERIALIZE(lastPosition);
        SERIALIZE_END();
    }

private:
    std::vector<std::string> archetypeNames;
    Vector4 lastPosition;
};

Read the rest of this entry »

Template Metaprogramming, Reflection in C++0x

So I’ve been working on the serialization code for our engine. And I’m finally understanding the more complex aspects of template metaprogramming, and it turns out that there are some neat things you can do with it that aren’t directly related to serialization.

OK let’s say you have an editor in your game, and in this editor you have a button “Add Component” which adds a new component to an entity. That button would open a pop-up menu, where you can select from all your component types and after selecting one, a new instance of that component-class is created and added to the entity. How do you populate that list? My solution using template metaprogramming and reflection is after the jump:

Read the rest of this entry »