COMPILE: Linux Port

[J Bytheway]

Originally posted by lynx_abraxas
Forgot: How did You take the screenshot? Is there a function like in CTP1 with the print-key?

I had the game windowed and used the Gnome screenshot applet (I probably cut off the rest of the screen using the gimp or some such thing).

[Fromafar]

Originally posted by lynx_abraxas
[Lots of questions]

Wow! So many questions. Looks like you are really delving into this .

About the base line: you are using the linux branch. It has revision 670, but the latest changes are only to get it compile with gcc 4.1. For the functional code, you are missing lots of modifications from the trunk. I think the last merge attempt was around revision 550. After that, all development has been done on the trunk (Windows) branch only, without much effort to keep the branches in sync.
We did try to iron out some language issues when porting it to MSVC2005 (being much more standard C++ compliant than MSVC6), so hopefully getting it to compile for linux will not be harder than before.

Maybe you could try to reapply the linux branch changes (where needed) to the latest trunk revision. This should be much less work than trying to reapply the 150 or so trunk revision modifications to the linux branch.

ScienceManagementDialog::CreateAdvanceItem contains the SetUserData call. Looks like you found it already.
It really is just an index. If you insist, you could encapsulate it when storing, along the lines of

sint32 * container = new sint32;
*container = GetIndexValue();
SetUserData(container);

Of course you should not forget to delete the container object when destroying the list. In the case of these simple indices, I am afraid this might be just a lot of useless overhead. For an example where pointers are being used, have a look at the CityEspionage::m_inventoryList handling in the trunk. Eventually, we managed to solve the memory leaks JBytheway hinted at. But the solution is not pretty - the way MSVC6 supports templates is somewhat funny.

About the assembly code: converting to C++ is OK. Note that there are some pieces that have been "converted" just enough to make it compile with GCC, but are basically unfinished. Some relations between registers have been lost in the code conversion, so I imagine this could cause problems. E.g. edx and dx have been defined as (unrelated) variables in the conversion. In reality, dx denotes the low 16 bits of edx, so defining it as a union would have been more appropriate.

[lynx_abraxas]

Originally posted by Fromafar

About the base line: you are using the linux branch. It has revision 670, but the latest changes are only to get it compile with gcc 4.1. For the functional code, you are missing lots of modifications from the trunk. I think the last merge attempt was around revision 550. After that, all development has been done on the trunk (Windows) branch only, without much effort to keep the branches in sync.

Just to see, if I can get this straight: tunk is for windows and has some parts where the linux branch was sync into trunc. This sync wasn't done completly to what is in the linux branch?

We did try to iron out some language issues when porting it to MSVC2005 (being much more standard C++ compliant than MSVC6), so hopefully getting it to compile for linux will not be harder than before.

Well I'm working on the linux branch because trunk didn't compile under Linux with gcc. configure even doesn't do as much as the linux branch one does. It stops here:

configure: creating ./config.status
config.status: creating GNUmakefile
config.status: creating ctp2_code/Makefile
config.status: creating ctp2_code/ctp/Makefile
config.status: creating ctp2_code/gs/Makefile
config.status: creating ctp2_code/gs/dbgen/Makefile
config.status: creating ctp2_code/gs/newdb/Makefile
config.status: creating ctp2_code/mapgen/Makefile
config.status: creating ctp2_code/os/include/config.h
config.status: ctp2_code/os/include/config.h is unchanged
config.status: executing depfiles commands

So make can't work. I don't have any knowlege of how to extend configure.

Maybe you could try to reapply the linux branch changes (where needed) to the latest trunk revision. This should be much less work than trying to reapply the 150 or so trunk revision modifications to the linux branch.

I'd prefer to work on trunk if someone could help me with configure and possibly make later. I wonder if trunk ever compiled under linux?
What was the reason the linux branch got opened? Why wasn't trunk not modified for linux from the beginning?

About the assembly code: converting to C++ is OK. Note that there are some pieces that have been "converted" just enough to make it compile with GCC, but are basically unfinished. Some relations between registers have been lost in the code conversion, so I imagine this could cause problems. E.g. edx and dx have been defined as (unrelated) variables in the conversion. In reality, dx denotes the low 16 bits of edx, so defining it as a union would have been more appropriate.

I don't know what is ment by union but I managed to port the tile blending to gcc inline asm. Only thing that's left is to figure out if it is possible to have -fPIC and to use all six registers plus ebp. I don't know how to push the ebx that PIC uses before all my six input oparands are loaded. Any idea?

Well, last but not least I still haven't resolved this arefact bug. Last thought was: The targa-file loading functions might be doing something wrong for SDL. SDL can only display BMP. Are original rim-files also targa? Or do they have their own loader which in contrast could work well with SDL?

The screen shot below is when the main surface is in 15bpp which I think looks pretty much like the added pics drwan badly in normal 16bpp mode. So I still believe the sixth bit of 565 is at the wrong place when SDL displays the pics.

Thanks for all the answers.

[lynx_abraxas]

Originally posted by Fromafar

About the base line: you are using the linux branch. It has revision 670, but the latest changes are only to get it compile with gcc 4.1. For the functional code, you are missing lots of modifications from the trunk. I think the last merge attempt was around revision 550. After that, all development has been done on the trunk (Windows) branch only, without much effort to keep the branches in sync.

Just to see, if I can get this straight: tunk is for windows and has some parts where the linux branch was sync into trunc. This sync wasn't done completly to what is in the linux branch?

We did try to iron out some language issues when porting it to MSVC2005 (being much more standard C++ compliant than MSVC6), so hopefully getting it to compile for linux will not be harder than before.

Well I'm working on the linux branch because trunk didn't compile under Linux with gcc. configure even doesn't do as much as the linux branch one does. It stops here:

configure: creating ./config.status
config.status: creating GNUmakefile
config.status: creating ctp2_code/Makefile
config.status: creating ctp2_code/ctp/Makefile
config.status: creating ctp2_code/gs/Makefile
config.status: creating ctp2_code/gs/dbgen/Makefile
config.status: creating ctp2_code/gs/newdb/Makefile
config.status: creating ctp2_code/mapgen/Makefile
config.status: creating ctp2_code/os/include/config.h
config.status: ctp2_code/os/include/config.h is unchanged
config.status: executing depfiles commands

So make can't work. I don't have any knowlege of how to extend configure.

Maybe you could try to reapply the linux branch changes (where needed) to the latest trunk revision. This should be much less work than trying to reapply the 150 or so trunk revision modifications to the linux branch.

I'd prefer to work on trunk if someone could help me with configure and possibly make later. I wonder if trunk ever compiled under linux?
What was the reason the linux branch got opened? Why wasn't trunk not modified for linux from the beginning?

About the assembly code: converting to C++ is OK. Note that there are some pieces that have been "converted" just enough to make it compile with GCC, but are basically unfinished. Some relations between registers have been lost in the code conversion, so I imagine this could cause problems. E.g. edx and dx have been defined as (unrelated) variables in the conversion. In reality, dx denotes the low 16 bits of edx, so defining it as a union would have been more appropriate.

I don't know what is ment by union but I managed to port the tile blending to gcc inline asm. Only thing that's left is to figure out if it is possible to have -fPIC and to use all six registers plus ebp. I don't know how to push the ebx that PIC uses before all my six input oparands are loaded. Any idea?

Well, last but not least I still haven't resolved this arefact bug. Last thought was: The targa-file loading functions might be doing something wrong for SDL. SDL can only display BMP. Are original rim-files also targa? Or do they have their own loader which in contrast could work well with SDL?

The screen shot below is when the main surface is in 15bpp which I think looks pretty much like the added pics drwan badly in normal 16bpp mode. So I still believe the sixth bit of 565 is at the wrong place when SDL displays the pics.

Thanks for all the answers.

[J Bytheway]

Originally posted by lynx_abraxas
Just to see, if I can get this straight: tunk is for windows and has some parts where the linux branch was sync into trunc. This sync wasn't done completly to what is in the linux branch?

Trunk is indeed intended for Windows. It has never compiled under Linux. Some Linux branch changes have been back-ported to trunk, but I don't think anything systematic has been attempted.

I'd prefer to work on trunk if someone could help me with configure and possibly make later. I wonder if trunk ever compiled under linux?

It didn't.

What was the reason the linux branch got opened? Why wasn't trunk not modified for linux from the beginning?

Because the main Linux developer had no access to Windows, and so couldn't check his changes didn't break the Windows compile. MSVC is so different from gcc that anyone porting to Linux is inevitably going to wreak havoc with the Windows version. Things are better now we've been able to move away from MSVC6, but it's still not good.

The screen shot below is when the main surface is in 15bpp which I think looks pretty much like the added pics drwan badly in normal 16bpp mode. So I still believe the sixth bit of 565 is at the wrong place when SDL displays the pics.

It looks like you might be on to something. I'm glad someone is able to make progress here - I had no idea where to start with the graphics problems.

[lynx_abraxas]

Because the main Linux developer had no access to Windows, and so couldn't check his changes didn't break the Windows compile. MSVC is so different from gcc that anyone porting to Linux is inevitably going to wreak havoc with the Windows version. Things are better now we've been able to move away from MSVC6, but it's still not good.

This is a real pitty. Code changes to trunk that don't concern directx or asm would probably work fine also under linux. When a change to asm is done just then a copy of trunk should be made to branch/linux until someone solves the problem for linux and then right back to trunk...

I wonder why not use djgpp for windows? This is gcc for windows for those who don't know. Except for the at&t asm syntax it's the best compiler the master coder at my uni has tested;-)

Then who of those who ansered me worked or work on the linux branch? Am I the only one now? :-(

I can't promise my modificatons to the linux branch are the best but for me they improved the programme. Should I commit them to the branch/linux and if so how to do that?

[lynx_abraxas]

Something I always forgot:

The mouse pointer is redrawn very often. It seems to me there is no delay put into that thread nor is checked if it has moved at all and needs to be redrawn.
When I put the mouse on the menu I can see the frequent drawing because it switches between artefact on the whole mouse and then some part is drawn correctly. I managed to catch a screenshot of that:
What are the files that draw the mouse pointer?
When I play the game at 1280x1024 the game slows down quite a bit. Any idea what else could cause this?

[J Bytheway]

Originally posted by lynx_abraxas
This is a real pitty. Code changes to trunk that don't concern directx or asm would probably work fine also under linux.

You'd think that, but it rarely turns out to be so simple. There are lots of little ways in which gcc and the MS compiler differ, and it's hard to keep track of them.

When a change to asm is done just then a copy of trunk should be made to branch/linux until someone solves the problem for linux and then right back to trunk...

I wonder why not use djgpp for windows? This is gcc for windows for those who don't know. Except for the at&t asm syntax it's the best compiler the master coder at my uni has tested;-)

Then who of those who ansered me worked or work on the linux branch? Am I the only one now? :-(

I've done quite a bit of work on it in the past, but I've had to stop now.

I can't promise my modificatons to the linux branch are the best but for me they improved the programme. Should I commit them to the branch/linux and if so how to do that?

It's probably worth comitting them, yes. First you need to get write access to the repository, if you don't already. See http://ctp2.darkdust.net for more details. Once you've got that you'll need to relocate your working copy to point to the version of the repository where you have write access. Then, assuming you checked your copy out with svn, you should be able to commit your changes with "svn ci". I suggest doing "svn diff" first to double-check exactly what you changed.

[lynx_abraxas]

Once you've got that you'll need to relocate your working copy to point to the version of the repository where you have write access.

I don't get what You mean here. Could You explain that a bit more?

I've done quite a bit of work on it in the past, but I've had to stop now.

That's a real pitty! I could need some help

Well, I had the idea to check the mouse pointer in gimp by splitting up the channels of the screen shot. It shows that all channels have these artefacts. This means that it can't be a 555 <-> 565 problem because then one colour channel would always be correct. Except the colours change through taking the screen shot. Could that be?

I've ported a few asm inlines. All of them work perfectly except the one doing the tiletransitions outside FOW (not darkened). Could anybody check if the code of ctp2_code/gfx/tilesys/tiledraw.cpp from the LINUX branch works well under M$ windows? I'm getting a segfault in the asm part. Any ideas how to debug that?

[lynx_abraxas]

red channel

[lynx_abraxas]

green channel

[lynx_abraxas]

blue channel

[J Bytheway]

Originally posted by lynx_abraxas
I don't get what You mean here. Could You explain that a bit more?

The command is something like svn switch --relocate OLD_REPOS NEW_REPOS. See svn help switch for more details.

Well, I had the idea to check the mouse pointer in gimp by splitting up the channels of the screen shot. It shows that all channels have these artefacts. This means that it can't be a 555 <-> 565 problem because then one colour channel would always be correct. Except the colours change through taking the screen shot. Could that be?

Possibly, if you used a lossy encoding for the screenshot, but I doubt you would have. I am interested to note that the red channel looks much worse than the other two.

I've ported a few asm inlines. All of them work perfectly except the one doing the tiletransitions outside FOW (not darkened). Could anybody check if the code of ctp2_code/gfx/tilesys/tiledraw.cpp from the LINUX branch works well under M$ windows? I'm getting a segfault in the asm part. Any ideas how to debug that?

Does gdb not handle asm well? Generally I attack segfaults first with gdb and (if that fails) with valgrind. I never tried running CTP2 under valgrind, though - it might be excruciatingly slow.

[Ekmek]

Originally posted by lynx_abraxas


I don't get what You mean here. Could You explain that a bit more?

the repository is where we store the source code. its managed by darkdust and once you have a password etc you can commit your changes so that other linux users have access to them. hope that helps.

if you have the 600 or so linux revision i assume you already have access though.

[lynx_abraxas]

I did it! Found the bugger! Some SDL code circumvented the special targa load which does 555->565 conversion!
Also I made the error of taking the screenshot in jpg. I'll check if my assumptions are right if the shot is in png. So for the enjoyment here's a screenshot again: