[Scummvm-devel] PS2 ScummVM 0.11.x updates!

[Max Horn]

Hi there,

will try to answer your questions. Luckily, Eugene already replied to  
some of them, in particular the video stuff, and I'll try not to  
repeat everything he said :-).


Am 14.02.2008 um 01:29 schrieb sunmax at libero.it:
>

>>> I would also recommend to make them available
>
> Sure thing! Is there a scummvm-place when I can upload them?
> Or should I send their tarball to you together with the PS2 patch
> in a few days?

As Eugene said, these could be put into our vendor/ SVN module. With  
cxxtest, I tried to roughly follow the "Vendor branch" guidelines  
from the SVN book, see here: <http://svnbook.red-bean.com/en/1.4/ 
svn.advanced.vendorbr.html>. So in brief, you'd do this:

1) Make a subdir for each "project" you need to modify, e.g. one for  
mpeg2dec, one for tremor, ...).
2) In there, make a subdir which will later host the *official*  
source code. Maybe using the version. E.g.
    vendor/mpeg2ded/0.4.1
would contain the contents of the offical tarball
3) "svn copy" this to a new dir, e.g.
    vendor/mpeg2dec/current-ps2
4) Apply your modifications to this copy

The idea here being that one can easily get a version of the full  
modified sources, but can also easily extract a patch, and also can  
easily update to new versions (using the svn_load_dirs.pl script).

BUT: For software which only changes very rarely, it might also be  
sufficient to store a .patch file against the latest source. E.g.  
mpeg2dec hasn't changed for over a year, and then it was only a bug  
fix release, the last release for that being from January 2004. So,  
it might be sufficient to distribute a patch against 0.4.1 (e.g. put  
that patch into the backends/platform/ps2/ dir in SVN).

[...]

> One question regarding the building process.
>
> The PS2 backend (like the PSP) contains a do-it-all makefile,
> it's that an accepatable solution for now?
>
> Should we on the long run port it to a 'configure'-friendly
> build process or it really does not matter?

As Eugene said, it's OK that you use a custom Makefile. And it's not  
mandatory to switch to our base "configure && make" build system.

However, if it's sanely possible, I still recommend moving to it.  
Being able to issue a simple
  ./configure --backend=ps2 && make
(resp. (./configure --backend=ps2 --host=mips-ps2-WHATEVER && make")
in order to build ScummVM (assuming the dev tools have been setup  
properly) is just so much easier for people interested in compiling  
ScummVM themselves. In particular, it makes it easier for them to  
contribute, too ;-)

Second best is to at least use Makefile.common, i.e. provide your own  
master Makefile, but reuse as much of our existing build system as  
possible. The DS port does that, for example, and probably some others.

The advantage here being that at least you don't have to worry about  
added/removed files in each engine.


[...]

>
>>>>> "Completely reworked internal access to files"
>
>>> Filipos wrote a bit about that already.
>
> Hey Filipos sorry if it took me so long, I thought I already replied
> to you but from my other account (GUE Tech one) only now I realize
> that mail bounced back. My sf account is 'sunmax' too. Thanks for
> the support.
>
> I think I got exists / isReadable / isWritable / lastPathComponent in
> place.

Great!

>
> Do I have a way to test it? Or the fact itself that the games I tested
> (Dig, Sam&Max, MI1/2 for now) are working is a sign that I got it
> right?

Not really. But e.g. the detector of Broken Sword 1 makes heavy use  
of exists(). So, try detecting and running that game (the demo should  
suffice). Then try running it after e.g. removing "swordres.rif" --  
it should complain about a missing file (well,  I *think* it should,  
I only glanced at the source and didn't have a way to test it yet).



>
> I saw "listSavefiles" changed too (now it returns Common::StringList),
> but some backends (e.g. 'ds') have just stubs for it. And others
> (e.g. 'palm') they are still using "void ... ::listSavefiles(const
> char *prefix, bool *marks, int num)" version. Who wins?

As Eugene said, common/savefile.h wins, and it also contains a  
Doxygen comment documenting this API. See also <http://scummvm.org/ 
docs/doxygen/html/classCommon_1_1SaveFileManager.php>.

(While looking at our Doxygen pages, I noticed that the script  
updating them broke in December. Sadly, nobody noticed, resp. nobody  
told me :/ But I'll fix it ASAP).

>
> Can somebody describe the semantics of the new "Common::StringList ...
> ::listSavefiles(const char *pattern)"? Is it as simple as returning
> a list of files that match the pattern?

Aye, see above, and also see the code in <backends/saves/default/ 
default-saves.cpp> for the reference implementation. You can use  
Common::matchString from common/util.h to perform the string  
matching, too.

> Is that in cwd? What happened
> to 'prefix' and 'num' arguments

Don't mind about prefix and num, this is an old obsolete API and not  
used anymore. You can just ditch that code (well, and maybe recycle  
parts of it for the new listSaveiles).




>
>  [4. Textures] ------------------------------------------------------
>
>  (This is most likely a question for Robert, I will send him a  
> personal
>  mail too)

Indeed, Robert has to answer these, I am afraid.

[...]
>
>  [5. TODO] ---------------------------------------------------------
>
> Ok this is a list of things I'd like to sort out before committing a
> patch for ScummVM 0.11.1.
>
> 1) get hdd working again
>    [it still enters a never-ending loop in:
>
>      while(((res = SifBindRpc(&cd0, PWROFF_IRX, 0)) >= 0) &&
>        (cd0.server ==  NULL)) nopdelay();
>
>         ^-- thats's in the PS2 SDK]
>
> 2) finalize new files access method

Good. You may have noticed some PS2 specific code in e.g. common/ 
file.cpp. Our plan is to eventually make these evil #define hacks go  
away in favor of a truly replaceable "file" backend module (i.e.  
class File will stay as an API, but the code will change, with  
various implementations under backend/file/

BTW, you may want to search through the full ScummVM code for all  
uses of __PLAYSTATION2__ and check whether they are still needed /  
require cleanup.

>
> 3) cleanup on exit
>    [btw: what is scummvm supposed to do on exit? On a PS2 it should
>          get back to the game launch menu, otherwise you have to
>          reboot all the times... does this require a core change
>          or is it doable just in the backend?]

Core change. This is an old request. We really need to do that. Well,  
actually, we already could do that, but it will require changes to  
some of the engines, and we have to start searching for memory leaks,  
too. And of course engines would need a way to distinguish between  
"Quit" and "Return to launcher". See also
* <http://wiki.scummvm.org/index.php/TODO#General_3>
* <http://wiki.scummvm.org/index.php/User:Fingolfin#GUI>

[...]

> 7) timididy ?
>
> Max, I did not get what you mean with "It's", does it mean
> that we -must- have it in place for ScummVM PS2 0.11.1 to happen?

Sorry, my mail was incomplete, seems I sent it before having fully  
completed it.

What I meant to say was: It's not at all necessary to support  
timidity. Which MIDI/music drivers (or for that matter, graphics  
scalers) your backend supports is up to you. If fluidsynth works well  
and timidity doesn't, that's fine. If the PS2 has some other means to  
playback MIDI files which other platforms don't have: that could be  
used, too. E.g. we have a MIDI driver for Windows or Mac OS X only  
(see backends/midi/).



Cheers,
Max