+---+---+---+
| 7 | 8 | 9 |
+---+---+---+
| 4 | * | 6 |
+---+---+---+
| 1 | 2 | 3 |
+---+---+---+

Normally moving from "*" to 7, 9, 1 or 2 would cost 2 movement points.

+---+   +---+
| 7 +---+ 9 |
+---+ 8 +---+
| 4 +---+ 6 |
+---+ * +---+
| 1 +---+ 3 |
+---+ 2 +---+
    +---+

In a hexagon moving from "*" to 1,2,3,4,6 or 8 would cost only 1 movement point. Moving to 7 or 9 would still cost 2 movement points.

Normal quads have only 4 attached quads. Hexagons have 6 attached quads.

QUAD GRID

+---+---+---+---+---+---+---+
| A | D | G | J | M | P | S |
+---+---+---+---+---+---+---+
| B | E | H | K | N | Q | T |
+---+---+---+---+---+---+---+
| C | F | I | L | O | R | U |
+---+---+---+---+---+---+---+

HEXAGON GRID

+---+   +---+   +---+   +---+
| A +---+ G +---+ M +---+ S |
+---+ D +---+ J +---+ P +---+
| B +---+ H +---+ N +---+ T |
+---+ E +---+ K +---+ Q +---+
| C +---+ I +---+ O +---+ U |
+---+ F +---+ L +---+ R +---+
    +---+   +---+   +---+

Shortest path from B to T in quads is B->E->H->K->N->Q->T
Shortest path from B to T in hexagons is B->(D|E)->(G|H|I)->(J|K|L)->(M|N|O)->(P|Q)->T

Even though the cost is the same, the possible routes in hexagons are not shortest if drawn.

The reason for this is because horizontal movement is always done in steps of 1.0 unit. Moving
vertical however is more tricky because steps can be either 1.0 (for example D->E) but also 0.5 (A->D)

Moving from A to E is however always two steps. Hexagon (A->(B|D)->E)

Moving from A to I is however 4 steps in quads but 3 steps in Hexagon (A->(B|D)->(E|H)->I)

Using coordinates A would [0,0] (both quad and hex) while "I" would be [2,2]
Moving from A to I in hexagon however lets you visit D which is [1, 0.5] Which can then move
to H which is [2,1]. These are both two steps with a distance of 1.5 where a quad is always limited to 1.0.

So Hexagons allows of steps that must be in distance either 1.0 (vertical movement) or 1.5 (horizontal movement)

So a hexagon doesn't only modify the allowed movement and cost, but because of the inherit properties it
also allows modifies the coordinate system (as adjacent nodes are at different distances).

This means that moving from A to U (whose coordinates are the same in both quad and hexagon)
The distance would be [6,2.0] covering the horizontal movement first we go

[1,0.5]  => A->D   [1,0.5]
[1,-0.5] => D->G   [2,0.0]
[1,0.5]  => G->J   [3,0.5]
[1,0.5]  => J->N   [4,1.0]
[1,0.5]  => N->Q   [5,1.5]
[1,0.5]  => Q->U   [6,2.0]

I had a post scheduled at 1200 today but when I checked it at home I noticed that it hadn't updated yet. It even said that it had missed its schedule. Calling the cron job a few more times didn't do anything so this is just a quick post to check if it does work now.

Update @ 2012-02-02 00:06: It seems to be working just fine

Even though I'm not racist I hate the diversity of compilers and OS so I decided to use Boost for all the timing relevant functions. Within boost you have two types of clock:

1. boost::posix::second_clock
2. boost::posix::microsec_clock

Thinking which one I wanted I decided not to go for the high-performance clock. I only want to know if a message had timed out and if I should send another one.

A basic example of the code would be this:

class SendTask : public IClientTask
{
public:
    SendTask()
        : m_SendTimestamp(boost::posix::second_clock::universal_time())
        , m_SendInterval(boost::posix::seconds(1))
    {

    }
    void Tick()
    {
        auto currentTime = boost::poxix::second_clock::universal_time();

        bool sendAgain = m_SendTimestamp < currentTime;
        if(sendAgain)
        {
            // ...
            // Send message again
            // ...

            // Increase the next timestamp.
            m_SendTimestamp = currentTime + m_SendInterval;
        }
    }

private:
    boost::posix::ptime m_SendTimestamp;

    // The default delay is one second (decided by constructor)
    boost::posix::time_duration m_SendInterval;
};

Timing the above code I was surprised to see that sending a message using UDP over the loopback took about 0.5 seconds, which was at least ten times more than what I had expected. After checking my code multiple times and not finding anything I could only come to the conclusion that somewhere in my code I made a wrong assumption. So I wrote a little test to at least ensure it had nothing to do with boost and to ensure it was my code.

int main()
{
    while(true)
    {
        std::cout << boost::posix::second_clock::universal_time() << std::endl;
    }

    return 0;
}

Removing all the duplicate entries that were printed I found out that the time difference between each timestamp was around 0.5 seconds. This would explain why it would take so long before it would send again. I told its resend delay is 100 milliseconds it would take at least 0.5 seconds because of the problem with the resolution/precision.

But I was using the loopback (sending to 127.0.0.1) and although messages can get lost there it should not happen that often. Sure I could replace everything with a faster clock but I wanted to know why this delay occurred. Taking another look at the send code I noticed that the following line:

bool sendAgain = m_SendTimestamp < currentTime;

If the send time is in the past it would send and this is also true for the very first time. Changing the code so that it checks if the next send time is less or equal than the current time fixed it and the performance increased to 0.005 milliseconds since it no longer had to wait for the first time out.

Sure I could have saved myself a lot of trouble by replacing the clock with the higher resolution variant (after striking concurrency of my list this was my next guess) but I rather spend a few hours on figuring out what exactly is going on. It takes time now but in the end it should save me time when I come before the decision which clock to choose.

When you need to convert an std::wstring to an std::string you should not simply do the following:

std::wstring input = L"Hello World";
std::string output;
output = std::string(input.begin(), input.end());

The above code is valid, but incorrect. A string is nothing more than a fancy array (just like a vector) but who is specialized for our basic usage of text (which is concatination and using the stream operators). If you look at std::wstring as a std::vector<wchar_t> and a std::string as a std::vector<char> then you should come to realisation that the above code performs an implicit cast (from wchar_t to a char).

If you use std::wstring to store UTF8 then there is no problem, but if you use it to store UTF16 then you do have a problem as you might lose some information. Also keep in mind that it is perfectly fine to store UTF16 in an std::string but then you should realize that every 2 elements in the string is one single character.

More correct (but still incorrect) would be:

    // Just making certain that wchar_t is 16 bits.
    assert(sizeof(wchar_t) == 2);
    assert(sizeof(char) == 1);

    std::wstring input = L"Hello world";
    std::string output;
    std::wstring::const_iterator it = input.cbegin();
    while(it != input.cend())
    {
        output += ((*it) & 0xFF00) >> 8; // Add the most significant bits.
        output += ((*it) & 0x00FF) >> 0; // Add the least significant bits

        // Going to the next wchar_t
        ++it;
    }

After logging in you are presented with the new Metro GUI which is confusing if you are not familiar with it (and even more if you have no touch device). So a few hints:

1. If you move the mouse completly to the left bottom you will see a start menu. Clicking on start will always bring you to the metro page.
2. If you move the mouse to the rightside of the screen you will get to see a thumbnail of the application to switch to
   1. Left mouse click will switch to it
   2. Scrolling will display other running applications
   3. Right mouse click will give you the snap options
3. Alt-F4 closes applications
4. The windows key will switch between the metro interface and the application
5. In metro applications the right mouse button often shows menus at the top and bottom, but you will never see quit (which confused me a lot)
6. Windows-R gives you the run dialog and yes mspaint, wordpad, notepad, explorer are all available.
7. Seen enough and want to shutdown? Move to the left bottom and click on devices and you will get a toolbar on the right. The center bottom button there is a power off button.

After playing with it for a few hours there are a few things I like and a lot I don't. Keep in mind that this is a developer preview so I'm sure a lot will change before the initial release.

The things I liked where:

• Snapping works well and frankly I love it. This is done way better than I have seen before.
• The twitter app looks good, works good and when snapped to 1/3 of the screen it is just a killer app

The things I don't like are:

• It's confusing, it took me a while to get around
• No good replacement for touch if you only have a mouse
• I miss the old start menu (which is a first since I enjoyed each new version of the start menu so far)
• Scrollbars are ugly
• Metro interface is confusing

As a closing note I would say that Windows 8 is not suitable for coorporate enviroments (no good function for metro interface) and is more aimed at the tablets. If I would have to pick a tablet I would wait until Windows 8 for tablets is ready.

So I have been looking at alternatives like NoSQL database. NoSQL is not a formal term but in general it means "Not Only SQL". It's a new development inside the database world and one I think that is certainly worth looking at. The first SQL was created in 1974 which in our line of work is really old. I also want to point out that it can only be so old because it has proven it's value. NoSQL on the other hand is from 1998 and the most common flavors are Key-value and Document store and graph.

Document store is in my opinion the coolest one as you can often just dump the data in any table. You don't need to look at the format. This would mean that we can still freely define types but at the same time we can also have different values and parameters.

There is only one downside: Eventual Consistency.

I understand the reason behind it (delaying writes while allowing reads) but there are plenty of situations where it is not acceptable. Sure you can catch it in your application layer but again that is not what you want.

Currently I think the best method is using MSSQL where a row also contains an XML document.

If you create a core application against which does only a few core elements (like basic rendering and providing input) and you put the rest in DLL which can dynamically be loaded and unloaded you will in theory never have to touch the core application again. The rest are all buildingblocks which are continuesly improved. If you do this, you can easily rollout (or rollback) features. Even cooler is that with another product you only have to write a few new buildingblocks (assuming you continuesly improve your old buildingblocks), create new content and your done.

If after a few years you want to re-release your game but you want to use the improved render, all you need to do is replace it. No more memory leaks the old version had

But for that we need to continuesly serivce our code, something I believe is rarely done.

The major advantages of working with Mercurial over SVN are:

• No unexpected merge (or merge conflicts)
• Developers can work independent of each other. They don't have to worry about commiting broken code, only syncing broken code.

There are two types of branching:

• Unnamed branches
• Named branches

Named branches are comparible to what we know from SVN. Unnamed branches are done when you have reverted to an old changeset and then make a change, they are like an automatic branch that occur where normally (in SVN) you would have conflict.

An example can easily be created by making a few commits, then revert to and old one because you want to try an alternative approach for a problem you were having and start commiting then. Once your done with the alternative you can decide which branch should be closed and which one should be continued.

When syncing your changesets with someone else, you make it possible to look at what the other has done without having to worry that your own code gets broken by the changes. For example you encounter a problem and notify another developer of it who tries to fix it while you continue work on your own problem. Once both of you are done, you can review each other code without having to merge. Then one is tasked with merging it while another continues with his tasks. Once done you simply merge again and you are done.

You can always sync your code with a central repositorie. It's not uncommon that you are working on a large issue which might take a day or two. With Mercurial you can still commit as you normally do and if only a central repository is backed up you can still push your changes to that location without interfering in someone else his work.

Another great feature is shelving. Simply put it puts your changes on a shelve. Imagine you are working on a feature and suddenly you have to put that on hold as your boss wants you to work on a bug. You can either complete what you were working on or revert all changes. With shelving you put those changes on the shelve and when you are done with whatever had a higher priority you can take the changes from the shelve and continue as if nothing had happend.

There are, as always, a few bad things about moving from Subversion to Mercurial. First of all, Subversion is linear which gives you a linear method of developing. Secondly because Mercurial automatically creates branches and you would have to actively control this by doing merges often.

Mercurial has a lot of nice features like being able to import from SVN (nice if you want to do a complete switch) as being able to rebase (similar to Git). Also Mercurial could easily be intergrate in our toolchain.

Since I mentioned Git, I would like to say that I have thought about it but decided against using Git. Git has no native version for Windows. Git was also hard to start with, heck, the installer alone requires several extra steps. As a developer I don't want to worry about the tools or how it should be used. Mercurial was ready with just a few steps and working with it is quite easy compared to Git which I was messing around with for a few days. So basically the choice was made on personal preference

So up in the attic I searched for my inline skates and found them in one of the boxes. I had indeed bought them and I recalled that they were quite expensive for me at the time. They were bought in France when we were there on vacation and I had indeed used them for only a week or so before I boxed them in the attic. The weather in the Netherlands was what excpected in the Netherlands: Nothing but rain. The year after that the weather was also poor and so I forgot all about them.

After cleaning the frame and wheels (I had not done that when I boxed them ) I geared up (wearing protection for elbow, knees and wrist), I finally got up and... almost planted my face on the ground. I admit I knew that I would have trouble skating again, but except the first time I wore skates I had never had any trouble getting up. I guess that the years of sitting behind a desk, hitting the keyboard while writing code had not improved my balance. Big surprise there. However that was indication enough I had to learn everything from scratch again.

So after a few test rounds on the parking lot, learning to brake and to turn I was reminded why I didn't like skating on the parking lot with these skates. The wheels of my skates are 80mm 82a which means that they are small and reasonable soft and the the parking lot has a lot of bricks. So after a few minutes you feel like your feet have been  put in the blender. Leaving the parking lot behind me I left in a random direction. I'm proud to say I did not fall, but it took a lot of effort and I wouldn't be suprised if I have lost my balance more than 20 times.

When I decided to rest I was tired and everything hurt. My arms from spinning, my feet from the poor road, my back because it wasn't used to bend like that and my head because it was the middle of the day and it was hot. After a few minutes of recovering my breath I decided to go back home. To my suprise going back was a whole lot easier. I only lost my balance a few times, four or five times if I recall correct, and the rough tarmac didn't feel so rough anymore. I enjoyed it. The distance skated was only 8 kilometers (about 5 miles) but for the first time after so many years it feels like quite a feat.

I only hope that this weather will stay as I want to do some more skating.