COMPILE: Linux Port

[lynx_abraxas]

Originally posted by J Bytheway


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

OK, I'll check that.

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.

Thanks J Bytheway! With all these pixel transformations I didn't think about that. I'm just wondering why these changes get into the other channels when using lossy compression? Below the analysis with png.

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.

Well gdb just tells me the end of the ca 20 lines of asm code, which isn't really an aid. This could come from -O2 switch to gcc. The problem is without it gcc can't manage to get the register pushed before my code comes.
There is no difference in the asm code of the linux branch to the trunk. So if trunk works fine when drawing non FOW tiles the bug has to be in my translation. So is all fine in trunk compiled under MSC?

[lynx_abraxas]

Yeah, forgot something again...
Next bug I want to solve is either having the sprites stay visible even after animation or fix the drawing of the mouse pointer rect.
By that I mean the displacement that takes place when the mouse moves over the civ menue. Could this be a lack of surface locking? Also the chroma key gets drawn after the mouse went over the list of tile improvements.
Does anybody have ideas where to start for these to problems?
Where do the sprites get drawn/animated?

[Ekmek]

look in the gfx/spritesys folder the sprite drawings should be there. If I understand what your asking.

[lynx_abraxas]

Thanks E for the starting point, I'll check gfx/spritesys.

For syncronising the linux branch to trunk I have the idea to do diffs agains the revision of trunk when it was cloned to the linux branch. Then use these diffs to run patch on the current trunk. What do You think about that aproach? How would I find out the revision that was used for cloning? Does anybody remember perhaps?

[lynx_abraxas]

gfx/spritesys is a total mess in the linux branch! It seems there was development going on in trunk at the time the linux clone was created. The mess in trunk seems to be cleaned up but of corse not in the linux branch.
The problem I now encountered are the big changes that were made in trunk gfx/spritesys. Using any of the files of trunk/ctp2_code/gfx/spritesys results in other unresoved dependencies. I fear that syncronising trunk and linux is less work then trying to repare ctp2_code/gfx/spritesys in the linux branch.
Is there anyone who can assist and help me out on that task?
For I have no knowlege so far about creating the input files for autoconf or automake such that they work under linux.
Else wise my debugging contribution will probably here.

[lynx_abraxas]

Forgot to mention that there seem to be no special changes in ctp2_code/gfx/spritesys concerning the porting to linux.

[J Bytheway]

Originally posted by lynx_abraxas
Using any of the files of trunk/ctp2_code/gfx/spritesys results in other unresoved dependencies.

What sort of unresolved dependencies? At what stage do they manifest?

[lynx_abraxas]

Originally posted by J Bytheway


What sort of unresolved dependencies? At what stage do they manifest?

Well, I copied the files from trunk/ctp2_code/gfx/spritesys to the linux branch dir. Sadly they again need changes else were in ctp2_code. One is:
AdvanceBranchRecord.h:43: error: 'CivArchive' has not been declared
I think following all unresolved dependencies to changes in trunk but not in linux branch leads to syncronising the linux branch to trunk.
So this brings me back to an earlier qutestion: How can I figure out the revison that was used to clone when starting the linux branch.
Or if the linux branch was ever syncronised with trunk that last revision. I would then make diffs to that revision and use patch to fit them into trunk.
I have the hope patch can do a good job here because most linux port changes are in bigger blocks. The only changes for linux I saw were for SDL and asm. That would only leave adjusting autoconf and automake and the net library. What do you think?

[Fromafar]

The problem of the generated *Record.h files missing the CivArchive declaration has been repaired in the trunk. See the gs/dbgen directory. This contains a separate program (dbgen.exe), which is used to generate the *Record.h and cpp files from the cdb text files in gs/newdb.

The linux branch was created in revision 363 (from revision 362). There never have been any full synchronisations - only partial synchronisations on file level.

[lynx_abraxas]

When doing svn di to check my changes in detail I get for nearly every file a change in the Id tag like this:
-// Id : $Id:$
+// Id : $Id$

Why's that and how can I prevent this at least for checking my changes locally?

[lynx_abraxas]

Ok, found the reason and a workaround:

The files listed are those that I had modified but removed the modification later. svn just knows modified and runs diff over it even if no modification is left for diff.
I worked around that with:
svn --diff-cmd /usr/bin/diff -x '-uBb -I \$.*Id.*' di

[lynx_abraxas]

Back again after a brake.
I started to check the idea to use patch to create a sync for trunk. My result so far is 832 files that have rejects. Looking at a few of them I noticed most of them are rejects caused by ws lines that were removed but are not just '\n'. That I think should be improveable with the normal diff and patch.
The other rejects often come from added "const" before some vars. I don't see the reason why patch has problems with those. A way out would be to use a word for word (wordwise) diff and patch. Does anybody know of a pair of good ones?

[lynx_abraxas]

Does anybody know why I get hunks like this one with
diff -awN -U 3 -I "^[ \t]*$" ../ctp2_clone/ctp2_code/ui/netshell/serverselectwindow.cpp ctp2_code/ui/netshell/serverselectwindow.cpp |cat -A

@@ -169,14 +156,6 @@$
^I$
$
$
-$
-$
-$
-$
-$
-$
-$
-^I$
^I((aui_ListBox *)m_controls[ CONTROL_SELECTSERVERLISTBOX ])->$
^I^ISetForceSelect( TRUE );$
$
@@ -186,13 +165,11 @@$

According to this http://www.gnu.org/software/diffutil...fied%20Folding
it should skip these changes, shouldn't it?

[lynx_abraxas]

OK. **** happens... grep and diff -I don't understand '\t'. Great, aren't they?
Now using:

for i in "*.h" "*.[hc]pp"; do ls $i 2> /dev/null ; find ctp2_code/ -name $i -exec diff -awN -u -I '^[ ]*$' ../ctp2_clone/{} {} >> merge11.diff \;; done

and

patch -p0 --dry-run -l -N -F 3 < ../ctp2/merge11.diff |grep "FAILED.*\.." |wc -l

Tells me there are 481 files with rejects. An example is:

cat -A ctp2_code/ui/netshell/serverselectwindow.cpp.rej
***************$
*** 1,13 ****$
- $
- $
- $
- $
- $
- $
- $
- $
- $
- $
$
#include "c3.h"$
$
--- 1,32 ----$
+ //----------------------------------------------------------------------------$
+ //$
+ // Project : Call To Power 2$
+ // File type : C++ source$
+ // Description : Multiplayer server select window$
+ // Id : $Id: serverselectwindow.cpp 720 2007-04-12 14:24:53Z lynx $$
+ //$
+ //----------------------------------------------------------------------------$
+ //$
+ // Disclaimer$
+ //$
+ // THIS FILE IS NOT GENERATED OR SUPPORTED BY ACTIVISION.$
+ //$
+ // This material has been developed at apolyton.net by the Apolyton CtP2 $
+ // Source Code Project. Contact the authors at ctp2source@apolyton.net.$
+ //$
+ //----------------------------------------------------------------------------$
+ //$
+ // Compiler flags$
+ //$
+ // - None$
+ //$
+ //----------------------------------------------------------------------------$
+ //$
+ // Modifications from the original Activision code:$
+ //$
+ // - Initialized local variables. (Sep 9th 2005 Martin GM-|hmann)$
+ //$
+ //----------------------------------------------------------------------------$
$
#include "c3.h"$
$
***************$
*** 78,88 ****$
}$
$
$
- $
AUI_ERRCODE ServerSelectWindow::CreateControls( void )$
{$
- ^IAUI_ERRCODE errcode;$
- $
$
^I$
$
--- 90,98 ----$
}$
$
$
AUI_ERRCODE ServerSelectWindow::CreateControls( void )$
{$
+ ^IAUI_ERRCODE errcode = AUI_ERRCODE_OK;$
$
^I$
$
***************$
*** 233,239 ****$
^Idp_objectDelta_packet_t *p;$
^I$
^Iif(g_netfunc) {$
- ^I^Iwhile(m = g_netfunc->GetMessage()) {$
^I^I^I$
^I^I^I$
^I^I^I$
--- 209,215 ----$
^Idp_objectDelta_packet_t *p;$
^I$
^Iif(g_netfunc) {$
+ ^I^Iwhile((m = g_netfunc->GetMessage())) {$
^I^I^I$
^I^I^I$
^I^I^I$

Does anybody see, why patch has problems here? Any suggestions what could reduce the amount of rejects further?

[Fromafar]

It is a bit difficult to say, because I do not know which revisions you are comparing. I can see a possible conflict at the

while(m = g_netfunc->GetMessage())

line. The trunk and the linux branch have solved the "assignment in condition" warning differently. In the trunk, the variable declaration of m has been moved to the condition, while the linux branch has merely added another pair of parentheses.