COMPILE: Linux Port

closms · November 3, 2003, 13:12

I'm wondering is anyone else is trying to port this to linux.

I spent some time on it and I got some of the mapgen dll's to build. Specifically Crater.so, fault.so, geometric.so, Plasma1.so and Plasma2.so

The above was the easy stuff though. I guess that hard part will be replacing dx calls with sdl calls and mss calls with openal calls.

I noticed that there is a linux makefile for dbgen. So I guess at least someone at activision was thinking of linux. ( Maybe they're reading this post, and could contact me?

).

Anyways, I'm interested in getting this thing up and running under linux. So if anyone thinks they can help out, that would be great!

Mike

ps. If you want to get a hold of me, use msn messenger (closms@hotmail.com). Don't send email there, I won't get it.

kaan · November 3, 2003, 15:23

id be glad to help but i have never tried to port an application to linux before, im just a happy user/programmer. but i figure it cant be too hard, just a long hard pull to get everything plugged in to the proper system calls.

kaan

Solver · November 3, 2003, 16:00

I believe that we should concentrate our efforts to work in some sort of a single fashion. Our priority now should be fixing the worst of game bugs, and adding sound on the Windows version.

Although for the future, Linux port is clearly a good idea.

kaan · November 3, 2003, 16:22

these goals are not that different, porting ctp2 to linux is also making the sound work and fixing bugs, its just that if we do port this game to linux there will be a lot more ppl coming to help with the rest. Those ppl will for the most part be experienced in working in an open source community and we can really use that kind of ppl now.

kaan

closms · November 3, 2003, 16:23

Quote:

Originally posted by Solver
I believe that we should concentrate our efforts to work in some sort of a single fashion. Our priority now should be fixing the worst of game bugs, and adding sound on the Windows version.

A public CVS (www.cvshome.org) server would be a good way to coordinate all developer efforts. Does such a server exist?

Solver · November 3, 2003, 16:26

As I posted in another thread, we may be prohibited from using a CVS.

Also, on Linux port, it's not open source. Usage of CtP2 source is limited by EULA.

MrBaggins · November 3, 2003, 16:29

The source code can, at this point, only be distributed from Apolyton, as far as I am aware, according to the code EULA. This would preclude a remote CVS, unless it was somehow implemented at Apolyton. I think ultimately some semi-manual system will be implemented.

kaan · November 3, 2003, 16:32

Quote:

Originally posted by Solver
As I posted in another thread, we may be prohibited from using a CVS.

Also, on Linux port, it's not open source. Usage of CtP2 source is limited by EULA.

i know that what we are dealing with here is not open source, but our way to work with the code (can you even say that?) is identical and thats why we could use ppl that has experience from that kind of projects.

i just read the licence again and you are right about the distributing part, thats a shame if that inhibits us from using a public CVS.

kaan

closms · November 3, 2003, 16:50

Quote:

Originally posted by Solver
As I posted in another thread, we may be prohibited from using a CVS.

Also, on Linux port, it's not open source. Usage of CtP2 source is limited by EULA.

What if Apolyton set up a pserver and only gave accounts to people who have accepted the EULA. That way CVS could still be used and we wouldn't be violating the code EULA.

kaan · November 3, 2003, 17:00

we could also make a source tree containing only the patch code, that way we can distribute all we want to.
the patch program in linux would be perfect, does anyone know if it has been ported to win32? it might be part of cygwin but i dont know.

kaan

EzInKy · November 3, 2003, 18:00

Since the code was written for DirectX 7 it may be possible to get it to compile against winelib.

kaan · November 3, 2003, 18:11

winelib of course

you are a hero my friend

Locutus · November 3, 2003, 19:38

As far as CVS and stuff goes, I'm working on that (seeing what's technically/legally possible), please give me some time...

J Bytheway · November 4, 2003, 09:57

We (those who have downloaded the code) all already have a copy of diff that came with the source code. I'm sure it will come in handy.

closms · November 4, 2003, 14:26

Hello All,

I've made a patch available to kick off the linux port. Contributions and criticism are welcome.

http://www.cs.ualberta.ca/~closson/ctp2/

Right now the work is pretty basic. Correcting case, and compiler warnings. Also VC++ has some quirks that aren't supported on g++. It should be pretty easy to contribute.

Mike

uppi · November 4, 2003, 16:19

Good Job

3 comments from me right now:

1. in the Makefile:

Code:

-mkdir dll
-mkdir dll/map

should be replaced by

Code:

-mkdir -p dll
-mkdir -p dll/map

(It isnt serious, just suppresses the warnings if the directories already exist)

2. What byacc are you using? Mine wouldnt accept the -o option. I had to remove it and copy the files manually.

3. There should be a variable like WINE_INCLUDE_DIR (or something like that) in the Makefile, pointing to the include dir of the winelib, because then it would be easier to change the Path of the winelib include files.

uppi · November 4, 2003, 18:58

And they are really allowed to call this "C++ Code"? I cant believe the VC++ compiler is accepting this. The Header files are a real mess. To get this working declarations have to be taken from one file and put into another, because header files are needing declarations from each other...

Well i managed to correct some errors (especially the "enum"-Errors) but now i am stuck with structure (?) called MouseEventCallback. It is used as a type, but i cant find a declaration of it and so g++ complains. Anybody got an idea where the declaration is / how to solve that?

closms · November 4, 2003, 21:46

Quote:

Originally posted by uppi
And they are really allowed to call this "C++ Code"? I cant believe the VC++ compiler is accepting this. The Header files are a real mess. To get this working declarations have to be taken from one file and put into another, because header files are needing declarations from each other...

Well i managed to correct some errors (especially the "enum"-Errors) but now i am stuck with structure (?) called MouseEventCallback. It is used as a type, but i cant find a declaration of it and so g++ complains. Anybody got an idea where the declaration is / how to solve that?

I guess VC++ lets you typedef a function signature and then use it to declare function prototypes. MouseEventCallback is an example of this.

eg.

typedef void (*MouseEventCallback)( aui_MouseEvent *mouseData );

virtual MouseEventCallback PreChildrenCallback {}

The traditional way to do this is

virtual void PreChildrenCallback( aui_MouseEvent *mouseData ) {}

Have a look at ui/aui_common/aui_region.h line 354 of my patched version.

This is what is happening that causes the enum problems

header a.h
------------
#include "b.h"

enum a1 {
a1_a,
a1_b,
a1_c
};

class a2 {
b1_a var;
.....
};

--------------

header b.h
-------------
#include "a.h"

enum b1 {
b1_a,
b1_b,
b1_c
};

class b2 {
a1_a var;
.....
};
---------------

So basically there are circular dependencies. I think the easiest way to fix this is to place the #include "a.h" after the enum is declared.

GENDER and CIV_INDEX are two good examples of this.

Mike

uppi · November 5, 2003, 13:40

thanks

Now I managed to compile all the files in ctp/ctp2_utils

bfennema · November 5, 2003, 22:08

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.

Peter Triggs · November 5, 2003, 22:30

Nice work

I don't know how the SDL audio subsystem works, but your efforts are much appreciated.

MrBaggins · November 5, 2003, 22:32

Its great... If we can get some linux people involved... well... the more the merrier.

closms · November 6, 2003, 16:26

Quote:

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.

Great work!

Yea, I'm surprised that more game companies don't use sdl or openal instead of mss.

Is this under windows or linux? If it's under linux then my hats off to you for fixing all the annoying compiler problems so quickly!

Mike

closms · November 8, 2003, 14:00

Does anyone know how to get g++ to grok the following?

file: a.h
-----------------
#ifndef A_H
#define A_H

#include "b.h"

class a {
b m_b;
};
#else
class a;
#endif
-----------------
file: b.h
-----------------
#ifndef B_H
#define B_H

#include "a.h"

class b {
a m_a;
};

#else
class b;
#endif
-----------------
file: tmp.cc
-----------------
#include "a.h"
#include "b.h"

int main() {
a a_var;
return 0;
}
-----------------

Mike

kaan · November 9, 2003, 12:25

Quote:

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.

Could you please zip up the changed files and post them here?

kaan

Leland · November 9, 2003, 13:45

Quote:

Originally posted by closms
Does anyone know how to get g++ to grok the following?

(snip)

No c++ compiler should accept that piece of code. Basically class a contains class b, and class b contains class a, which leads to an infinite regress. Depending on what you really want to achieve with that piece of code, you could

1) replace m_a and m_b with pointers and use forward declarations instead of including the headers, or

2) declare a common base class for both of them which contains the data you want shared.

Maajromax · November 9, 2003, 13:46

Or, perhaps better, post a diff against the original source.

So long as it doesn't break anything, a linux-buildable source would be an excellent starting place for everyone else's modifications, as it's much more likely to remain portable/cross-platform.

uppi · November 9, 2003, 18:47

Quote:

Originally posted by Leland

No c++ compiler should accept that piece of code. Basically class a contains class b, and class b contains class a, which leads to an infinite regress. Depending on what you really want to achieve with that piece of code, you could

1) replace m_a and m_b with pointers and use forward declarations instead of including the headers, or

2) declare a common base class for both of them which contains the data you want shared.

Actually there were no circular dependencies in the classes itself, but in the header files containing the various enums. By putting these enums in a seperate header file this is (more or less) easily solved.

Leland · November 11, 2003, 13:08

Quote:

Originally posted by uppi

Actually there were no circular dependencies in the classes itself, but in the header files containing the various enums. By putting these enums in a seperate header file this is (more or less) easily solved.

Actually I was talking about closms' code.

closms · November 16, 2003, 18:09

Does anyone know what the code in this subdir of for? I find a lot of duplicate headers in here. And including them has been nothing but trouble (im working on getting all the ui code to compile).