Last Ray of Hope

My browser at work seemed to keep the background image, so for now I’ve removed the image from the website so it won’t be able to find it.

At the weekend I’ll see if I can find out whats causing it to appear.

Also at the moment I’m working on trying out some types of pagination for multi-page posts.

Just updated the site theme to v3.0.0, seems WordPress doesn’t notify me when it goes out of date since I was using v1.0.8.

Text seems a lot more crisp in this one.

Today while browsing around the interwebs, I came by an archive of my old website, which was originally a Final Fantasy website.

But in my news posts from around that time, I was talking about a newer version of the battle system I had built into the custom made forums I had created since I couldn’t afford vBulletin. I named them dejaBoards, after a friend who had the alias Dejaina Rhea.

I had completely forgot I had wrote them, and the fact they made a lot of other forums hate LastRay since also being Final Fantasy forums, they couldn’t do it.

Though funny story about that, Final Fantasy Republic actually purchased the ability to look at the sourcecode for them back in the day they were making theirs. I think they also stole the idea of shops from me.

Hopefully at some point get around to re-uploading them to this site and reverse engineer the database I had setup for them. Then maybe even update them use java to get a better graphical version. They certainly need their queries cleaned up though.

Updated my WordPress blog with the old entries from the archive.

This week I came by a new kind of bug that I’ve never had before, and is up the top of bugs I’ve came by when using CodeWarrior, the top still being invisible syntax.

Though I don’t think anything can top that, it can be hell if you have garbage at the end of a line, and you can’t see it when even though the compiler tells you something is wrong, luckily to solve that one, you just press a key or change someone on the same line and it makes it visible.

Anyways, this bug is caused by having overloaded pure virtual or virtual methods in a base class, but only implementing some of the them in the derived class.

It causes the compiler to not acknowledge any of the other overloaded functions, which you can end up spending a lot of time trying to solve if you’re not familiar with it.

The below code shows an example base class for causing this error.

class BaseClass
{
    //
    // Functions
    public:
        //
        //
        BaseClass()
        {
        }

        //
        //
        virtual ~BaseClass()
        {
        }

        //
        //
        virtual int Multiply( const int inValue1 )
        {
            return 2 * inValue;
        }

        //
        //
        virtual int Multiply( const int inValue1, const int inValue2 )
        {
            return 2 * inValue1 * inValue2;
        }
};

If in the derived class you implement one of these, as shown below, and then try to access one of the other overloaded that are only implemented in the base, the error will happen, telling you something like there are no overloaded versions of that function that take that parameters you are giving.

class DerivedClass : public BaseClass
{
    //
    // Functions
    public:
        DerivedClass()
            :
            BaseClass()
        {
        }

        //
        //
        int Multiply( const int inValue1 )
        {
            return 3 * inValue1;
        }
};

//
//
int Main()
{
    DerivedClass testClass;
    return testClass.Multiply( 2, 3 );
}

Now I’m sure I had use overloaded virtual functions before, so why was this happening now. So after a bit of searching I found out that only some compilers have support for this.

The reason the error occurs, is because the compiler generates a list of virtual function names to link to in the class. However, if it fails to find a function matching the name of what is being called, it will check the base.

Because we had overloaded only one of overloaded virtual functions, it ended its search in the derived class. And when it tries to associate the correct function call with the correct function, it notices that the function has a different number of parameters to that which is recorded in the list, and causes an error.

Now there is a way around it, you explicitly tell the compiler to use the functions listed in the base by use of the “using” keyword.

class DerivedClass : public BaseClass
{
    //
    // Functions
    public:
        //
        //
        DerivedClass()
            :
            BaseClass()
        {
        }

        //
        //
        using BaseClass::Multiply;

        //
        //
        int Multiply( const int inValue1 )
        {
            return 3 * inValue1;
        }
};

//
//
int Main()
{
    DerivedClass testClass;
    return testClass.Multiply( 2, 3 );
}

This will not error, since when the compiler is generating a list of functions, it will also include the Multiply functions in the base. The using keyword also has scope, so putting it in public will make the functions accessible outside the class.

A great end to 2009 and start to 2010, SNOW!

To think a short time ago, having a white Christmas was extremely unlikely, nowadays it seems to be every year. Thanks Global Warming :).

It started on the same night as the office Christmas party, and on my way home I literally got covered in snow to the point of becoming a walking snowman.

In January it snowed some more, creating a layer of ice which turned everywhere into what looked like a glacier. Apparently, they run out of grit too, which was unfortunate, because when they finally got some more to put down, it began to snow again.

Lots of great snowmen this year :).

In 1726, there were tensions between Lilliput and Blefuscu, the problem being soft-boiled eggs. The inhabitants of Lilliput crack open their eggs at the small end, while the inhabitants of Blefuscu crack open theirs at the big end.

In 2010, while writing a Midi file parser in C#, I needed the ability to swap the endian of the data, since Midi files are stored as Big Endian, converting them into Little Endian.

I would have thought there would be some function within the BitConverter class to be able to swap, but there didn’t appear to be, so I wrote my own.

Since swapping endian is just reversing the byte order, the simplest method would be to get the bytes of a number, and reverse the array, then reconstruct the number using the reversed bytes.

//
//
using System;

//
//
namespace Midi
{
    class Endian
    {
        //
        //
        public static UInt16 SwapUInt16( UInt16 inValue )
        {
            byte[] byteArray = BitConverter.GetBytes(inValue);
            Array.Reverse(byteArray);
            return BitConverter.ToUInt16(byteArray,0);
        }

        //
        //
        public static UInt32 SwapUInt32( UInt32 inValue )
        {
            byte[] byteArray = BitConverter.GetBytes(inValue);
            Array.Reverse(byteArray);
            return BitConverter.ToUInt32(byteArray,0);
        }
    }
}

But this method is slower than just using a bitshift.

//
//
using System;

//
//
namespace Midi
{
    class Endian
    {
        //
        //
        public static UInt16 SwapUInt16( UInt16 inValue )
        {
            return (UInt16)( ((inValue & 0xff00) >> 8) |
                             ((inValue & 0x00ff) << 8) );
        }

        //
        //
        public static UInt32 SwapUInt32( UInt32 inValue )
        {
            return (UInt32)( ((inValue & 0xff000000) >> 24) |
                             ((inValue & 0x00ff0000) >> 8) |
                             ((inValue & 0x0000ff00) << 8) |
                             ((inValue & 0x000000ff) << 24) );
        }
    }
}

Since any the there are only 16 bit and 32 bit numbers in the Midi file format, and anything larger is of Variable Length Quantity, these are the only two required.