Category Archives: C#

C# development, including converting C++ code to C# code.

Compile Errors Defeated!

There are now no more compile errors.  It took just under 5 months to fix 75,000+ errors, giving me a fix rate of 15,000 per month (500 a day).  Not bad for something I only worked on in my spare time on a “as I feel like it” basis.

After the compile errors were squashed, there were 922 warnings.  It’s a bad idea to ignore warnings because there’s a pretty good chance they’ll just end up as runtime errors.  I went through and squished as many as I could as fast as I could, and the warning total is down to 28.  Those are (mostly) harmless.

Now begins stage 3:  Getting the game to run without errors.

This might be pretty involved, since I wasn’t able to test any of my rewritten code thanks to all those compile errors.  Right now I’m hammering out the glitches in the new network code (and I’ve already fixed a few).

Stage 4: Once I have the codebase in a runnable state I’ll have to convert over all of the area and data files.  You know how I converted everything to save and load XML files?  Well, the old areas aren’t XML yet.  I’ll have to write a converter application to do this.

Stage 5: Debug the whole thing.  Stage 3 debugging is easy since the game doesn’t *DO* anything without areas, mobs, and equipment loaded.  Stage 5 is where every command has to be tested, and it’ll be pretty involved.  This might be where it makes sense to set up a test server so other people can play around with it and help find problems.

Down to Only Six!

I’ve been working on the code the whole day.  The compile error count is now down to 6.

The trouble is that each of these six remaining errors will be extremely painful to fix.

< 300

The compile error count is now 297, with gains mainly due to date and time function rewrites.

Even though there were a lot of changes involved in the conversion, dealing with a System.TimeSpan and a System.DateTime is far more pleasant than the ugly and annoying integer math involved in C-style dates.  To get the number of hours that have passed with a C date, you have to do something like:

hours = time / (60 * 60 * 24); // assuming time is an integer time value in seconds.

With a System.DateTime you just do:

hours = time.TotalHours(); // assuming time is a TimeSpan.

I’d much rather deal with a class that has built-in date and time conversion logic — I hate manually converting, even if seconds-per-minute, minutes-per-hour, and hours-per day are well-known constants.

Under 500

The compile error count is now down to 486.

Most of the network communications code has been rewritten.  TCP/IP programming in C# is much like it is in C, but WAAAAY smoother — none of those ridiculous sizeof(sockaddr_in) parameters, etc.

Today’s Code

Most of today’s coding involved rewriting string functions.

The error count is now down to 834, with every gain a battle.

Under 1,000

I spent pretty much the whole day working on the codebase.  Every error clobbered is becoming a pretty hard-fought battle.  Even so, I seem to be winning.  Of course, after the errors are done, that doesn’t mean the work is over — far from it.

The error count is now down to 949.

.Net XML Serialization

Most of the saving and loading of MUD data in Basterne 2 was handled by low-level C functions that used a custom text file format for each data type. That is just a bad idea.

Save and load functions were typically dozens or hundreds of lines of code with lots of room for error and data loss. If a word was off by one space or a character was miscapitalized, a file load would fail and nothing could be done. Players of Basternae 2 probably remember pfile corruption issues with anything but fondness.

Every time we changed a file format by adding another value to an object, we had to build a translator that would convert the old file to the new version. Usually this wasn’t too hard, but it did result in a LOT of extra code lying around where it didn’t belong.

.Net makes this a lot better by giving us XML serialization.

With XML serialization, data is dumped out in a neat little XML file that can be read not only by our MUD server, but by just about anything that can read XML, which these days is just about every application in existence. Gone are the days of low-level custom file formats and painful data corruption issues (I hope).

So, how do we do it?

For example, I just rewrote the saving and loading of fraglists to use XML serialization. The code started as 174 lines of custom textfile saving and loading with lots of recursive looping to save and read the arrays containing numbers on the frag list by race and class.

Now the code looks like:

public void Load()
{
XmlSerializer serializer = new XmlSerializer( this.GetType() );
Stream stream = new FileStream( Database.SYSTEM_DIR + Database.FRAG_FILE, FileMode.Open,
FileAccess.Read, FileShare.None );
fraglist = (frag_data)serializer.Deserialize(stream);
stream.Close();
}

public void Save()
{
XmlSerializer serializer = new XmlSerializer( this.GetType() );
Stream stream = new FileStream( Database.SYSTEM_DIR + Database.FRAG_FILE, FileMode.Create,
FileAccess.Write, FileShare.None );
serializer.Serialize( stream, this );
stream.Close();
}

Cleaner and better, just the way we like it. I still hate the way WordPress formats source code.

The compile error count is now down to 1,649.

Under 2,000

The compile error count is now down to 1,900. It feels like there will be a running codebase relatively soon.

Shiny New Logs

Today I replaced the old-school C-style logging routines with new C# code based on the System.Diagnostics.TraceListener class.  That may not mean much to you, but trust me — logging is way better now.

The compile error count is now down to 2,205.

Random Numbers

I finally got around to replacing the old outmoded random number generator that the MUD has been using for ages. It’s the Mitchell-Moore algorithm and is present in just about every free codebase.

I ended up building a class that lets you select one of three random number generators to run the MUD engine on.

The first is the plain-old slow, ineffecient, and repetitive .NET random number generator.

The second is the R250/521 shift-register sequence generator. There’s a paper on it here:
http://www.informs-cs.org/wsc97papers/0127.PDF

The third is the Mersenne Twister, a fairly new algorithm by Matsumora and Nishimura. More information is available here:
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html

The neat thing about how I’ve set up the random number system is that new algorithms can be dropped in easily. I’m sure there won’t be much cause to change random number generators, but it’s a pretty easy option if we feel like it.

We’re now down to 2,591 compiler errors.

More Progress

The compile error count is now down to 2,654.

I’ve also added a codebase section to FindMUD since it seems that codebase downloads are getting harder and harder to track down these days.  There are only a handful posted, but I expect that the list will grow as the site evolves.

Under 3,000

The compile error count is now down to 2,779.

Some of the remaining code rewrites remaining are pretty significant:

  • Telnet/Network Code.
  • Data File Saving/Loading (I’m seriously considering rewriting data storage as database-based rather than XML-based).
  • Low-level string processing routines.

If you think about it, those three things are all you need to build a MUD (well, that and a command interpreter). Even though progress has been good lately, there are a couple whole-weekend projects coming up. With me house shopping and the holiday season creeping up I couldn’t possibly imagine having a running server before the new year.

A Pretty Good Chunk

Compile errors are now down to 3,293.

It feels a little strange to re-implement some of the core C-language character functions in C#.  Things like isdigit(), isspace(), and isalpha() are easy enough to rewrite, but there’s just something a little surreal about it.