Rktcr: Demo One

As promised, Demo One of Rktcr is now available for download on the game's web page. Please enjoy to the full extent allowed by morality, good sense, and the laws of thermodynamics. (And then drop me an e-mail, IM, or comment.)

Rktcr: Preparing for Demo1

This week, I've been preparing the next demo release of Rktcr. I expect to have the build up tomorrow. For now, all I have for you are screenshots and descriptions of a few of the refinements I've added to the game in demo1.

Tree-Style Path Select

Path selection got a major overhaul for demo1. Now it is easier to see what paths exist for a zone (and their relative lengths). Clicking on a portal will immediately select the fastest path to that portal.

Also, the opacity animation in the displayed path is really quite pretty. If I make an announcement video for demo1, I will probably dwell on it longer than necessary.

End Markers

The win markers now show whether you've beaten the par time (and your personal best). Also, there is now a distinguished lose marker for running out of time budget in a zone.

Colorful Text

Character names (and their pronouns) are now colorful. This can make dialog a bit more sensible if you pick weird/pathological names.

Time Control

I've changed the way time control works -- 'a' and 'd' still move backward and forward, but 'w' and 's' have been removed and 'ctrl' now slows time (just like 'shift' speeds it up). This change was based on feedback from Taus and Mike, and on my desire to free up 'w' and 's' for path selection.

Copy/Paste

You can now copy paths out of rktcr using Ctrl-C and paste them in with Ctrl-V. This allows for sharing of paths without having to actually find the .path file.

By way of example, the path shown above is:

1 af169 f2 cf38 f3 af65 f53 af41 f41 af13 f19 af22 f21 af17 f11 af24 f13 af47 f15 af28 f17 af100 f8 af2 f70 af3 f4 af66 f14 cf96

Why, cl.exe, Why?

When compiling C++ projects (e.g. Rktcr), I use different compilers on different platforms: Microsoft's cl.exe from Visual Studio Express Edition on Windows, Apple's clang++ from XCode on OSX, and g++ from the GCC on Linux. (These also use different versions of the C++ Standard Library, for added variability.)

This is great for catching errors in my code, as I get three different sets of static checks and three sets of design decisions (for those memory bugs that "just happen to work" on one system or another). But it also means I get exposed to a fair amount of compiler (and system library) quirkiness.

Today, I'm going to talk about one of the odder bits of behavior I've seen out of cl.exe (Version 17.00.60315.1 for x86 from Visual Studio 2012 Update 2).

I ran across this a few months back, but have been lax in posting because I didn't have any sort of CSS styling set up for posting code in news.tchow.com ; a situation which I have partially rectified (no syntax highlighting or fancy line numbers; sorry).

The Code

Apologies about the spacing in this code. Blogger apparently converts tabs to single spaces. For reference, using spaces to indent code is wrong.

#include <iostream>

template< int N >
struct TrivialTemplate {
    int val;
    typedef TrivialTemplate< N > type;
};

struct NoTemplate {
    int val;
};

//Consider different types of Coord:
#if COORD==1
typedef NoTemplate Coord; //<-- (1)
#elif COORD==2
typedef TrivialTemplate< 27 > Coord; //<-- (2)
#elif COORD==3
typedef TrivialTemplate< 27 >::type Coord; //<-- (3)
#endif

struct Pt {
    union {
        Coord arr[2];
        struct {
            Coord x;
            Coord y;
        };
    };
};

int main(int, char **) {
    Pt pt;
    pt.x.val = 12;
    std::cout << pt.arr[0].val << std::endl;
    return 0;
}

This C++ code defines type Pt, which makes use of a struct wrapped in a union to allow individual coordinate access as pt.x and pt.y, and easy coordinate indexing with pt.arr[i]. (This method can be extended to allow synonyms like pt.x and pt.r and subvectors like pt.xy or pt.yz. I use it in my Vector.hpp.)

The Problem

Notice that the lines marked (1), (2), and (3) all define Coord to be the same type -- a struct with a single int as a member -- but in slightly different ways.

So, with the line marked (1), things compile fine:

c:\Users\ix\Code\rktcr>cl /nologo /EHsc /W3 /WX /DCOORD=1 weird_template.cpp
weird_template.cpp

c:\Users\ix\Code\rktcr>weird_template.exe
12

c:\Users\ix\Code\rktcr>

If I use line (2), I get some weirdness:

c:\Users\ix\Code\rktcr>cl /nologo /EHsc /W3 /WX /DCOORD=2 weird_template.cpp
weird_template.cpp
weird_template.cpp(20) : error C2621: member 'Pt::arr' of union 'Pt::<unnamed-tag>' has copy constructor
weird_template.cpp(31) : error C2039: 'arr' : is not a member of 'Pt'
        weird_template.cpp(18) : see declaration of 'Pt'
weird_template.cpp(31) : error C2228: left of '.val' must have class/struct/union

So, what happened? Well, cl.exe has (presumably) synthesized a copy constructor for Pt::arr -- which, after some typedef expansion -- is an array of TrivialTemplate< 27 >. Now, having non-trivial constructors and destructors for data in a union is problematic, because the whole point of a union is that its members overlap in memory. However, it's also odd that a copy constructor would be synthesized -- after all, TrivialTemplate< 27 > is functionally identical to NoTemplate, and no constructor was synthesized there.

Indeed, neither g++ or clang++ have any problems compiling this code.

But here's where it gets really weird. If I compile with the line marked (3) active -- that is, if we talk about TrivialTemplate< 27 > using a typedef it contains for itself, one would expect the same error.

Instead, it just works fine:

c:\Users\ix\Code\rktcr>cl /nologo /EHsc /W3 /WX /DCOORD=3 weird_template.cpp
weird_template.cpp

c:\Users\ix\Code\rktcr>weird_template.exe
12

c:\Users\ix\Code\rktcr>

So, where does that leave me? Spending time writing workarounds -- in this case, my planar map code (which uses templated classes wrapping integers to make sure it isn't going to overflow) now has a fair number of uses of the somewhat odd-looking BitsInt< N >::self.

This is certainly a lot nicer than the llvm-gcc bug that incorrectly passed unions to functions (effectively reordering function parameters). That bug led to me abandoning Apple-supplied compilers on OSX until clang was mature enough.

Rktcr: Stylish Tree Path Select

Today, I continue to progress on Rktcr's tree select. Actually riffling through the paths feels much more natural and usable than before, with a small magnified region around the current tick and markers to indicate important path events.

The styling of the tree is also improved, with different thicknesses for different control signals. I like how this works, and something like it is likely to appear in the next demo release.

Rktcr Path Select Tree

Today, I decided to dive back into revising path select mode in Rktcr. As I mentioned before, this has been a process without a clear design answer.

However, I think I'm getting closer. Today, I worked on a tree-like view and path selection therein. This prototype doesn't yet have flashy graphics on the tree, any sort of magnification for dealing with longer paths, or the ability to do any editing of paths. However, it does give a clear impression of the relation of paths (especially their relative times).

With some markers for important events (gems, finishing), and a fair amount more graphical polish (using lines is... well, not optimal, for sure) I think this has the potential to be the new path select.

Enlightening Work

After a slow day and a half, the C++ port of Rainbow now has enlightenment working.

The next thing to do is probably to revisit how control works, and build effects to reflect the current state of each frequency band (unclaimed, claiming, following, crashed). These will be different than the mouse-control effects, because with touches one does not know where an inactive control point lies.

Utilitarian Level Select

Today, I completed the last pieces of the editing levels puzzle for my C++ port of Rainbow.

The first of these was level loading and saving (which doesn't really have a screenshot representation). The second was level selection:

This is a utilitarian screen designed for use when editing levels. Tapping any level edits it, tapping a '+' spot edits a new blank level.

One final thing I might add add to the editor is some sort of zoom capability (or I could forgo editing large levels on iPhone). The downside of this is it might encourage the creation of levels with detail too small to play on one screen; and I'd rather avoid having to have zoom during play, given that the rainbow's trail is accumulated into a framebuffer.