Successfully *building Goblin Camp

Previously…

Upon getting all the required libraries I started on resolving all the compiling errors that came with goblin camp.

Fixing boost

First things first The boost libraries that are being shipped with the code a outdated. To fix this I had to update all the boost source files which is easy enough, however we can’t just update to the latest version. long story short boost 1.6.2 is going to be what we compile wit. Anything newer will run you into a problem with the boost::python::numeric API calls as they were renamed to boost::python::numpy. Anything previous to 1.6.0 ran into compiler error I assume are a result of outdated code and version 1.6.0,1.6.1 ran into linking error for boost::system::error_category. I won’t go into further detail on other errors I encountered with boost as updating all files seemed to resolved them in one clean swoop.

Switching compilers

Even with an updated version of the boost libraries I found GCC just wouldn’t compile them. The problem this time is how boost selects it’s compile. Specifying that we want to compile with GCC will cause every file to be compiled with GCC however this causes a problem. GCC does not link the C run-time libraries automatically and boost doesn’t allow us to easily change the compile options. This causes linker errors down the line so I quickly switched compilers to MSCV-14.0. Microsoft’s visual studio compile will solve all our problems when it comes to what compiler to use.

Switching Architecture

I’m not sure if this was actually required but I noticed when compiling for 64 bit far more warning were present. Since many of the external libraries are outdated as well it seemed like a good choice to recompile for x32. This of course meant changing all external libraries to x32 as well as python.exe.

Resolving the last error

The last error I had to resolve to get the executable to build was a simple warning being treated as an error. Progress.png

I encountered a similar one when compiling the libraries. There’s generally 2 ways to solve it.

1. Compile with the compiler option /WX MSVC will ignore all warnings when compiling

2. In a visual studio solution select project->properties->C/C++->General->treat Warnings As error

However with no access to compiler options or visual studio project properties I had to find a third way. Luckily for me we can solve it programmatically as much as I don’t want to edit code from the external libraries I made an exception to see if it would move forward. Adding the code:

#pragma warning(disable: <error number>)

before any include statements in file creating the error ensures that no undesired warning will be shown when compiling.

However upon looking for the deflate.c file I noticed that it wasn’t in the specified C:\dev\libs\include\ folder. This file belong to the zlib library within it’s own \zlib folder. At first I didn’t think much of it but when trying to suppress the warning and recompiling nothing changed. In attempting to track down this error I found that it stemmed from the zlib.lib file. However this doesn’t explain why it’s pointing to a file in the wrong location.

So what was the cause? When compiling the zlib.lib library for libpng16.lib I used a shortened include path. Because of this boost was accessing a file I didn’t have access to, something I didn’t even know was possible. To solve the issue I recompiled zlib.lib with the added code to suppress the warning. Finally after 5 days and 100s of compile attempts.

Success.PNG

Boost was finally able to build the Goblin Camp executable to play and finally we can see what the game looks like…

SDL-dll-missing.PNG

Well not quit for some reason the .dll files for the SDL/SDL_Image libraries are not being moved into the folder containing the executable, No worries we have the .dll files from compiling the libraries so we can move them manually.

…and it’s closes as soon as it I attempt to launch it. Well on the bright side it builds with no errors and launches with none either, in a way I did everything I wanted.

Conclusion

As of now I’ve been able to build the executable in both debug and release build mode on x32 architecture. The same behavior happens when launching the game simply cloeses instantly. If I had to guess what the problem is I beleave it has something to do with the gc-boost-python.dll file. When the executable is being built it does say it “failed” to copy this file but it’s in the folder with the executable. It could also be the sdl/sdl_image.dll files which I have to manually move as it doesn’t seem to want to copy them when it build.

The origin Goblin Camp shipped an executable that can be downloaded. Looking at what the game is shipped with I also notice that there’s a bunch of .dll files mines missing for the external libraries. The issue may be it looking for those files but not sending any error message when it fails to find them.

Well I guess that’s it for now…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s