What platform would you run Quetoo on if it was on Steam?:

Windows Build Instructions

March 11, 2009 - 00:22am

I was wondering if the resident Windows maintainer (maci?) could give a quick rundown of how to build. I poked around a bit, but some of the stuff looks rather specialized (e.g. the uploading stuff in win32.sh). I'd be interested to know how to both build on Windows and cross-compile from my Linux machine (if you have that setup).

Also, is there any interest in getting MSVC project files setup? In other projects, such as ioquake3, MSVC builds tend to run measurably faster than mingw builds.

Either way, I just need an easy way to get Window bins. My Linux machine isn't really acceptable for testing and playing around.

March 11, 2009 - 07:44am

First, if you haven't, I would install maci's win32 environment setup package. It provides msys, mingw, and some other nice-to-have's: http://maci.satgnu.net/files/q2wdevenv.exe

In the msys shell, checkout a working copy of the code. Then you basically follow the Linux instructions, with a few minor tweaks. Most notably, the game module (game.dll) has to be compiled manually with the command found in build.sh (gcc -shared -o game.dll *.o ../../libshared.a, I think). Consult the build portion of build.sh for the exact details.

Cross compiling has worked as recently as December, but when I tried it in January it was broken. I think configure.in hoses the OPENGL_CFLAGS/OPENGL_HOST_LIBS or something. I have not really looked into it.

MSVC project files would be cool, but I have no way to maintain them. So if you're interested in doing that, I can sort you out with svn access. Are you able to hop on the IRC channel? Myself, Ingar, and maci will be able to better help you with getting a build environment up and running that way.

March 15, 2009 - 01:31am

I got things compiling in MSVC, but there isn't much performance gain (about 5-10%). I suppose that's because this engine utilizes the video card better and isn't as CPU-bound as other engines. I'm not going to finish this MSVC business because the benefit doesn't outweigh the cost of finishing it up and maintaining it. However, I still wouldn't mind having SVN access or a Trac account.

March 16, 2009 - 12:36pm

Dude, I would spend weeks refactoring portions of the engine to gain 5 or 10%, lol. I'll ask maci to weigh in on the feasibility of using MSVC to produce the continuous integration build. As for Trac/svn, ping me on IRC and I'll get you sorted. If you do not have a RSA/DSA key, go ahead and create one. The developer svn uses svn+ssh://.

March 17, 2009 - 01:37am

Haha, well, it's all relative. For ioquake3, MSVC gives about a +50% performance increase, so my expectations were a little skewed ;)

I should be clear that what I did this weekend was quick and dirty. I mutilated code, the game.dll did not run, and the client was unstable. Admittedly, I don't have much experience with MSVC (*nix toolchain at work and school), so I still need to learn the ins-and-outs of it. If you're psyched about 5-10%, then I'll have another go at it and try to develop a clean solution. It might take some time though :)

As for continuous integration, I'm willing to help out with that. What is being done now? Does someone manually initiate the process frequently, or is it triggered with a post-commit hook?

March 17, 2009 - 05:29am

i used to have a build every 3 hrs but right now I trigger it manually.
that build box i had was rather unstable, but now the win32 build is almost always up to date.
actually i personally don't like the idea of using msvc, tho its not a bad thing to have project files for it because some people may wish to develop using msvc.