UFO:Alien Invasion
Development => Coding => Topic started by: Duke on October 02, 2008, 12:43:27 am
-
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.
-
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
-
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):
#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.
-
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):
#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 ;)
-
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 ?
-
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
-
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.
-
oh yes - the network code is ipv6-ready - might be a problem on some msvc installations. not sure about it
-
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 ?
-
the link from the wiki page (http://szklo.eu.org/~mattn/Codeblocks.zip) worked for me last time (which was some months ago)
-
try the rapidshare link from http://mattn.ninex.info => Download
-
@blondandy:
That's the link I used yesterday. Just tried it again minutes ago and it failed again :(
@Mattn:
Thx. Rapidshare did the trick :)
-
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 ?
-
they are working fine here - please attach screenshots of your problem. also did you use msvc for compilation? or gcc?
-
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 ?
-
both are not known - have you compiled the po files? (from within c::b or compile_po.bat in contrib/scripts)
any console output for the second error? do you have the maps compiled?
-
NO to both po and maps.
A brief test after executing po.bat showed that it didn't solve the i18n prob. Will retest later.
Currently compiling the maps...
btw I added the info you gave above to the 'prepackaged C::B' chapter in the wiki. plz review.
-
Is the entire game German or just some texts? Is German your machine's default locale?
This smells like locale glitch (https://sourceforge.net/tracker/index.php?func=detail&aid=1773998&group_id=157793&atid=805242).
-geever
-
True. Machine's default locale is german.
But it's a little different than in that bug report you linked.
The game seems to be >90% german. The rest might well be strings where i18n is not (yet) implemented.
I even switched to 'danish' in the options menu, but to no avail.
-
I finally finished compiling the maps.
Congrats, you had the right idea :)
The 'einzelgefecht' now works fine.
The i18n prob persists, though.
-
did you try to restart game after changing language? As stated in the bugreport some texts are translated on startup and stay so until language is changed. This mainly applies to weapons.
Another version is related to saving: messages are saved in its translated version, so switching to another version and loading a savegame displays old messages with old language settings
-
RudolfoWood, this doesn`t help.
-
Current situation is:
The freshly started exe comes up and has 'remembered' that the language switch is set to danish. All menus, buttons, item desc etc. are in german.
I chose danish to prove that it's neither the default nor the machine's locale.
-
Update:
I'm not yet familiar with the ufo code nor with language handling. But the snippit from CL_LanguageTryToSet() below looks rather strange to me:
do {
Cvar_Set("s_language", mapping->localeMapping);
#ifdef _WIN32
Com_DPrintf(DEBUG_CLIENT, "CL_LanguageTryToSet: %s\n", mapping->localeMapping);
SDL_putenv(va("LANGUAGE=%s", mapping->localeMapping));
Cvar_Set("s_language", language->localeID);
s_language->modified = qfalse;
return qtrue;
#else
if (setlocale(LC_MESSAGES, mapping->localeMapping)) {
Cvar_Set("s_language", language->localeID);
s_language->modified = qfalse;
return qtrue;
}
#endif
mapping = mapping->next;
} while (mapping);
#ifndef _WIN32
Com_DPrintf(DEBUG_CLIENT, "CL_LanguageTryToSet: Finally try: '%s'\n", localeID);
setlocale(LC_MESSAGES, localeID);
#endif
On WIN32, the do-while will always break after the first loop AND return, so
1. the #ifndef _WIN32 after the while is useless (not the enclosed code)
2. setlocale() is never executed here on WIN32
So as the function behaves *completely* different on WIN32, I would expext a big fat comment stating that.
The missing of such a comment along with the useless #ifndef lets me suspect that the code does not work as the programmer intended.
Anyone around who knows more about how setlocale should work on WIN32 ??
-
Uhmm...forget about my above post (exept for the missing comment and the useless #ifndef), that is NOT the error.
After some research and debugging, I have been able to nail it down to this:
// SDL_putenv(va("LANGUAGE=%s", mapping->localeMapping)); // does NOT work on Win
putenv(va("LANGUAGE=%s", mapping->localeMapping)); // works fine here
What I have not figured out is how SDL_putenv() is superior to putenv(). Back in 2.2.1 Q_putenv() was used (and worked fine).
I also found this on the web:
"Not all environments have a working putenv(). SDL_putenv() is not available on Windows. "
(from : http://docs.taoframework.com/Tao.Sdl/Tao.Sdl.Sdl.SDL_putenv.html (http://docs.taoframework.com/Tao.Sdl/Tao.Sdl.Sdl.SDL_putenv.html))
-
Hmm. Q_putenv() went out of its way to call setenv() on "APPLE" and putenv() on other platforms. Linux also has setenv() nowadays; perhaps Windows does too?
setenv() is better than putenv() because putenv() keeps the string and makes it part of the environment. That means that Q_putenv()'s approach of constructing putenv()'s argument in a local string is bound to fail: as soon as that memory gets overwritten, the environment string gets overwritten.
If we can use setenv() everywhere, we should.
-
Just tested it: setenv() doesn't exist on Windows :(
Why don't we just create some UFO_setenv() and therein do whatever is necessary for the various platforms supported ?
-
Amtep, I can hardly believe what you said about putenv(). Are you really saying it stores a pointer of unknown origin in a semi-permanent structure like the environment and not creating a copy ???
Or did I simply not understand you ?
That's a common newbie fault, but no C-programmer with a sane mind and more than 2 weeks of coding experience would do that imho.
At least the putenv implementation in Windows doesn't seem to have that problem.
-----
Ok, so SDL_putenv was introduced to support APPLE. The line of code in question is already enlosed in #ifdef WIN32. So we can safely change that line to a simple putenv() without disturbing the other platforms.
The dowside is, that we then no longer have just one function that encapsulates the stuff. But as SDL_putenv() is only called from a handfull of places, all in the context of locale setting, which needs a lot of #ifdef's anyway, I think we can afford that.
-
Yep, it really behaves that way. What's more, it was standardized that way, so even platforms which used to make a copy now keep the string instead. The standard is here (http://www.opengroup.org/onlinepubs/009695399/functions/putenv.html), but a web search for "putenv man page" will find similar language for a variety of platforms. Windows seems to be the big exception here, actually, probably because it has a different structure for keeping track of the environment and it needs to copy the value to that.
If Windows doesn't have setenv, then using putenv on Windows and setenv everywhere else seems to be the way to go. If it's all inside an #ifdef WIN32 then you're probably right that we don't need a helper function.
-
Amtep, thanks a lot for providing the link to the standard. As you probably guessed from what I wrote above: otherwise I wouldn't have believed you.
I always thought of 'the environment' as a way to pass some kinda configuration to programs. Obviously, the opengroup guys had something different in mind; like a cheap way to pass data between threads.
Ok, we're not here to judge the decisions of standardisation organisations...
----
As we both seem to agree on the solution of our little language problem and I don't have commit access to the svn, may I ask you to commit the fix ? Unless some 3rd person objects, of course.
I forgot to mention that the line in question is located in module cl_language.c, func CL_LanguageTryToSet(),
somewhere around EOF minus 20 lines.
For a 4-byte change, a diff would be overkill, right ?
Oh, and you may want to add this comment:
/* as SDL_putenv() doesn't work on Windows, we need to use putenv() here */
Ok, more than 4 bytes....
-
I've just committed r19934 which should fix this by introducing a Sys_Setenv() function in the src/ports system and using that. Can you test it? I can only test on Linux.
-
I happened to see rev 19934 before I found your above post...
Just tested it, works nicely here.
Thx :)