A Special Kind of Hell

I've spent the majority of today attempting to get Synergy to compile.

Basically, as far as I can tell, after I formatted my computer some time ago and reinstalled MSVC++ 2008, reinstated all the libraries that Synergy uses (Allegro, AllegroGL & SOIL), at some stage something went wrong.

I loaded up the .sln file, and hit Build, and I was confronted with one of the strangest errors I've seen in a while: something about an inline assembly code error, expected an opcode and found a data type, or something bizarre like that.

I started to systematically compile each individual .cpp file, and found that all of them except 1 compiled just fine. The troublemaker that caused the problem was gam_Entity.cpp, which is weird because that's a very simple source file, with very few dependencies and very straight-forward class-definition-style code.

So I kind of fiddled around in that file, commenting out sections of code and recompiling, trying to find a particular line that spouted the error, and I found that no line caused it, since I ended up commenting out the entire .cpp and .h files! By this point I was just downright flabbergasted, and I turned to google for help.

I found a couple of pages that mainly went through fiddling with project properties, cleaning out .obj itermediary files, that sort of thing. But none of those seemed to fix it. So then I started thinking maybe it was something about where Allegro was being included, so I started including allegro.h and alleggl.h at different points in the header file, commenting out includes, trying #include instead of #include "allegro.h", random trial and error things like that.

I don't remember exactly at what point it worked, but somewhere it worked. As far as I can tell, no one thing that I did fixed it, it just seemed to `come good', which is troubling.

Anyway, after that assembly error stopped coming up, I had a new set of errors coming up; a tonne of link errors. Welcome to the next nightmare. This was basically about 180 LNK2001 errors saying various identifiers had already been included in .obj files. I did more scanning of the net and went a little crazy, and then I realised I had actually gone through all the functions in m_common.h and removed the inline from the beginning of each non-template function definition in an attempt to fix the previous problem. Dur. So I replaced the inlines and bam! No more link errors.

But then I got a single error; something about P1 and P2 being different versions. Scanning the net more, I found out this relates to the compiler having incosistent versions of itself, or that libraries that I'm using have been compiled with different version compilers, something quite likely. So then I kind of started losing my mind, and tried bringing in different versions of each library to MSVC++ 8.0, downloading and installing MSVC++ 9.0 and installing the libraries for that, and even going back to MSVC++ 6.0 and trying there.

What I ended up with was uninstalling 8.0 sort of out of some irrational belief that it would help to quell the curse upon my computer, but also (more rationally) that I should try reinstalling it at some point and carefully version checking each library I bring into it.

MSVC++ 9.0 overcame the P1 != P2 error, but now SOIL.lib was spouting a couple of link errors to unresolved external symbols __alloca() and something else. So now I'm quite lost. My guess is some version inconsistency between the 9.0 compiler and the compiler that SOIL was written for, ie SOIL only compiles on 8.0 or earlier, or something like that. That's something I mean to test when I reinstall 8.0.

I then tried to comment out the SOIL code and I was left with a single link error about MSVCRT not being able to locate _main. So I followed some instructions on a website to fiddle with the MFC settings in the project settings, which just spawned more errors so I reverted back to EXACTLY how the settings were, and now I have 7 errors. It's absolute madness!

MSVC++ 6.0 finally managed to compile and execute an older version of the code once I commented out all reference to SOIL. This is basically the best result that I've achieved. At this point I'm looking at bringing in all the code that I've written since this old version, getting it to function, and then (hopefully!) compile and run. At that point I'll be back to where I was, except in 6.0 instead of 8.0, to which I say good riddance. This might also be a good time to rid myself of AllegroGL for good. One lesson I take from this is `the less dependencies, the better'.

So there it is, my special kind of hell. To be honest, this should never have happened. Part of the function of this blog is to act as an engineering journal, where I can record version changes and things I do to my projects which might end up leading to something like this current scenario in the future. I should have had logged which version all of my libraries, IDE and compiler were and the directory of my last known successful build of Synergy.

I won't make the same mistake again.

--------------------------------------------------

Synergy Version: 0.0.0
IDE Version: MSVC++ 6.0
Allegro Version: 4.2.2
AllegroGL Version: 0.4.2
SOIL Version: 2008/07/07

Current Status:

• Compiling & Executing
• SOIL producing two LNK2001 errors; all SOIL references have been commented out
• Thus, textures currently not loading
• Old demo version; multiple smoothed 3D objects floating in space

To Do:

• Eliminate all AllegroGL dependency
• Fix texture loading
• Implement multicore functionality
  
• Reintegrate following features:

1. multiple material meshes
2. the `Big Room' demo
3. lightmaps
4. unified lighting attenuation system

• Implement uniform lightmap patching system
• Implement physics library integration

Multi Yodel Scope

So, I've been on holidays for two months or so, and have been partaking in eclectic activities. Most of these are not significant to the focus of this blog, however I have managed to glean some constructive work from this time.

First up, I've given some attention to restructuring Synergy to support multicore processing. I had the design goals to allow the engine to scale with cores at run time, to have next to zero locking mechanisms in the code, and to have the multicore functionality as transparent as possible.

What I ended up with is largely a combination of two materials I read. The first is an introductory article to writing multicore games for the Xbox 360, which gives a good overall breakdown of an engine's structure into parallel processes. The second is Valve Corporation's presentation on Source Engine's multicore concepts.

Taking these two together, I basically have two `Delegator' threads that run through the structure outlined in the 360 article as 2 parallel processes. Every significant independently executable function within those threads is called with a function wrapper task(), which takes a pointer to the function to be run, and up to four parameters caste to void type. The task() function takes the information passed to it and builds a linked list with it, and then pushes that linked list onto a lock-less task queue.

All the while this is happening, there is a thread pool with some number of threads all executing a peon() function. As the name might suggest, peon functions continually check the task queue for a task, and if they can grab it they do so, break the linked list up into a function call, and then execute the function representing the task to be done. Upon completing the function, the thread returns to its peon() function to continue checking for more work to do. As you might guess, the number of peon threads in operation is related to how many CPU cores are visible to the engine. The more cores available, the more peons can be running.

Within all of this is a simple semaphore system whereby a task in the queue can be associated with a semaphore. This allows the delegator threads to wait until a certain cluster of tasks in the queue are completed before adding more tasks. This is a necessary evil simply due to the serialised structure of games themselves, and at the moment is the most logical solution I can think of. This is, in fact, a locking mechanism, but it's only operating when the actual logic of the program cannot proceed until the current tasks are completed, and it should minimise any kind of thrashing, since the peon threads never rely on the semaphores.

So that's Synergy's multicore structure at the moment. Nothing too sophisticated, and still yet to actually be tested! But at least in theory it meets all of my design goals for the moment.

Next up in my projects is a Team Fortress 2 map! I've been itching to do some mapping for a while, but struggled to settle upon a good idea until I was reading over the Valve Developer Community Team Fortress 2 pages, and there was an article about Circular Control Point map types. This is a game mode currently not implemented in any official map, but has the potential to be an extremely dynamic game type if implemented appropriately.

After reading about it, I had a rapid explosion of ideas for a map, and begun to sketch out every area in photoshop, paying careful attention to attack/defend dynamics, flanks, killzones and setup areas. As well as the obvious considerations for each class.

After about a day I had the whole map sketched out and detailed with all major routes, spawns, setup areas, rocket jump access, etc, and began to actually rough the map out in Hammer. As of writing this I have the entire map roughed out in seperate map files and am currently bringing them all together and playing a juggling act to get them to all fit together. Some points have considerably larger areas than others, and so alot of scale harmonising needs to be done, which is a little tedious.

I'm hoping to have a tight, playable alpha of the map ready by the next tf2mappers.net game day, so it can have some testing done by fellow mappers. Anyway, though it's hardly eye-candy material at this point, here's some screen shots:

Battle area below D

Attacker's far staging area at C

Primary indoor contesting area of C

Oh and here's some random sketch I half-finished up the other day:

What if the mountain defeats you?