COMPILE: Linux Port

btb · November 17, 2003, 17:23

Originally posted by bfennema
I got the executable to build with SDL/SDL_mixer instead of mss32, and sound (at least the sfx) seem to work fine. The only thing I couldn't do a direct mapping of was cdrom volume. I couldn't find a way in SDL to adjust the cdrom volume.

SDL doesn't provide a way to control the volume, so you have to implement an OS-specific routine to do it.

Basically in linux, you do an ioctl on the cdrom device (which just happens to be the 'id' field of the SDL_CD struct) -
You can see how I did it in d2x here:
http://cvs.icculus.org/cgi-bin/viewc...?r1=1.4&r2=1.5
Note that this doesn't touch the mixer of your sound card, it changes the volume internally on the drive itself.

closms · November 18, 2003, 12:14

Originally posted by btb
Basically in linux, you do an ioctl on the cdrom device (which just happens to be the 'id' field of the SDL_CD struct) -
You can see how I did it in d2x here:
http://cvs.icculus.org/cgi-bin/viewc...?r1=1.4&r2=1.5
Note that this doesn't touch the mixer of your sound card, it changes the volume internally on the drive itself.

Thanks btb, this is great! If you're ever interested in helping out with the linux port, let me know. Right now the work is getting the .cpp files so that g++ can compile them. Stuff like correcting case, fixing decls, ....

btb · November 18, 2003, 16:05

Originally posted by closms

Thanks btb, this is great! If you're ever interested in helping out with the linux port, let me know. Right now the work is getting the .cpp files so that g++ can compile them. Stuff like correcting case, fixing decls, ....

I'd love to. I don't see how we can really collaborate without CVS or something though. The EULA for this source code is totally fubar, but I have an idea of how we can do it legally.

-btb

Solver · November 18, 2003, 16:12

Activision have mentioned that we are, after all, allowed to use a CVS...

btb · November 18, 2003, 16:31

Oh, okay. I just read the updated FAQ, and that's pretty much what my idea was: Put it on cvs, but in order to get to the web page which shows the password, you have to click a link confirming that you have acquired a "legal" copy of the source, and agreed to the EULA.

btb · November 18, 2003, 16:32

Has anybody looked into a host for the linux port? I can try to get it on icculus.org...

uppi · November 18, 2003, 18:32

I am trying to compile civapp.cpp and I am getting some strange Errors:

Code:

In file included from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/g++-v3/memory:59,
                 from ../ui/interface/MainControlPanel.h:15,
                 from ../ctp/civapp.cpp:74:
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/g++-v3/bits/stl_raw_storage_iter.h:64: syntax
   error before `namespace'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/g++-v3/bits/stl_raw_storage_iter.h:79: `
   _ForwardIterator' was not declared in this scope
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/g++-v3/bits/stl_raw_storage_iter.h:79: syntax
   error before `)' token
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/g++-v3/bits/stl_raw_storage_iter.h:79: only
   declarations of constructors can be `explicit'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include/g++-v3/bits/stl_raw_storage_iter.h:81: syntax
   error before `&' token

These errors are strange for several reasons:
1. I haven't managed to reproduce thes errors with test programs of my own, would be included nicely.
2. 'namespace' is the first piece of code in that file, so a syntax error bfore that doesnt make much sense...

about the cvs server: closms has already set up a temp cvs server, but i think it wouldnt hurt to have an official one.

closms · November 18, 2003, 20:22

Originally posted by uppi
I am trying to compile civapp.cpp and I am getting some strange Errors:

Hi uppi,

check cvs for a fix that worked for me. The problem was in netshell.h. Specifically the action callback in the DestroyAction class.

g++ can give crappy error messages sometimes.

uppi · November 19, 2003, 18:43

Thanks, civapp.cpp compiles finally

btw: This is what i would call a "creative and unique name for a variable":

Code:

GUID		GUID;

How the hell could any compiler accept this?
I changed the name of the variable to displayGUID, so if anyone finds g++ complaing about DisplayDevice::GUID change it to DisplayDevice::displayGUID .

Joss · November 20, 2003, 14:52

Is their now a way to get the code with the Linux specific changes

closms · November 20, 2003, 14:55

Originally posted by Joss
Is their now a way to get the code with the Linux specific changes

Hi Joss,

I have setup a private CVS server with the linux code. If you have agreed to the EULA, email me and I will give you an account.

btb · November 20, 2003, 15:38

Have you actually got the cvs code to build under linux? I found tons of things that wouldn't compile - that GUID thing above, several function calls with the wrong # of args, stuff like that.

Plus there are so many filenames with the wrong case - I guess it doesn't matter if you have the code on a FAT partition though.

btb · November 20, 2003, 15:46

So, I'd like to fix the filename case, but we need to decide on a consistent standard. I think that going with Activision's original intent is the simplest.

It looks like most of the time activision intended to use mixed case (FileName.cpp, etc), but then they got lazy.

Some modules however, it seems they intended to use lowercase only - ui/aui_*, for example.

uppi · November 20, 2003, 17:42

Originally posted by btb
Have you actually got the cvs code to build under linux? I found tons of things that wouldn't compile - that GUID thing above, several function calls with the wrong # of args, stuff like that.

Plus there are so many filenames with the wrong case - I guess it doesn't matter if you have the code on a FAT partition though.

Well, no we havent got it to compile yet, otherwise we wouldnt be working on it

The makefiles: dbgen.mk Crater.mk fault.mk geometric.mk Plasma1.mk Plasma2.mk ctp.mk and ui.mk _will_ (well _should_) compile for now, the others, especially gfx.mk gs.mk ai.mk robot.mk and net.mk will only compile to a certain point and then exit with error messages, which need to be fixed without breaking to much.

The problem with the filenames with wrong cases was fixed rather _quick_ until now: If a file did not find an include because of case errors, the right filename would be given in that file and the include would happily keep its filename....

BTW: Does anybody know if there is a unix equivalent to "_splitpath" as this function seems to be windows only? (It basically splits up the filename to its components, like Drive, Path, Extension...). If not I guess I'll have to write some replacement code for it.

btb · November 20, 2003, 18:11

bfennema said he had an executable built, with SDL for sound... perhaps he simply meant he had built it under windows, and replaced the sound code with SDL.

d2x has a splitpath function:
http://cvs.icculus.org/cgi-bin/viewc...viewcvs-markup
I don't know how accurate it is, but it works for d2x.

closms · November 20, 2003, 18:20

Originally posted by btb
So, I'd like to fix the filename case, but we need to decide on a consistent standard. I think that going with Activision's original intent is the simplest.

It looks like most of the time activision intended to use mixed case (FileName.cpp, etc), but then they got lazy.

Some modules however, it seems they intended to use lowercase only - ui/aui_*, for example.

Hi Brad,

Yea, this should be fixed properly. What I have been doing is changing the filenames in code and not renaming the files on disk. So I don't have do cvs delete and cvs add the renamed file (btw, is there a better way to do this?)

I put a script in the linux dir called fixcase.sh to make this a little easier.

Although I agree that calling the filename the same as the class it defines is good style.

btb · November 20, 2003, 19:05

I think that if you have access to the cvs repository, you can just rename the files directly, and then it'll be as if it had always been that way. It's been a long time since I tried anything like that though.

uppi · November 24, 2003, 17:10

Uh oh, I got a problem here...

in gfx/spritesys/Sprite.cpp there are calls of some dirty

MS Function called _msize, which returns the size of the allocated memory to a pointer.

A search on the internet with "_msize" and "gcc" mainly returned things like this:

foo = _msize(bar);
/* not portable to gcc */

does anybody know how to replace that function? Or else I'll have to figure out, what memory is allocated and somehow store this in a new variable.

btb · November 24, 2003, 18:07

I saw that too. I _think_ we can get away with using the (unsupported, undocumented, unportable) function malloc_usable_size()

i.e. just do:
#ifdef __GNUC__
# define _msize malloc_usable_size
#endif

teknomage1 · November 26, 2003, 11:07

for anyone doing some dev work in windows while trying to understand the code, http://unxutils.sourceforge.net/ has win32 ports of most of the good unix commandline tools. And there's a port of GVIM for windows also at vim.org

uppi · November 26, 2003, 17:17

Originally posted by teknomage1
for anyone doing some dev work in windows while trying to understand the code, http://unxutils.sourceforge.net/ has win32 ports of most of the good unix commandline tools. And there's a port of GVIM for windows also at vim.org

Erm, this is the linux port thread. Kinda hard to port a game to linux if you're working in windows...Therefore i dont think we need win32 ports of commandline tools or editors. Go post in a windows thread, they might need those tools, or post in this thread and add something constructive.

I saw that too. I _think_ we can get away with using the (unsupported, undocumented, unportable) function malloc_usable_size()

i.e. just do:
#ifdef __GNUC__
# define _msize malloc_usable_size
#endif

So were replacing a dirty win32 hack with a dirty glibc hack

Anyway, it compiles and we have to test whether this works. (I have a bad feeling, that there we will need some extensive debugging once we get a binary)

teknomage1 · November 26, 2003, 18:50

I realize you're porting it to linux dude. I just didn't realize how far you'd gotten from what I understood it folks were still trying the grok the code...ungrateful..blah.
-----------------------------------------------------------------
posted from Gentoo Linux running 2.6.0-test10-mm4

closms · November 27, 2003, 13:29

This is how I propose we handle enums. Just so we're all on the same page.

If you see

enum C3DIR {
C3DIR_DIRECT = -1,
...
};

change it to

typedef sint32 C3DIR;
enum C3DIR_enum {
C3DIR_DIRECT = -1,
...
};

If you see

enum C3DIR;

change it to

typedef sint32 C3DIR;

The compiler can promote C3DIR_DIRECT to a sint32 without any trouble.

Mike

closms · November 27, 2003, 14:10

Originally posted by closms
This is how I propose we handle enums. Just so we're all on the same page.

Grrr.. Of course there is a problem with this already. If all enums are now sint32's then operator overloading won't work. ie

Player::FindAgreement(const PLAYER_INDEX otherParty)
Player::FindAgreement(const AGREEMENT_TYPE agreement)

used to work, but now doesn't. I'm going to chnage it to

Player::FindAgreementPI(const PLAYER_INDEX otherParty)
Player::FindAgreementAT(const AGREEMENT_TYPE agreement)

for now. Ideas??

Mike

uppi · November 28, 2003, 10:06

I am suddenly missing a file "lin_compat.h". I guess somebody made that file and forgot to add it to the cvs. So if the maker could add that file I would be happy

closms · December 1, 2003, 17:51

Originally posted by uppi
I am suddenly missing a file "lin_compat.h".

Done.

closms · December 7, 2003, 00:48

Anyone else notice that the networking code uses the anet library. And we have a dll but no source. I guess we can cut multiplayer support for now. Any chance we can get this source code or at least a linux .so?

Martin Gühmann · December 7, 2003, 10:10

Originally posted by closms
Anyone else notice that the networking code uses the anet library. And we have a dll but no source. I guess we can cut multiplayer support for now. Any chance we can get this source code or at least a linux .so?

Probably it is the same library as used in CTP1 and as there is a linux version of CTP1 there should such a file, but I can remember that we found something about it in the internet maybe but I am not sure the source code was also there.

-Martin

closms · December 9, 2003, 18:41

Originally posted by Martin Gühmann

but I can remember that we found something about it in the internet maybe but I am not sure the source code was also there.

-Martin

Yep. Here it is. Thanks Martin.

http://www.kegel.com/anet/

btb · December 9, 2003, 19:46

Wow, it's LGPL even. Of course, normally integration of LGPL software would not be possible, since it's incompatible with the ctp2 license... In this case, though, since it's the same library Activision used originally, we wouldn't be actually creating a "derived work".