Compiling Issues MSVC 2013 Express

[vexed]

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 ?

Basically, yes.

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.

Pretty much all MP bugs are the same in SP/skirmish.
The only thing that is MP specific is the net code, and I am unaware of any bugs from that at this moment.

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.

Which was in the wiki at one point, (well, how to build stuff), but, as you can see, it is out of date, and nobody has had the time to fix anything on the wiki, and people didn't contribute anything either.
Don't know if it was mentioned or not, but, we don't have any full time people here, we all have real jobs, and contribute to this project as time permits.

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.

For the external libraries themselves, there really is only 1 version that we ever use, and that is the latest that upstream offers, unless there is an issue. (Like with the latest version of GLEW) That is the only time we downgrade to the last known working library.
We just list the libs we use in the wiki, and the package manager gets them.
(The only good news on that front is with windows 10, they will have a package manager as well.)

There is no way for the linux guys to build windows builds without the help of the cross-compiler, and in linux land, it is far, far easier to get everything up to speed static wise.

Pretty much all bugs are cross-platform, no matter what binary you use, and the only platform specific bugs are in the base "setup" code, of SDL (or Qt), so, we are pretty much immune from having them in the regular code base.

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.

Without feedback, and people to help update documentation, things get done very slowly, because of lack of time.

As long as you are not making static builds for windows (MSVC), then, things aren't that bad, and are about as complex as any other project that uses external libs.
This still holds true for any platform you are coding for. Android, Windows, Apple, linux, they all require you to get the libs and compile them, and some of them are geared toward developers (linux) so, it is easier to get stuff via doing apt-get install lib_name-dev as shown in the wiki.

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?

Yes, we are always looking for skilled people (be it developers, artists, web design or anything else).
As for devpkg for all platforms, that isn't really needed for linux & mac, only MSVC people, and as was stated, I just don't have the time to put up a package of what is needed, and keep it updated.
The reason I don't offer my "devpkg" is, I have way too many libs in that for multiple versions of WZ and also proprietary stuff in it. It is over 3.6GB now, and over 7 years old.

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

Actually tried before (more than 3 times), but, nobody has succeeded in making a working CMake project file that works for all platforms we support.
I really doubt that would make it any easier though, since you still must download everything that is needed.

The only real difference is, there is less upkeep, since, we would all be using the master CMake file when people add/change things.
Never heard/tried of MPC.

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

As Per stated, this looks like a mod or something tried to load or something.
As for the crash itself, can't tell by looking at the logs, would need you to run the game under MSVC's debugger, and then post a stack dump so I can see where it is crashing.