Compiling Issues MSVC 2013 Express

[caribes]

The compile guide and some forum thread was giving me an orientation what to do. But the information seems to be out of date.

What I did so far:
* Installing Visual Studio 2013 Express
* Using VS2013 git to clone WZ2100 repository from https://github.com/Warzone2100/warzone2100.git
* Using branch: master
* Open win32/Warzone2100.sln
* Compiling ... a lot of missing header! What a hell?

I was reading compile guide in detail, and some forum threads ...

Then I added some of the required libraries:
* Installing Qt 5.3.2, and assiged environment variable $(Qt5dir)
* copied devpkg to lib directory (from devpkg-trunk-msvc2010-20102705.rar, but i don't know if the binaries are compatible wit VS2013)
* Compiling ... much headers now available but still missing GL/glew.h and some others

Then:
* Installed GLEW from http://glew.sourceforge.net/ (version 1.9.0 supporting OpenGL 4.3, as I have seen code is using macros for OpenGL 4.3)

And now, I am wondering how the the VS2013 solution and projects is including GLEW environment.
I didn't find any configuration regarding GLEW. So what is the answer to this problem?
* the configuration is missing, it must be added ???
* there is somehow a tricky thing I didn't get ???
-> I have added settings for GLEW, then it worked.

There are some more issues to deal with to get the solution compiled:
* missing 'SDL.h' in \lib\sdl\scrap.cpp, project SDL
* missing 'SDL_mouse.h' in \lib\sdl\cursors_sdl.h, project SDL
* missing 'physfs.h' in \lib\gamelib\anim.h project Warzone2100
-> I modified the include path then it worked.

Additional issues:
* missing 'glm/glm.hpp' in \lib\ivis_opengl\piematrix.cpp, project ivis_opengl
* missing 'openssl/sha.h' in \lib\framework\crc.cpp, project framework
-> Atm. I don't have glue how to deal with this.

Can someone give me some hints?
Has someone ever been able to build the code of wz2100 with VS2013, e.g. Debug/win32 ??
Should I switch to an other branch ??

[vexed]

That dev package will most likely not work at all. It is way too old, and made with another version of the compiler. About the only thing you need from that is etc & fonts stuff.

viewtopic.php?f=32&t=11789#p128801
Assuming you got all the libs required, http://developer.wz2100.net/wiki/CompileGuideLinux (Qt 5, and all the other stuff it shows)
All headers should be in the include folder in the directory called devpkg, which is located at the base directory. (you will see all the other WZ directories there as well, src, lib, and so on)
All libs that you compiled from those packages should be in devpkg/libsx86

So, seems you didn't just get all the required libs, and install them where it expects them to be installed.
You shouldn't have to mess with the solution file at all.

[caribes]

hi vexed, thanks for your reply.

But I don't have a linux environment. So I can't do the steps described in the linux compile guide.

Is there a way to get the required dev packages with windows?
I am puzzeling over which versions of the packages are required.

[Ezio]

hi vexed, thanks for your reply.

But I don't have a linux environment. So I can't do the steps described in the linux compile guide.

Is there a way to get the required dev packages with windows?
I am puzzeling over which versions of the packages are required.

'http://developer.wz2100.net/ticket/2783'
this one from 2010 most dll and libs were same but version. you just need qt5, glew, and some lib from xiph.

[vexed]

hi vexed, thanks for your reply.

But I don't have a linux environment. So I can't do the steps described in the linux compile guide.

Is there a way to get the required dev packages with windows?
I am puzzeling over which versions of the packages are required.

I didn't mean for you to install linux or anything, I just meant that you can look at the libs listed, and then download each package that you need.
libtheora would be theora, libogg would be ogg, libopenal would be openAL soft, libcrypto would be openssl's crypto lib, libpng is just the latest version of the png library, and so on.

I would get the latest version of every library (they usually contain bug fixes), we don't require specific versions of them, except for Qt, that must be 5.x and higher and SDL must be 1.2.x as well, we don't officially support SDL 2 at this time.
We don't use/need bison & flex anymore either, so don't bother with them.

[caribes]

Thanks for the information.

I will have a look into getting all these packages and bind them to a devpck. I guess this will be take some days to get it done. Propably I'll come back and offer to write a guide for this.

[caribes]

Now, I have got all the header been required in the devpkg/include directory.
Even there never was dropped a word about GLM. (missing 'glm/glm.hpp')

You shouldn't have to mess with the solution file at all.

So I didn't touch the solution file.

But what is about this issues:
undeclared identifiers in project Warzone2100
VCS_BRANCH
VCS_TAG
VCS_EXTRA
FOCUS_IN
RAND_add
OPEN_SSL_all_alghorithms_noconf
RAND_screen

What is missing now ?

[vexed]

Well, the wiki is out of date... so, no big shock that it is missing things.

As for your issue, if you look at your build log, there should be a error stating it couldn't find a program. (not a compile error) so, edit where\you\installed\warzone2100\build_tools\autorevision.bat and point it to the location you have msysgit installed.
You also need perl to convert linefeed correctly.

That should fix the above.

[caribes]

Hi vexed, the hint regarding autorevision helped. I've got everthing compiled now.

Even linking has been completed. This took a while. But Starting WZ has some issues regarding required DLLs. ATM it blocks due QT, because it can't find a windows platform plugin. I have not properly installed QT on my system, only using includes and libs atm. But I'm wondering about the usage of Qt. Does every user need to install Qt in the future?

I would prefer the approach to have everthing statically linked into the wz2100.exe as it has been done with v3.1.1. May be adding build targets for this at the projects. From my point of view the advantage is, there is no additional precondition required, because everthin is inside wz2100.exe. What is your opinion at this point ?

I am trying to get everthing linked as static library. Atm. I try to work out how build the static library for Qt stuff.

I want to have a debug version of WZ, which can be debugged remotely. So I can attach VS2013 debugger to the WZ process on the game computer. This can be make life much more easier for bug hunting.

Is there a demand to have an updated devpkg for win32, e.g. release and debug with sources?

[vexed]

Hi vexed, the hint regarding autorevision helped. I've got everthing compiled now.

Even linking has been completed. This took a while. But Starting WZ has some issues regarding required DLLs. ATM it blocks due QT, because it can't find a windows platform plugin. I have not properly installed QT on my system, only using includes and libs atm. But I'm wondering about the usage of Qt. Does every user need to install Qt in the future?

Well, Qt is looking for the plugin in data\platform, just move the .dll there.
Yes, Qt is required, since we use it for some parts of the code, just nothing to do with screen/GUI or I/O. (well, by default, we use SDL, but, there is a Qt backend as well.)
It is used for Scripts & we also use Qstring, and some other classes.

I would prefer the approach to have everthing statically linked into the wz2100.exe as it has been done with v3.1.1. May be adding build targets for this at the projects. From my point of view the advantage is, there is no additional precondition required, because everthin is inside wz2100.exe. What is your opinion at this point ?

Sure, it is possible to have static builds built by MSVC, however, you need to jump through lots of hoops.
If you look at commit be75778, to see what to link to, and fix the CC #ifdefs to allow it for MSVC as well, then, yeah, it is doable. You got to be really careful building all the other libs, to make sure you don't have zlib in any other lib or you will get conflicts at the linker stage. Not 100% sure about QuesoGLC though, that might be a bit harder to accomplish.
I should also point out that, builds made by MSVC are *not* compatible with builds that are made with the cross-compiler. What I mean by that is, you will get sync errors in MP games. I haven't had time to narrow down the root cause of this though.
So, yes, MSVC is fantastic for debugging, but, not for distribution purposes at this time.

I am trying to get everthing linked as static library. Atm. I try to work out how build the static library for Qt stuff.

I want to have a debug version of WZ, which can be debugged remotely. So I can attach VS2013 debugger to the WZ process on the game computer. This can be make life much more easier for bug hunting.

Is there a demand to have an updated devpkg for win32, e.g. release and debug with sources?

You can run WZ within the IDE right now, and you do get full debugger support. I use MSVC for 99.9% of all the bug fixes I do.
You can also attach it remotely, but, you don't need it to be a static build for that.

As for demand for the dev package, well, only a few people have requested something like that be made available.
The only issue about having stuff made that is outside the project is the possibility of code injection / modification for the dlls/libs.
Getting files from official sources (like Qt's pre-built stuff for VS2013) is more safe, where you at least have hashes of what the file(s) should be, and while I highly doubt that your intention is mischievous, there is always that possibility that someone might come along and do that.
This is why I always recommend that people download the sources themselves, and compile everything. That way, they can be sure that nothing has been modified.

[caribes]

Well, Qt is looking for the plugin in data\platform, just move the .dll there.
Yes, Qt is required, since we use it for some parts of the code, just nothing to do with screen/GUI or I/O. (well, by default, we use SDL, but, there is a Qt backend as well.)
It is used for Scripts & we also use Qstring, and some other classes.

I think it was the right decision to make use of Qt, due it supports multiple platforms. Is the use of QtScript the reason why there is not required flex and bison any more ?

Sure, it is possible to have static builds built by MSVC, however, you need to jump through lots of hoops.
If you look at commit be75778, to see what to link to, and fix the CC #ifdefs to allow it for MSVC as well, then, yeah, it is doable. You got to be really careful building all the other libs, to make sure you don't have zlib in any other lib or you will get conflicts at the linker stage. Not 100% sure about QuesoGLC though, that might be a bit harder to accomplish.
I should also point out that, builds made by MSVC are *not* compatible with builds that are made with the cross-compiler. What I mean by that is, you will get sync errors in MP games. I haven't had time to narrow down the root cause of this though.
So, yes, MSVC is fantastic for debugging, but, not for distribution purposes at this time.

I already made the static libraries except for Qt and SDL. And yes, it was a lot of work to do for that. QuesoGLC with freetype, fontconfig and zlib has been a challenge. I was forced to have a look into every part of the packages, and to deal with topics driving me mad. And with static lib there comes in additonal dependencies to "expat" and "dirent" to be linked for WZ. What I have learned is, each of the DLLs internally use their own version of e.g. zlib. Qt and QuesoGLC are dealing with own versions and options of freetype and fontconfig. I seriously expecting compatibility issues, especially between different platforms. At the end, every of the libraries should be same version for all platforms, and handled by exactly the same build steps, static as well as shared libraries, to have chance to narrow down MP bugs.

Without MP the game is useless for me. SP can only be used as tutorial, as it is.

As for demand for the dev package, well, only a few people have requested something like that be made available.
The only issue about having stuff made that is outside the project is the possibility of code injection / modification for the dlls/libs.
Getting files from official sources (like Qt's pre-built stuff for VS2013) is more safe, where you at least have hashes of what the file(s) should be, and while I highly doubt that your intention is mischievous, there is always that possibility that someone might come along and do that.
This is why I always recommend that people download the sources themselves, and compile everything. That way, they can be sure that nothing has been modified.

Well, I got your point. But the WZ project even can provide a hash and a description how to build the libraries to match the hash.

Regarding the libraries for WZ, there is a hell of versions, combined with a hell of options to build the stuff, combined with a hell of platforms, combined with the number of libraries, combined with the number of toolchains. This way you have a five dimensional space of different runtime versions. But exactly one version for each platform should be the reference runtime. I am pretty sure, that the chance to get something not modified at source side is assured, but not resulting in compatible runtime setting is even a high chance. And how to reproduce a specified bug with an unspecified composition of binaries? This sounds to me like a high dynamic source of problems. I expect ppl spending the rest of their life hunting down ghost issues in their own world of libs. Ok someone is happy with that, like Don Quixote tilting at windmills.

I see it by myself, I was looking since years to get into the source of WZ, but the effort to build the project has always been a pain in the ass. Again, I try this since many weeks now, but I never have seen running an own build of WZ on my machine so far. The build looks to me very chaotic. I am not sure that I be able to remember every of the steps I have already done. If someone is supporting a single library he don't has the many sideeffects to deal with. But a complex project like WZ with many dependencies will eat up the motivation of most ppl to participate within the early steps of building the project.

I am assuming that skilled developers investing time to improve the game are welcome from the project side. At this point I could run into the idea, that the project could offer a devpkg for all platforms, out of the box, so building the WZ runtime is not the showstopper to get into the work?

The use of tools like CMake or MPC would make life easier.

[caribes]

But Starting WZ has some issues regarding required DLLs. ATM it blocks due QT, because it can't find a windows platform plugin. I have not properly installed QT on my system, only using includes and libs atm.

Well, Qt is looking for the plugin in data\platform, just move the .dll there.

I copied the complete folder "platforms" of Qt to the directory where the wz2100.exe is. Now WZ2100 is starting, there appears a window frame for 2 seconds, and then it just quits without any response.

The stderr.txt contains this:

Code: Select all

info    |07:56:45: [realmain:1123] Using C:\Users\Sisyphus\Documents\Warzone 2100 master\logs\WZlog-1201_075645.txt debug file
info    |07:56:46: [pal_Init:51] Buffer overrun reading palette data
info    |07:56:46: [pal_Init:51] Assert in Warzone: piepalette.cpp:51 (lenLeft >= 0), last script event: ''
info    |07:56:46: [pal_Init:51] Buffer overrun reading palette data
info    |07:56:46: [pal_Init:51] Assert in Warzone: piepalette.cpp:51 (lenLeft >= 0), last script event: ''
info    |07:56:46: [pal_Init:51] Buffer overrun reading palette data
info    |07:56:46: [pal_Init:51] Assert in Warzone: piepalette.cpp:51 (lenLeft >= 0), last script event: ''
info    |07:56:46: [pal_Init:51] Buffer overrun reading palette data
info    |07:56:46: [pal_Init:51] Assert in Warzone: piepalette.cpp:51 (lenLeft >= 0), last script event: ''
info    |07:56:46: [pal_Init:51] Buffer overrun reading palette data
info    |07:56:46: [pal_Init:51] Assert in Warzone: piepalette.cpp:51 (lenLeft >= 0), last script event: ''
info    |07:56:46: [pal_Init:51] Buffer overrun reading palette data
info    |07:56:46: [pal_Init:51] Assert in Warzone: piepalette.cpp:51 (lenLeft >= 0), last script event: ''
info    |07:56:46: [pal_Init:51] Buffer overrun reading palette data
info    |07:56:46: [pal_Init:51] Assert in Warzone: piepalette.cpp:51 (lenLeft >= 0), last script event: ''
AL lib: (EE) ALCmmdevPlayback_open: Device init failed: 0x80004005

[Per]

Are you trying to use some mod or old data files? It is complaining that the palette.txt file it is reading is too short (ie too old).

[stiv]

I think it was the right decision to make use of Qt, due it supports multiple platforms.

Qt might be a good choice for multi-platform business apps, but it does not do well with OpenGL games like Warzone. We did the experiment ( a good thing, IMHO) and the answer was no.

The bits of Qt you see laying around are the remnants of that. However, some of them like QtScript seem problematic. There is another thread discussing that.

[stiv]

The use of tools like CMake or MPC would make life easier.

We are currently using GNU automake - affectionately known as autohell. Changing build systems will not free you from installing the necessary libraries and headers.