PPC 2.3.1 almost ready!

[virag0]

Good news everybody!

I have resolved the save game issue on 2.3.1 with PPC.
It does seem to be an endian problem.  The cp_save.c code has some methods
in it that converts via a function called "LittleLong" which does a byte swap.

Taking out these entries and assigning the variables without byteswapping now
allows the save/load of the slot data to both get a name and a time stamp.

I can do a patch if requested.....  ..the change was literally a no brainer.
I seem to recall doing the same thing in 2.3.0 but it didn't work, so the code must have
changed somehow...

When I work out why the intro prints out "intro_ sentence1" and so on intead of the actual text,
I will bundle up the PPC binaries required into a standalone app that should work on at least
PPC machines with an NVIDIA card.

Then I will have a go at 2.4......

[Mattn]

yes, please submit patches so we can fix it in 2.4

[virag0]

yes, please submit patches so we can fix it in 2.4

Matt,
please tell me how/where to send the very simple patch or if I can email upload it here.

I will submit the patch in GNU patch format, in any case.

Ok, I just found the attachment function here and so the patch is attached.
It is a simple diff so just cd into client/campaign and apply directly.

BTW, fixed the text intro issue.  It was just me not setting the language.

I am going to bundle this up now and post it up on google unless there
is somewhere better.   I will drop another post when I am done.

rachel

[geever]

please tell me how/where to send the very simple patch or if I can email upload it here.

We have a Patch Tracker.

I will submit the patch in GNU patch format, in any case.

Create unified diff, please (diff -u).

Thanks for the patch however I'm not sure you didn't broke it for little-endian systems now... We should test savegames between endianness (saving on big-endian then loading on little-endian and so..)

-geever

[virag0]

Undoubtly this will break little endian systems, because I have put any directives in.
If I was a bit better, I would write all the cpu arch directives in, but I am not really that good yet.
In this instance, I was just testing the hypothesis that PPC was being byteswapped, without
doing anything to the code except chopping out the offending function!

I will add the diif -u file tomorrow now, because I am offline ( it is 2:30am here)!

I have encountered another problem.   I wanted to create a bundle, to post online,
so that people can have a binary, but I am running into the issue with name_tool
where libsdl_mixer cannot be converted.   So the app only runs with the shared objects
in /opt/local/lib for now.   To make a packaged app bundled with its own library repo
means recompiling libsdl_mixer with some kind of ldflag that expands the headers,  but although
Ihink I have it, it gives the same error.   I think I have to use this header expansion in the linker
flags for the app, instead.  I will see tomorrow.....

[virag0]

I have just uploaded the contextualised version of the patch.  I think we need to throw
a few ifdefs into it, to check the architecture.  I need to remember how to do this. 
My usual environment is Solaris, but my home computer is a G5.  Please be kind to me,
as I am a humble hacker who does this instead of sudoku, but I never have enough time.


rachel

[virag0]

Here is the context diff attachment

[virag0]

And here is a UNIFIED version of the patch.   I can be such an idiot.....

[Mattn]

can you please also attach a savegame from your ppc?

[virag0]

Here it is....

[geever]

Here it is....

Was it created using your patch, wasn't it?
The problem that it doesn't load on x86 (neither with nor without your patch). Your patch is basically removing the compatibility between little endian and big endian systems and it's not that we want.

Please, attach a savegame created by the original code (best with a fresh 2.4-dev build) and the ufoconsole.log contains messages about the failed loading.

-geever

[virag0]

Was it created using your patch, wasn't it?
The problem that it doesn't load on x86 (neither with nor without your patch). Your patch is basically removing the compatibility between little endian and big endian systems and it's not that we want.

Please, attach a savegame created by the original code (best with a fresh 2.4-dev build) and the ufoconsole.log contains messages about the failed loading.

-geever

Yes, the patch I made merely drops the function call to "littleLong" in the cp_save.c file.   I did not say the patch was suitable for your
source repo - quite the opposite.   It is a dirty hack that proves something in littleLong isn't translating properly between x86 and PPC.

To work the bug out properly would obviously require more #ifdefs and checking and perhaps creating a "universal" file.
But as someone mentioned, the xml contained within is not vulnerable to byte swapping so there is something weird going on.
What that is, I do not know.   I am just doing ports of code to PPC as a distraction while on sick leave.

All I wanted to do was make 2.3.1 available on PPC in a reasonably stable format - I would only consider my patch as a pointer
to the bug which I suspect is in littleLong().   It is not a universal binary, nor is it an official one, if you guys want me to say that.    It is just what I got working on my Mac, by myself and I wanted to share it back. 

I will get the 2.4 repo on my Mac, when I am back at work, which will be ironic as then I won't be able to work on it as much.

[geever]

To work the bug out properly would obviously require more #ifdefs and checking and perhaps creating a "universal" file.

Byteswapping is done by SDL, so I guess something else is wrong here.

But as someone mentioned, the xml contained within is not vulnerable to byte swapping so there is something weird going on.

The savegame has a binary header, nothing weird here.

Unfortunately we don't have any big endian systems to test this function, we need your help with testing on this issue.

-geever