MSVC ?

[Duke]

I loved to play X-COM back then.

It's August 2nd in my 2.2.1 game at std level and I'm running out of things to research. I only noticed a handfull of minor bugs so far (and a lot of missing/uncompleted features, of course). So I have to say:
Great job, guys. THANK YOU very much for giving us this game

I guess the next step for me should be to dive into the 2.3 SVN version and help to fix the remaining bugs by reporting them (at least).
To do so, I need to compile SVN src. And sure enough, I'd like to use the debugger before reporting
Problem is, my favourite IDE is MSVC 6.0 SP 5. Allthough the original engine seems to have been developed with MSVC, forum search revealed that none of the devs here seems to use MSVC.
So here are my first questions:

1) Is there anybody around who uses MSVC to compile it ?

2) Are there some docs I missed about how to set up MSVC to compile it (like required switches eg. /J etc.) ?

3) Is there some architectural overview for the src ? eg. which dir contains what and how it all works together ? (I'm not talking about the calltree).

t.i.a.

[Mattn]

1) i don't think so - we are all using codeblocks and some are using eclipse (but not officially supported)
2) no, sorry. You might want to have a look at some very old branches - there are msvc project files
3) not yet, but in general:
client - everything that is only client side
common - server and client
shared - server and client and tools
server - everything that is only server side
game - the game lib (only used by the server - even in singleplayer we are using a client/server arch)
tools - ufo2map (mapcompiler) radiant (mapeditor) and other small tools like model exporters
renderer - client side renderer (opengl)
ports - os specific stuff

[Duke]

Thanks, Mattn

I finally found some spare time and surfed to the Code::Blocks site (I was particularly pleased to see it is hosted at berliOS ).
The site says it also supports the MSVC compiler. So it seems to me it's NOT UFO:AI's restriction to Code::Blocks or eclipse, it's more a restriction to MingW...

However, I'd like to cling to MSVC. So...

Q1: If I should get it to run with MSVC, would you appreciate if I documented my steps in the wiki ? Or is M$ totally disliked here ?

Q2: I managed to overcome the inttypes.h and stdint.h problems. Next is curl.h. Stupid question: does libcurl automagically come with MingW or has it 'silently' been packaged into the (UFO-)Code::Blocks installation package ? I didn't see it being mentioned in the wiki.

Q3: There is a libcurl-4.DLL in the UFO-dir, but I also found this code (in eg. q_shared.h):

Code: [Select]

#define CURL_STATICLIB
#include <curl/curl.h>
Uhmmm...STATICLIB doesn't really sound like DLL to me. I'm a bit puzzled. I guess a sentence or two from you could save me quite a lot of work to figure that out...

t.i.a.

[Mattn]

Q1: If I should get it to run with MSVC, would you appreciate if I documented my steps in the wiki ? Or is M$ totally disliked here ?

Yes, please do - the things we don't like is clumbering the code with msvc hacks all over the place. but if it only needs a few changes.... the more compilers the better. msvc might even produce some more useful warnings than gcc is producing.

The only other rule is, that all the msvc stuff must be done in the c::b files. we don't plan to add other project files to our svn, as nobody on the team will maintain them.

Q2: I managed to overcome the inttypes.h and stdint.h problems. Next is curl.h. Stupid question: does libcurl automagically come with MingW or has it 'silently' been packaged into the (UFO-)Code::Blocks installation package ? I didn't see it being mentioned in the wiki.

no, curl.h is no part of mingw - it's the libcurl header

Q3: There is a libcurl-4.DLL in the UFO-dir, but I also found this code (in eg. q_shared.h):

Code: [Select]

#define CURL_STATICLIB
#include <curl/curl.h>
Uhmmm...STATICLIB doesn't really sound like DLL to me. I'm a bit puzzled. I guess a sentence or two from you could save me quite a lot of work to figure that out...

to be honest i don't know anymore - it's been a long time since we introduced libcurl into ufo - btw. if you can manage to statically link some libs like curl, feel free to send patches - but keep in mind, that it still must work with c::b

[Duke]

I went ahead and added the sources from some dirs (namely shared, game, client, common) to my little MSVC-project and tried to compile.
Well, it doesn't look that bad....
Here's what I did so far (hope you understand the ultra-short notation):

- get inttypes.h add include-path
- get stdint.h
- get libcurl package
- define ssize_t in dbuffer.h
#ifndef ssize_t
#define ssize_t int
#endif

- #ifndef _MSC_VER in shared.h around min/max definitions

- problems with net.c, dbuffer.c, scripts.c need further investigation

- get libSDL
- get SDL_mixer
- get libintl

Looks like I'm re-inventing your C::B-package to some extent

Now I ran into this problem: libintl.h includes features.h.
I have learned that features.h is common to many glibc includes, but either I'm too tired or too stupid to google for the *right* link that solves this problem.

Do you (or anyone else) have an idea or a good link ?

[Mattn]

mh. it should be included in the codeblocks mingw/include dir, no?

also if you only need small patches to compile on msvc, please send a patch(/diff) file for stuff you already have - i will integrate this into svn then

[Duke]

Uhmm...remember: I'm trying to avoid the installation of MingW/C::B.....
But nevermind, I managed to overcome the features.h prob by creating my own libintl.h, deleting all the macros from features.h.

atm I'm running a brute force q&d attack on the *2.2.1. src* just to figure out if there are any showstoppers.
IF I should succeed, I'll send *clean* patches for 2.3.x, of course

Meanwhile I've been able to compile everything except net.c (which may become a showstopper because I don't know nothing about networking code ). Currently struggling with linking the libs.

[Mattn]

oh yes - the network code is ipv6-ready - might be a problem on some msvc installations. not sure about it

[Duke]

Ouch...that IS a showstopper
My MSVC installation definitely has no clue about ipv6. And the errors I get sound much like they are ipv6-related (addrinfo etc.).

Ok, I decided to give C::B a try and tried to DL your prepackaged zip. But only got between 12 and 42 MB of those 60+ before the DL stops Is that me or your server ?

[blondandy]

the link from the wiki page (http://szklo.eu.org/~mattn/Codeblocks.zip) worked for me last time (which was some months ago)

[Mattn]

try the rapidshare link from http://mattn.ninex.info => Download

[Duke]

@blondandy:
That's the link I used yesterday. Just tried it again minutes ago and it failed again

@Mattn:
Thx. Rapidshare did the trick

[Duke]

Ok, I managed to install C::B, get latest svn src, build it and - believe it or not - it worked
Well, quite.
I ran into several very obvious bugs (like the textures of items and persons in the recruit and the equip screens are ...uhm ... 'strange').

Which leads to the question: Is that a problem with the current svn code or did I miss something during installation/config ?

[Mattn]

they are working fine here - please attach screenshots of your problem. also did you use msvc for compilation? or gcc?

[Duke]

gcc.

I fired up UFO to take the screenshots, only to find that the strange textures were back to normal (no update, no recompile, no drugs).

However, two problems persist:
- the i18n insists to show german text. I can set it to english in the options menu, but the game stays in german.
- the 'einzelgefecht' feature (nice idea btw) doesn't seem to work. I can select eg. oriental and 'start', but it simply returns to the main menu.

Known bugs or my problem ?