 |
| |
|
|
ctplinuxfan
|
|
quote:
Originally posted by Joss
Hi,
Im wonder if anyone is still working on a linux port, and where to get the few pathes for it. I would be happy to contribute to a linux port.
Cya |
Hi,
due to the count of answers i'm afraid nobody is continuing on it atm.  Though, it would be great to have somebody who aids on this!
I've a lot of work to do and am moving, which prohibits me from continuing on it for some time. The main things i suppose have to be done are (perhaps in that order):
- create branch with apolyton sources on subversion repository for linux port
- merge sources from closms cvs into that branch
- use autoconf/automake mechanism
- make the code compiles with vc6 and work under windows
- bug fixes
- milestone 1: merge back to apolyton main codeline and sync branches
- merge patch by johannes sixt into linux branch, without removing the original cd check (i.e. reimplement sdl version for linux)
- when merging this patch, also provide native DirectX code by implementing aui_sdl abstraction layer
- check that code also compiles with vc6 and works under linux and windows
- bug fixes
- milestone 2: merge back to apolyton main codeline and sync branches
- result: first working linux version with mouse support only
- implement abstraction for user input by both DirectX and SDL
- verify it works under windows and linux
- bug fixes
- milestone 3: merge that back to apolyton main codeline
- result: linux version with keyboard input
- implement cdrom volume settings for linux and windows with sdl providing native directx code
- bug fixes
- merge back and sync with apolyton main codeline
- implement installer (perhaps a script first that unpacks the archives
- bug fixes
- milestone 4: merge with apolyton code line, sync branches
- result: releasable source package (if agreed to eula) or binary builds
- fix network game play
- bug fixes
- milestone 5: merge and sync..., native ctp2 for linux, network games with windows clients possible
- bug fixes
- milestone 6: sync codebase suitable for other ports efforts, if any
So to get started, you'd need to mail closms to get access to the cvs server and ask kaan to get access to the subversion server once it is up.
When i can spend some time again, i will add windows related project files for building an SDL version of civctp2 under windows as well (i have started on them, but maybe need to resolve some conflicts).
|
|
| |
|
|
|
Capehill
|
|
Your plan sounds good, are there any news?
I got just an access to the SVN server and I'm interested to try AmigaOS port using SDL, but as far as I know, the sources on that SVN server use DirectX.
I'd like to help but my time is also very limited...
|
|
| |
|
|
|
ctplinuxfan
|
|
You can learn as you go along, but if you find a tutorial, please let me know. 
For undeclared errors, there may be these cases
- missing include in .c/.cpp file with the error
Find out, where the prototype/the function is defined (e.g. using ctags) and add that header file to the #include list in the .c/.cpp file
- function/type used available on windows only, see points below
- the function uses windows related datatypes (e.g. MBCHAR, LPVOID) as parameters or return values and reading it's documentation at msdn.microsoft.com, you found a replacement function which does the same, e.g. WIN32 CreateDirectoryand Unix/POSIX mkdir
Replace the code like this
code:
#ifdef WIN32
return CreateDirectory(path, NULL);
#else
mode_t mask = 0777;
return mkdir(path, mask);
#endif // WIN32
The function does not use windows related datatypes or you don't know a replacement
Add its prototype definition to os/nowin32/windows.h
Also add type definitions for the parameters, if not in windows.h already
enum forward declaration errors:
Locate the header with the definition of the enum and add move it's definition to ctp/ctp2_enums.h. In the header file, add the line #include "ctp2_enums.h"
Remove the enum ITS_NAME; line and replace it with #include "ctp2_enums.h"
I cannot test the last changes on windows ATM, so i'll create a linux-branch now with more up-to date changes. We can merge the changes to trunk frequently, when they have been tested on windows, too.
So checkout the linux stuff at svn://stp2.kaan.dk/ctp2/branches/linux
HTH,
Holger
PS: There is a book titled Programming Linux Games, but it does not cover porting afaik (read about it on freshmeat.net). Perhaps you can get this book at a library, it'll give you an overview over linux and game programming. At least that might ease the task finding an equivalent implementation of a windows function.
|
|
| |
|
|
|
J Bytheway
|
 |
England
Jul 2001
time: 05:31
|
|
Well, I've had some fun this evening trying to make civ3_main.cpp compile. I've fixed things as best I can, but since I'm new at this I would appreciate it if you glance over what I've done and tell me if I did anything stupid.
I encountered the enums DEFAULT_PLACE_POP and MSG_CLS which appear not to be defined anywhere - I wonder if they were removed at some point and there are still references to them lying around, but I would have thought that would have caused compilation errors under Windows...
The next batch of errors are of the form:
code:
ctp2_code/ui/aui_common/aui_listbox.h:291: error: friend declaration
requires class-key, i.e. `friend struct aui_DropDown'
Is it safe to simply follow the advice of the error messages in this case (which is what Googling suggests)?
Last edited by J Bytheway on 23-05-2005 at 07:19
|
|
| |
|
|
|
J Bytheway
|
|
England
Jul 2001
time: 05:31
|
|
quote:
Originally posted by ctplinuxfan
_WIN32 is used by original code, WIN32 has been introduced by me or others. Actually some compilers define _WIN32, some WIN32 on Windows, and some neither. For newer Microsoft compilers, _WIN32 doesn't mean sizeof(void *) == sizeof(int) == sizeof(long) == 4, because it's also defined on x86_64, for which _WIN64 was introduced. |
OK. Thanks for the explanation.
quote:
Some headers are cyclical included, because the types they define are used in any of them and are forward defined. So i chose moving the enums into a seperate file to unroll dependencies. E.g. i remember enums needed from keymap.h and aui_tabgroup.h could be fixed by additional inclusion. |
Right, that makes sense .
quote:
Sorry if i thought of something simple to start with. |
Simplicity has its merits  .
quote:
However, this file is still thought to be a container for enums to be refactored into other files when refactoring makes sense. |
OK. I feel we might want to start making a list of these issues that need to be looked at later.
quote:
We will have to get along some issues of which i think we need to refactor some parts of the code (e.g. type punned pointers in event system and non-static class methods used in arrays of callback functions, the later is in newdb if you turn -fms-exceptions off). |
Well, I have almost no idea what that means .
Last edited by J Bytheway on 27-05-2005 at 03:12
|
|
| |
|
|
|
J Bytheway
|
|
England
Jul 2001
time: 05:31
|
|
quote:
Originally posted by ctplinuxfan
What i'd like to see changed is the top Makefile to be removed and GNUmakefile.am added as Makefile.am instead.
It allows other make programs to also perform a build. The other gain would be, that IDEs like e.g. kdevelop display the targets of the project and display the classes in the classview. We could move the original makefile into an admin dir, like e.g. some kde projects do it, to make its targets available without automake.
Anyways, i tried but reverted this, since i don't know who else uses the Makefile atm. |
Well, I suspect I'm the only one who uses it, and I certainly don't mind it being moved into some other appropriate place. I think anyone else who uses it will be ble to cope as well, provided the change is mentioned sufficiently obviously in the revision report.
quote:
Well, more and more stuff compiles. I'd like to seperate some compilation tasks into the associated subdirs to generate conveniance libraries, as we proceed. This should reduce compilation and linking time theoretically, because only the executable and the conveniance library with the sources you changed will be relinked if you just change .cpp files later on (i.e. no header file included by anything like c3.h)... |
Sounds good .
Besides errors in improveevent.cpp, There seem to be a lot of warnings which concern me. They are mostly in the events-related files so I guess they are results of the "type punned pointers" you were mentioning...
|
|
| |
|
| |
|
|
|
ctplinuxfan
|
|
My idea goes in this direction. However, the ptr trick is ugly because it's unclear when unneeded temporaries of function parameters are destroyed (not a reference of the object is passed, but a pointer to the object. the pointer still holds an adress, after the object is destroyed, but dereferencing the pointer will lead into a crash, because it points to an invalid address).
My idea goes in that direction:
code:
class Param {
public:
Param(const Unit &u) { m_type = typeUnit; m_u = u; }
Param(const City &a) { m_type = typeCity; m_c = c; }
...
const type getType() const;
City &getCity();
Unit &getUnit();
private:
...
};
class EventCall {
public:
int call(const Param &p1);
int call(const Param &p1, const Param &p2);
int call(const Param &p1, const Param &p2, const Param &p3);
...
}
City c(id);
Unit u(id2);
EventCall evc;
evc.call(SEND_UNIT_TO_CITY, u, c);
however, this might lead into performance issues, because additional time is needed for creating temporary Param objects on stack. An alternative might be a C convention, for most classes have a unique id to allow distribution of the gamestate e.g. over network:
Function with 2x param count like this:
code:
int evc callback(EVENT_TYPE type, ...)
with an odd number of variable length arguments following: a list of pairs of arguments. The first argument of such a pair is an uint32 describing the type of the argument following. The second argument of a pair is the Event-Argument converted to a POD-Type (maybe even a void * pointer to a type). This would need additional time decoding the argument types, but perhaps less time then creating temporary objects on stack which must be destroyed after calling.
Both have the need of decoding the argument list passed to determine the objects passed.
A last possibility would be to write a call function for any valid argument type list that could be passed to it, i.e.
code:
class XY {
int call(EVENT_TYPE, const Unit &, const City &);
int call(EVENT_TYPE, const Army &, const City &);
int call(EVENT_TYPE, const Army &, const Army &);
...
};
|
|
| |
|
|
|
J Bytheway
|
|
England
Jul 2001
time: 05:31
|
|
quote:
Originally posted by ctplinuxfan
An alternative might be a C convention, for most classes have a unique id to allow distribution of the gamestate e.g. over network:
Function with 2x param count like this:
code:
int evc callback(EVENT_TYPE type, ...)
with an odd number of variable length arguments following: a list of pairs of arguments. The first argument of such a pair is an uint32 describing the type of the argument following. The second argument of a pair is the Event-Argument converted to a POD-Type (maybe even a void * pointer to a type). This would need additional time decoding the argument types, but perhaps less time then creating temporary objects on stack which must be destroyed after calling.
Both have the need of decoding the argument list passed to determine the objects passed.
A last possibility would be to write a call function for any valid argument type list that could be passed to it, i.e.
code:
class XY {
int call(EVENT_TYPE, const Unit &, const City &);
int call(EVENT_TYPE, const Army &, const City &);
int call(EVENT_TYPE, const Army &, const Army &);
...
};
|
Since all the non-POD types being passed inherit from ID, we could combine these two solutions to have something like
code:
class XY {
int call(EVENT_TYPE, ARG_TYPE, const ID &);
int call(EVENT_TYPE, ARG_TYPE, const ID &, ARG_TYPE, const ID &);
...
};
Where we have doubled argument lists as before to distinguish between different inheritors from ID, but we're able to pass the actual objects. This needs only one function for each possible number of arguments, rather than one function for each possible combination of arguments.
|
|
| |
|
|
|
ctplinuxfan
|
|
quote:
Originally posted by Frog_Gamer
I am a complete newbie as far as Linux is concerned, but I have played CTP2 for years now.
Due to the fact that I will have heart surgery next month, I should have plenty of time available to help.
In what way may I be of help?
My goal would be in the end to play CTP2 on my Linux Mandrake 10.2 system
regards to all and keeep up the good effort 
regards to all |
Great that you want to help.
For now, you could help us in porting, i.e. program to get CTP2 running on linux. If you want to do so, read the EULA, write a personal message or mail to kaan with a username and password you chose to access the source (and that you agree to the eula). If you are new to c++ programming, get a book at your library and feel free to ask what you don't understand.
Once your user has been setup, install subversion and run
code:
svn co --username yourusername svn://ctp2.kaan.dk/ctp2/branches/linux ctp2-br-linux
(where yourusername is the username you chose).
You can run ./autogen.sh ; ./configure ; make to start compilation of ctp2.
For coding, first, the errors which prevent the code from compilation have to be fixed, second the compiler warnings which may indicate bugs and finally when ctp2 runs probably fix runtime bugs and implement more and more features left out at the moment (networking, videos, ...).
As a first step, you could start compilation and post where it stops with the errors you get (not the warnings). I try to get it run on debian testing (gcc 3.3.5) and gentoo 2005.0 (gcc 3.4.3), but maybe things are also different on mandrake.
The other thing you could do is playtesting once ctp2 compiles under linux, but it will still last some time until we're at this point.
Get well soon and welcome to the team!
|
|
| |
|
|
|
ctplinuxfan
|
|
quote:
Originally posted by J Bytheway
Since all the non-POD types being passed inherit from ID, we could combine these two solutions to have something like
code:
class XY {
int call(EVENT_TYPE, ARG_TYPE, const ID &);
int call(EVENT_TYPE, ARG_TYPE, const ID &, ARG_TYPE, const ID &);
...
};
Where we have doubled argument lists as before to distinguish between different inheritors from ID, but we're able to pass the actual objects. This needs only one function for each possible number of arguments, rather than one function for each possible combination of arguments. |
In my opinion, this is the best idea.
Could you try to implement that by and by for the slic and gameevent handler? I will continue with the ui networking stuff once i have some time again.
|
|
| |
|
|
|
J Bytheway
|
|
England
Jul 2001
time: 05:31
|
|
OK, I've got my version compiling too, so I submitted revision 414 with my changes.
Along the way I fixed as many compiler warnings as I could, so there are rather a lot of changes. It would probably be wise to look them over.
Now the only warnings that need disabling to get the code to compile (at least in the C++ code) are -Wno-multichar -Wno-unused -Wno-format -Wno-switch -Wno-switch-enum -Wno-non-template-friend.
I'm now seeing linking errors mostly in the lexer/parser code complaining of duplicate definitions.
A couple of other points:
When I was comiling in a seperate tree, it fails to create the ctp2_code/ui/ldl directory, and so one of the calls to byacc fails.
Do we need to worry at this point about what symbols we are defining, e.g. _DEBUG?
Last edited by J Bytheway on 08-07-2005 at 07:30
|
|
| |
|
|
|
J Bytheway
|
|
England
Jul 2001
time: 05:31
|
|
OK, after fixing those I could, I'm left with the following linking errors:
code:
civ3_main.o(.text+0x7fd): In function `ui_Initialize()':
ctp2_code/ctp/civ3_main.cpp:508: undefined reference to `aui_SDLMouse::aui_SDLMouse[in-charge](AUI_ERRCODE*, char*, unsigned)'
CityData.o(.text+0xf3a7): In function `CityData::RemoveBorders()':
ctp2_code/gs/gameobj/CityData.cpp:6325: undefined reference to `terrainutil_RemoveBorders(MapPoint const&, int, int, int, Unit const&)'
wldgen.o(.text+0xb38): In function `World::~World [not-in-charge]()':
ctp2_code/gs/world/wldgen.cpp:271: undefined reference to `lt_dlclose'
wldgen.o(.text+0xb3d):ctp2_code/gs/world/wldgen.cpp:272: undefined reference to `lt_dlexit'
wldgen.o(.text+0xbf4): In function `World::~World [in-charge]()':
ctp2_code/gs/world/wldgen.cpp:271: undefined reference to `lt_dlclose'
wldgen.o(.text+0xbf9):ctp2_code/gs/world/wldgen.cpp:272: undefined reference to `lt_dlexit'
wldgen.o(.text+0xcb0): In function `World::~World [in-charge deleting]()':
ctp2_code/gs/world/wldgen.cpp:271: undefined reference to `lt_dlclose'
wldgen.o(.text+0xcb5):ctp2_code/gs/world/wldgen.cpp:272: undefined reference to `lt_dlexit'
wldgen.o(.text+0x7cb5): In function `World::LoadMapPlugin(int)':
ctp2_code/gs/world/wldgen.cpp:2800: undefined reference to `lt_dlinit'
wldgen.o(.text+0x7cd5):ctp2_code/gs/world/wldgen.cpp:2804: undefined reference to `lt_dlopen'
wldgen.o(.text+0x7cfe):ctp2_code/gs/world/wldgen.cpp:2809: undefined reference to `lt_dlexit'
wldgen.o(.text+0x7d1d):ctp2_code/gs/world/wldgen.cpp:2816: undefined reference to `lt_dlsym'
wldgen.o(.text+0x7d31):ctp2_code/gs/world/wldgen.cpp:2822: undefined reference to `lt_dlclose'
wldgen.o(.text+0x7d36):ctp2_code/gs/world/wldgen.cpp:2823: undefined reference to `lt_dlexit'
wldgen.o(.text+0x7d87):ctp2_code/gs/world/wldgen.cpp:2839: undefined reference to `lt_dlclose'
wldgen.o(.text+0x7d8c):ctp2_code/gs/world/wldgen.cpp:2840: undefined reference to `lt_dlexit'
wldgen.o(.text+0x7dc3): In function `World::FreeMapPlugin()':
ctp2_code/gs/world/wldgen.cpp:2865: undefined reference to `lt_dlclose'
wldgen.o(.text+0x7dc8):ctp2_code/gs/world/wldgen.cpp:2866: undefined reference to `lt_dlexit'
WrlEnv.o(.text+0x1960): In function `World::CutImprovements(MapPoint const&)':
ctp2_code/gs/world/WrlEnv.cpp:897: undefined reference to `terrainutil_RemoveBorders(MapPoint const&, int, int, int, Unit const&)'
spritefile.o(.text+0x698): In function `SpriteFile::WriteFacedSpriteData(FacedSprite*)':
ctp2_code/gfx/spritesys/spritefile.cpp:212: undefined reference to `FacedSprite::GetFrameDataSize(unsigned short, unsigned short)'
spritefile.o(.text+0x6d4):ctp2_code/gfx/spritesys/spritefile.cpp:213: undefined reference to `FacedSprite::GetMiniFrameDataSize(unsigned short, unsigned short)'
spritefile.o(.text+0xbda): In function `SpriteFile::WriteFacedSpriteWshadowData(FacedSpri
teWshadow*)':
ctp2_code/gfx/spritesys/spritefile.cpp:311: undefined reference to `FacedSpriteWshadow::GetFrameDataSize(unsigned short, unsigned short)'
spritefile.o(.text+0xc56):ctp2_code/gfx/spritesys/spritefile.cpp:327: undefined reference to `FacedSpriteWshadow::GetMiniFrameDataSize(unsigned
short, unsigned short)'
spritefile.o(.text+0xce5):ctp2_code/gfx/spritesys/spritefile.cpp:344: undefined reference to `FacedSpriteWshadow::GetShadowFrameDataSize(unsign
ed short, unsigned short)'
spritefile.o(.text+0xd61):ctp2_code/gfx/spritesys/spritefile.cpp:359: undefined reference to `FacedSpriteWshadow::GetMiniShadowFrameDataSize(un
signed short, unsigned short)'
spritefile.o(.text+0xdf3):ctp2_code/gfx/spritesys/spritefile.cpp:375: undefined reference to `FacedSpriteWshadow::GetFrameDataSize(unsigned short, unsigned short)'
spritefile.o(.text+0xe8a):ctp2_code/gfx/spritesys/spritefile.cpp:386: undefined reference to `FacedSpriteWshadow::GetMiniFrameDataSize(unsigned
short, unsigned short)'
spritefile.o(.text+0xf34):ctp2_code/gfx/spritesys/spritefile.cpp:398: undefined reference to `FacedSpriteWshadow::GetShadowFrameDataSize(unsign
ed short, unsigned short)'
spritefile.o(.text+0xfcb):ctp2_code/gfx/spritesys/spritefile.cpp:410: undefined reference to `FacedSpriteWshadow::GetMiniShadowFrameDataSize(un
signed short, unsigned short)'
aui_surface.o(.gnu.linkonce.r._ZTV11aui_Surface+0x20):ctp2_code/ui/aui_common/aui_surface.cpp:411: undefined reference to `aui_Surface::GetDC(hdc_t**)'
aui_surface.o(.gnu.linkonce.r._ZTV11aui_Surface+0x24):ctp2_code/ui/aui_common/aui_surface.cpp:411: undefined reference to `aui_Surface::ReleaseDC(hdc_t*)'
aui_ui.o(.gnu.linkonce.r._ZTV6aui_UI+0xf0):ctp2_code/ui/aui_common/aui_ui.cpp:65: undefined reference to `aui_UI::HandleWindowsMessage(hwnd_t*, unsigned, int, int)'
aui_Factory.o(.gnu.linkonce.t._ZN7aui_SDL2DDEv+0x4): In function `aui_SDL: D()':
ctp2_code/ui/aui_sdl/aui_sdl.h:31: undefined reference to `aui_SDL::m_lpdd'
aui_sdlsurface.o(.gnu.linkonce.r._ZTV14aui_SDLSurface+0x20):ctp2_code/ui/aui_sdl/aui_sdl.h:18: undefined reference to `aui_Surface::GetDC(hdc_t**)'
aui_sdlsurface.o(.gnu.linkonce.r._ZTV14aui_SDLSurface+0x24):ctp2_code/ui/aui_sdl/aui_sdl.h:18: undefined reference to `aui_Surface::ReleaseDC(hdc_t*)'
aui_sdlui.o(.text+0x4b2): In function `aui_SDLUI::CreateScreen(unsigned)':
ctp2_code/ui/aui_sdl/aui_sdlui.cpp:144: undefined reference to `aui_SDL::m_lpdd'
aui_sdlui.o(.text+0x915): In function `aui_SDLUI::RestoreMouse()':
ctp2_code/ui/aui_sdl/aui_sdlui.cpp:214: undefined reference to `aui_SDLMouse::aui_SDLMouse[in-charge](AUI_ERRCODE*, char*, unsigned)'
aui_sdlui.o(.gnu.linkonce.r._ZTV9aui_SDLUI+0xf0):ctp2_code/ui/aui_sdl/aui_sdlui.cpp:88: undefined reference to `aui_UI::HandleWindowsMessage(hwnd_t*, unsigned, int, int)'
c3ui.o(.gnu.linkonce.r._ZTV4C3UI+0xf0):ctp2_code/ui/aui_common/aui_resource.h:183: undefined reference to `aui_UI::HandleWindowsMessage(hwnd_t*, unsigned, int, int)'
segmentlist.o(.text+0xc1): In function `SegmentList::SegmentList[not-in-charge](void (*)(int), char*)':
ctp2_code/ui/slic_debug/segmentlist.cpp:69: undefined reference to `vtable for SegmentList'
segmentlist.o(.text+0x2df): In function `SegmentList::SegmentList[in-charge](void (*)(int), char*)':
ctp2_code/ui/slic_debug/segmentlist.cpp:69: undefined reference to `vtable for SegmentList'
sourcelist.o(.text+0xef): In function `SourceList::SourceList[not-in-charge](void (*)(int), char*)':
ctp2_code/ui/slic_debug/sourcelist.cpp:100: undefined reference to `vtable for SourceList'
sourcelist.o(.text+0x303): In function `SourceList::SourceList[in-charge](void (*)(int), char*)':
ctp2_code/ui/slic_debug/sourcelist.cpp:100: undefined reference to `vtable for SourceList'
watchlist.o(.text+0xf1): In function `WatchList::WatchList[not-in-charge](void (*)(int), char*)':
ctp2_code/ui/slic_debug/watchlist.cpp:86: undefined reference to `vtable for WatchList'
watchlist.o(.text+0x305): In function `WatchList::WatchList[in-charge](void (*)(int), char*)':
ctp2_code/ui/slic_debug/watchlist.cpp:86: undefined reference to `vtable for WatchList'
collect2: ld returned 1 exit status
These seem to fall into a few categories:
- UI stuff which isn'tthere because the appropriate SDL code is missing
- terrainutil_RemoveBorders not working, for reasons which escape me
- Lots of functions starting 'lt_dl' being missing
- Some functions in FacedSprite which are undefined (I checked and they seem to really be unimplmented - I think perhaps it's supposed to be calling the versions on the parent class).
- Peculiar problems with lists which I don't really understand.
Also, you seem to have abandoned the "helper library" idea - any particular reason?
Last edited by J Bytheway on 10-07-2005 at 00:43
|
|
| |
|
|
|
ctplinuxfan
|
|
Wow, great work!
quote:
Originally posted by J Bytheway
When I was comiling in a seperate tree, it fails to create the ctp2_code/ui/ldl directory, and so one of the calls to byacc fails.
Do we need to worry at this point about what symbols we are defining, e.g. _DEBUG?
|
Yes, i got that once as well, but waited for a possible addition of a conveniance library target for that dir as well. Perhaps we should meanwhile add a target for the directory ctp2_code/ui/ldl dependent on ctp2_code/ui dependent on ctp2_code.
For the makros we define, i think we should first look that everything works out of the box. We just need to ensure the cd check works, and later have to adopt as many flags as possible for the windows debug target (./configure --enable-debug) and the final build for release (no debug).
quote:
OK, after fixing those I could, I'm left with the following linking errors:
code:
wldgen.o(.text+0x7cfe):ctp2_code/gs/world/wldgen.cpp:2809: undefined reference to `lt_dlexit'
...
collect2: ld returned 1 exit status
|
You need to install libtool's libltdl.so and development files (on debian, it's in package libltdl3).
I merged further SDL related code, deactivated the slic_debug code and got a linked executable.
Now it's time to fix missing implementations (i get intended assertions of _splitpath() calls, which should be converted to string operations e.g. when just extracting the file extension to check if a filename ends with ".foo").
quote:
Also, you seem to have abandoned the "helper library" idea - any particular reason?
|
First only to get ctp2 to link. I'm not sure, whether the conveniance libraries may contain unresolved links on any platform (which they all do), if they may we can switch to that again later.
For the next steps, we need a copy of a ctp2 installation on a FAT16 or FAT32 partition mounted writable for the user.
These changes must be made to the linux copy:
- copy mapgen/.libs/*.so to the mapgen plugin directory in ctp2_program
- copy ctp2 executable to the ctp2_program/bin? path (where the .exe is located)
- copy ctp2_data/* files to the ctp2_data dir of the linux copy
- modify civ_paths.txt and userprofile.txt to contain / instead of \ and point to the plugin libraries ending with .so instead of .dll
TODO now is:
- replace _splitpath() calls by appropiate c code (preferably implement something like BOOL string_endswith(char *, char *))
- implement essential parts of mainloop (ctp/*)
- fix any assertion errors we find
- review font related code in case we get no text displayed
- review our last changes (mainly type related warnings we corrected; we must ensure the code behaves the same)
When we get a running game (mouse + sound only so far):
- make sure the cd check works under linux as well
- copy everything to a case sensitive filesystem and make game work there (something like convert every filename to lowercase when reading ldl files or accessing filesystem, and convert installation to lowercase)
- write xml file for loki_setup
- generate Makefile.am to copy files needed to path for installer image
- sync makro definitions win/linux and make sure code compiles as well (perhaps despite guarded code for linux like debugging aids and too system specific code)
- fix code to compile on windows again and merge back to /trunk (this will become a very large commit i fear)
After that, we reach milestone 1
Hope i didn't forget anything. And thanks again for your help so far!
|
|
| |
|
| |
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
|
|
|
|
|
|
14-01-2005 05:18
|