The compiler tells me:
“You have just passed the halfway point in the journey toward your next codebase.”
Errors are now quite a bit less thant the halfway mark (which would be 37,571).
We now have 35, 542 errors to resolve. We’re making pretty good progress so far.
We’re down to 39,610 errors now. Even though that’s a stunningly huge amount, it’s still progress.
My brain’s starting to hurt, I should probably work on a different project for a few days.
We’re down to 44,773 errors. That’s 12,486 fixed for today.
Visual Studio 2005 has become noticeably more responsive. It’s still a little slow and clunky, but each error corrected is a slight speed increase.
17,883 errors squashed.
I doubt I will break that record anytime soon. I deserve a cookie. Too bad I don’t have any.
Yesterday I mentioned that I had 75,142 second-pass compile errors in the codebase. That’s a lot no matter how you describe it.
Aside from spending a couple hours reading Heinlein’s Revolt in 2100, all I’ve really done today is hammer away at the code trying to reduce that number. This has been a little slow because Visual Studio 2005 slows down A LOT when it has to store tens of thousands of error messages in memory and check every change you make to code against those errors to see whether it can remove them from the error list.
I really like intellisense and realtime error checking, but not when it pretty much causes the IDE to grind to a halt. As the number of errors decreases, VS is gradually becoming more responsive, but it’s still too much of a mess to be a very pleasant editing experience.
So, the number of errors is now 58,264. That’s still a ton, but I’ve now set a new personal record of fixing 16,878 compile errors in a single day. My previous record was about 8500, basically due to some weird recursive STL/templating issues with a C++ app I was writing a year or two ago.
Even better, the day’s still not completely over yet, so I could probably add a few more to that total.
Seriously.
I cleared up all the first-pass compiler errors (the remaining 1,447). It was tedious, but not too terrible. That means that the compiler made it to the second pass.
It churned away for a while, and then gave me a “build failed message”, which I expected. It then proceeded to show me every last little error that it could find.
There were seventy five thousand one hundred and forty-two errors.
After displaying that many errors, Visual Studio 2005 promptly crashed in a horrible flaming fireball of death.
There are only 116,000 lines of code in the whole codebase. That means two-thirds of the code is broken. Nice, eh? I wonder how long it will take me to fix 75k errors…
That’s a good thing. Down from 7,899 errors. Everything that could be fixed via search-and-replace (about 5,000 errors) has been, and the rest (about 1,400) have been edited by hand. There’s still a lot more work to do in stage 2, but the number of compile errors is steadily decreasing. Soon we will have a C# version.
Stage 1 is done.
Q: What is stage one?
A: Hammering the code into C# syntax so that Visual Studio gives no complaint before trying to compile to code.
Q: What’s that involve?
A: Placing all of the functions into classes, eliminating all global variables, converting #define statements into variables (in the case of constants) or class methods (in the case of macros), changing all char[x] variable declarations to strings, rephrasing all array declaration and initialization, and removing stray const keywords.
Q: How many changes did you have to make?
A: I had to change about 4,000 lines of code, mostly by hand. I love search-and-replace, but it couldn’t do much here.
Q: Did you completely break the heck out of anything in the process.
A: ABSOLUTELY! I know for a fact that I will have to completely rewrite mob tracking (which has always been one of the things I intended to do anyhow). Some of the changes to correct syntax also just pushed the errors later in the process — they won’t show up in a syntax check and will instead show up in a compile.
Q: What are the other 4 stages of this conversion?
2 = Compiling without errors. This is a huge step. After just running the first initial build, there were 7,899 compile errors. A large percentage of these will be pointer errors because I didn’t change any pointer-based code (”Pointers and fixed size buffers may only be used in an unsafe context.”)
3 = Building an executable. This may be moderately complex, but since C# pushes so much of the work onto the syntax checker and compiler, chances are that if it compiles without errors then the program will build and run.
4 = Booting without immediate crashes. This will involve firing up the debugger and making sure that all of the changes didn’t have any unintended consequences. They will, errors are unavoidable in a rewrite of this magnitude. Hopefully debugging will be fairly quick.
5 = Logging a character in and walking around without crashes. Most of the code lies dormant until a player is logged in. This includes things like network code, combat routines, hit/mana/move regen, informational screens, skills, etc.
Completing all of this will get us ready to put up an alpha port of the game so that we can actively start building content.
Over the past few days I’ve spent a while working on rewriting the Basternae source code in C# (even though the original code is not completely object-oriented yet). Ideally I’d like to have it run as a standalone application linked to a SQL server for data storage. This is doable in C++, but in C# it’s far easier.
I still have the C++ version, but after some experimentation it looks like I’m going to stick with the idea of migrating to C#. It’s been my favorite language lately, and it offers a bit more power than C++ does. What better way to fully master a language than port a 115k-line project to it? I will still have the old code to fall back on, but I hope to have the new code working in less than a month (which is the timeframe I had planned for the original string conversion anyway).
For now I’m pretty sure that I’m going to stick to C++ for the client, especially since it’s already written and just needs some slight modifications to work with the new engine and to work with Linux (ideally it will be able to run on Linux, Windows, and MacOS, but I have no access to MacOS so that’s a “maybe eventually” thing) .
As a techie I usually focus on the tech stuff first, but sometime soonish I’ll probably be posting about the gameplay changes I have in mind.
Or more like, “getting owned by globals”.
As part of the conversion to C++ one of the major tasks is moving all of the global functions into classes. There are a lot of them - each spell, command, skill, bard song, et cetera has been handled by a global in the past. Even with all that’s been moved, I still count 1,467 global functions that need to be moved into classes. This is down from about 2,000 when I started.
Some of this is easy. It’s obvious that a get_object_weight function belongs to the object classs and an initialize_mob function belongs to the mobile class. Other things might not be so easy, like functions that belong to both characters and objects like give_object_to_char. It could just as easily belong to either one. It’s not a big deal if I just make an arbitrary decision and stick it somewhere, but it is something that I have to think about.