[Scummvm-devel] PlayStation2 Backend Updates & Patch!

[Max Horn]

Am 17.07.2008 um 17:46 schrieb sunmax at libero.it:

> Ciao Max & Team!

Hi Max ;)

>
>
> I will be able to get back to PS2 tonight or tomorrow,
> if in the meanwhile you could go ahead and commit on my
> behalf (sorry!) that would speed things up, I am still
> a bit scared about commiting to the trunk ;-)

Done.

> My fear will pass over time!

You'll manage :)

>
[...]
>
> Anyway I have plenty of ScummVM/PS2 time in August
> so I will try to give it a boost!

Great!

>
>
>
>>> Checking for EISDIR won't work with mass:.
>
> That was addressed in release 0.11.0 but never made it
> to the trunk, if we commit my patch, this will get
> sorted automatically ;-)

Well, can you do that? If you send me a patch, I can also commit it  
for you, but it's difficult for me to determine what needs backporting  
from 0.11.0 and what not.
>
>
[...]

>>> TocManager is buggy and the whole caching system needs
>>> a rewrite
>
> I fully agree. It's "patched in my patch", but in urge of
> a rewrite and integration with ScummVM File & Nodes.
>
> Am I allowed to fix this for 0.12.0 or this kind of change
> will have to wait for the next release (maybe safer).

As long as your changes are restricted to backends/platform/ps2, you  
are virtually free to do what you deem necessary. If you need to make  
changes outside, you best consult with Eugene and me first. As a rule  
of the thumb if it's "#ifdef PS2" only, it should be OK, at least as a  
temporary measure.



>
>
>
>>> Ps2UsbSaveFileManager
>
>>> needs an intermediate abstract class
>
> Yes.
>
> My vision is a unified save/config filemanager that will let
> you store your saved games and config files on any RW media:
> MC, USB, HD, remote.
>
> I can surely use some of his code in our future integrated
> PS2 filemanager.

Sure. The config file handling in ScummVM needs to be improved, for  
sure: They are in many ways like save files (can be written to, user  
specific), but we can't just use the savefile manager, because they  
may be stored in other locations (and on some ports, we get the  
savepath from the config file, so we can't store it under the  
savepath ;). Also, on some ports, the user can override the default  
config file. We currently lack a proper way to abstract access to the  
config file sufficiently to make life easy for porters...

One idea would be to add yet another OSystem API, which is responsible  
for loading/saving the config file. On PS2 and other ports, it could  
just use a fixed location, while on desktop ports, it'd just use the  
current code.

All in all, as I said previously, I envision that we overhaul the  
whole Common::File class. A rough sketch of how the future could look:
* Savefiles stay as they are

* Common::File becomes read-only; the whole core code gets rewritten  
to be easier for backends to use non-"ANSI FILE" based code to access  
files; also the whole "try all case variants of a file name; cache a  
list of all available files; etc." could become different

* yet another special case for the config files. Not sure how this  
would work. Maybe just two new OSystem APIs (resp. a new  
ConfigFileManager) which can be asked for a readstream resp. a  
writestream for the config file, and internally, it can either use use  
FILE *, or a custom implementation. If we do a ConfigFileManager, it  
could also make it possible to use multiple config files (a wish we  
have heard several times, though personally I am still not convinced  
it's such a great idea; but well, we can think about it).

* if games need to read/load .ini style files (like some HE games),  
they would of course use the savefile manager, as they do now; only  
the global config file has to be treated separately

* A new "DumpFile" class, write only, enabled on desktop systems (and  
any port which choses to), thus dead simple to implement. On systems  
which don't implement, it just does nothing. can be used to dump  
debug / resource data, screenshots, whatever you like.



Cheers,
Max