OK, I'll check that.Originally posted by J Bytheway
The command is something like svn switch --relocate OLD_REPOS NEW_REPOS. See svn help switch for more details.
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.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.
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.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.
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?
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?
look in the gfx/spritesys folder the sprite drawings should be there. If I understand what your asking.
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?
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.
Forgot to mention that there seem to be no special changes in ctp2_code/gfx/spritesys concerning the porting to linux.
What sort of unresolved dependencies? At what stage do they manifest?Originally posted by lynx_abraxas
Using any of the files of trunk/ctp2_code/gfx/spritesys results in other unresoved dependencies.
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:Originally posted by J Bytheway
What sort of unresolved dependencies? At what stage do they manifest?
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?
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.
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?
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
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?
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?
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?
It is a bit difficult to say, because I do not know which revisions you are comparing. I can see a possible conflict at theline. 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.Code:while(m = g_netfunc->GetMessage())
Does the additional pair of parentheses matter here at all?
Well I'm compairing rev 362 with the newest 737 of the linux branch to create the diff that I would like patch to fit into the newest trunk for merging the to together, such that in future the linux-game benefits of changes made to trunk that are OS independent. eg the sprite drawing... Which annoys me most
Anyway, patch has many rejects of changes to just one line where I wonder why it couldn't manage to apply the diff. Any idea why's that?
Semantically, no, but it quiets a (quite sensible) warning of gcc's, and indicates to the reader that you really meant to do an assignment, not a comparison.Originally posted by lynx_abraxas
Does the additional pair of parentheses matter here at all?
Well, after family crises and some health problems, I'm back. It looks like the port has come on some way since I last looked at it; the significant diff is down to around 600k.
I'm not sure how much time I'll be able to devote to the port at the moment, but I'll spend as much time as I can. I'm currently compiling with gcc 4.1.2 (openSuSE 10.2), and have a few compile fixes which I will commit later.
Is anyone monitoring this thread who has access to a Windows compile rig? I don't think any of these fixes will break the Windows build, and it would be nice to commit them to trunk as well, and stop the diff getting any bigger...
Tea: there is nothing it cannot fix.
r750 committed with anet compile fixes. It would be great if someone could test them on the Windows build - they shouldn't break it.
Tea: there is nothing it cannot fix.
I may be able to try it, but I'm pretty amateur. I'll report back with any problems/successes
It's great someone takes up work on the linux port again. Good decision Richard! I'm currently having too much work to do to any forther work on the merge. But in autumn I hope I'll find some time for it again.
A good massage: A friend of mine has tested the new commits and managed to play a full game through.
I'm afraid I haven't got as far as playing a game yet... when I click 'Launch', it dies with the 'Please make sure the Call to Power 2 CD-ROM is in your CD-ROM drive.' error. c3files_HasLegalCD() is returning false even though the CD is in my drive. I'm trying to work out why... I don't know SDL well.
Tea: there is nothing it cannot fix.
Ok, it seems that the reason c3files_HasLegalCD() is failing is because tracklen_CheckTrackLengths() is failing. And the reason *that* function is failing is because it can't open texture.dat.
Question: what is texture.dat, why should I care, and where can I get it from??
Tea: there is nothing it cannot fix.
Never mind, I found (and fixed) the problem. I've updated README.linux, too. Now I get a little further. I click launch, and the game starts to load. Everything comes up except for the map, whereupon I get a crash. Here's the output. Any suggestions?
All resolutions available.
ui/aui_ctp2/c3blitter.cpp L719: MMX-Test succeded!
Success: 1
Messagebox(Map Generator Error): Error while trying to load library 'dll/map/geometric.la': 'file not found'. Using builtin map generator
Continue?
Mouse PeepEvents failed:
Mouse PeepEvents failed:
Mouse PeepEvents failed:
Segmentation fault
Tea: there is nothing it cannot fix.
Ok, so it seems that 'make install' doesn't install the libraries into dll/.
*makes a note of something else to fix*
Onward!
Tea: there is nothing it cannot fix.
I did it this way:
make bootstrap
./configure --prefix=/home/lynx/CTP2 --bindir=/home/lynx/CTP2/ctp2_program/ctp
make
make install
follow doc/README.linux
- put everything on vfat in /mnt
- modify userprofile.txt in /mnt/ctp2/ctp2_program/ctp
cp /media/cdrom/Setup/data/Add/ctp2_program/ctp/texture.dat /mnt/ctp2/ctp2_program/
cd ~/sda1/ctp2_source/ctp2_code/mapgen/.libs
cp crater.la crater.so geometric.la geometric.so plasma2.la plasma2.so /mnt/ctp2/ctp2_program/ctp/dll/map/
No warrenty this is complete
That's basically what I did. There are possibly better ways of doing it, but for now I want to focus on merging.
Tea: there is nothing it cannot fix.
r754 checked in, with lots of trivial merges in ctp2_code/ctp/ctp2_utils. Diff in that directory reduced to 80k, much of which is whitespace and comment that needs to be merged into trunk.
Tea: there is nothing it cannot fix.
r756: more merging in ctp2_code/ctp/ctp2_utils. Diff is down to 53k. I've merged some changes into trunk, too.
Tea: there is nothing it cannot fix.
need me to test it?
Posting Permissions
Reply With Quote
Bookmarks