 |
| |
|
|
closms
|
|
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 on 04-11-2003 at 00:25
|
|
| |
|
|
|
kaan
|
|
Aarhus
Mar 2001
time: 05:31
|
|
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
|
|
| |
|
|
|
kaan
|
|
Aarhus
Mar 2001
time: 05:31
|
|
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
|
|
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?
|
|
| |
|
|
|
MrBaggins
|
|
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
|
|
Aarhus
Mar 2001
time: 05:31
|
|
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
Last edited by kaan on 04-11-2003 at 01:56
|
|
| |
|
|
|
closms
|
|
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
|
|
Aarhus
Mar 2001
time: 05:31
|
|
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
|
|
| |
|
|
|
closms
|
|
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
|
|
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 on 05-11-2003 at 05:20
|
|
| |
|
|
|
closms
|
|
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
|
|
| |
|
|
|
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.
|
|
| |
|
|
|
MrBaggins
|
|
Its great... If we can get some linux people involved... well... the more the merrier.
|
|
| |
|
|
|
closms
|
|
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
|
|
Aarhus
Mar 2001
time: 05:31
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
| |
|
|
|
closms
|
|
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).
|
|
| |
All times are GMT. The time now is 05:31.
Apolyton Time is 00:31. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
03-11-2003 22:12
winelib of course 
|