Reply With Quoteid 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
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.
Last edited by closms; November 3, 2003 at 14:25.
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
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.
Solver, WePlayCiv Co-Administrator
Contact: solver-at-weplayciv-dot-com
I can kill you whenever I please... but not today. - The Cigarette Smoking Man
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
A public CVS (www.cvshome.org) server would be a good way to coordinate all developer efforts. Does such a server exist?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.
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.
Solver, WePlayCiv Co-Administrator
Contact: solver-at-weplayciv-dot-com
I can kill you whenever I please... but not today. - The Cigarette Smoking Man
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.
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.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 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
Last edited by kaan; November 3, 2003 at 15:56.
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.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.
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
Since the code was written for DirectX 7 it may be possible to get it to compile against winelib.
winelib of course
you are a hero my friend
As far as CVS and stuff goes, I'm working on that (seeing what's technically/legally possible), please give me some time...
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.
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
Good Job
3 comments from me right now:
1. in the Makefile:
should be replaced byCode:-mkdir dll -mkdir dll/map
(It isnt serious, just suppresses the warnings if the directories already exist)Code:-mkdir -p dll -mkdir -p dll/map
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.
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?
Last edited by uppi; November 4, 2003 at 19:20.
I guess VC++ lets you typedef a function signature and then use it to declare function prototypes. MouseEventCallback is an example of this.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?
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
thanks
Now I managed to compile all the files in ctp/ctp2_utils
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.
Nice work
I don't know how the SDL audio subsystem works, but your efforts are much appreciated.
Its great... If we can get some linux people involved... well... the more the merrier.
Great work!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.
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
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
Could you please zip up the changed files and post them here?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.
kaan
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 couldOriginally posted by closms
Does anyone know how to get g++ to grok the following?
(snip)
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.
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.
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.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 I was talking about closms' code.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.
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).
Posting Permissions
Bookmarks