Re: [freesci-develop] Introduction and Question About ScummVM Integration

[Max Horn]

Am 22.06.2008 um 01:39 schrieb Christoph Reichenbach:

> Jordi,
>
> On Sun, Jun 22, 2008 at 01:18:43AM +0200, Jordi Vilalta wrote:
> > > The easiest solution to me then seems to be the introduction of a
> > > file abstraction API (by refactoring the existing header files) with
> > > two underlying implementations, one relying on the one we already  
> > > have
> > > in scicore/tools.c (plus extensions as needed) and one relying on  
> > > the
> > > ScummVM mechanisms, with a flag triggering which one we use.
> >
> > Any details on the expected API design? About the data structure I'm
> > thinking on something like the current sci_dir_t.
>
>  That would do the trick, but as we discussed in IRC some time back,
> I still don't see what it will buy us.  The central argument in favour
> of supporting this seems to be that it will permit ANSI C89 FILE *
> support on platforms that have broken C89 support-- effectively by
> wrapping a custom API around ScummVM's FILE* emulation layer.
>
>  Why not just use ScummVM's FILE* emulation layer to provide vanilla
> ANSI C89 FILE* support instead?  That sounds like less work and
> easier maintenance to me.
>
>  (Unless I am missing something...?)

Just to throw in some thoughts here, on why ScummVM does not just  
emulate FILE, and on some caveats regarding portable file access.

First of, ScummVM is of course written in C++, and at least I find it  
preferable to have a File class, not a FILE  pointer. We get some  
benefits from this, e.g. a File object automatically closes its file  
handle once you don't use it anymore.

Also, if one wants to create a custom FILE implementation, you must be  
careful to not clash with any existing but broken FILE implementation.  
So, don't call it FILE but rather sci_FILE / scummvm_FILE or so (and  
#define/typedef it on non-broken systems).


But in reality, a reason why the given FILE implementation is broken  
or missing is that simple FILE does not fit all devices too well! On  
consoles and PDAs, there are often multiple kinds of storage: There  
might be big read-only storage, and only small writable storage space,  
and that might in turn be separated into very slow but bigger and very  
fast but small portions. Oh, and of course on some systems you have  
paths, and on others you don't. And if there are paths, they can be  
very differently handled (e.g. under Windows, there are many FS roots,  
under Unix there is only one).

Hence, it is often very difficult for porters to correctly emulate all  
details of FILE correctly; they need to know more than just "open a  
FILE", you need to provide hints as to what kind of FILE to open. For  
these reasons, in ScummVM, we provide a system to abstract away from  
paths, and also distinguish between roughly three kinds of files:

* data files: those are only readable. They can be huge. E.g. on the  
Dreamcast, they are typically stored on the read-only game CD. We  
provide code to automatically search for such files in various places,  
allowing the user to keep shared data files in a single location, and  
more importantly, we provide an abstraction layer for paths.

* save files: These are small and contain save states. They must be  
both readable and writeable. On consoles, these are often stored in  
special "locations" (to which no "path" would corresponds), like  
memory sticks and suchthings. We actually have completely separate  
code for these in ScummVM, which greatly helps some ports (they don't  
have to rely on hacks to distinguish between game and save files). As  
a side benefit, it allows us to transparently and automatically  
compress save files. Also, save states are automatically stored in a  
special location on Desktop systems, too.

* Debug / dump files: Those are (not yet) an actual separate class in  
ScummVM, but my plan is to separate them eventually (right now the  
File class has special code if you try to open a file for writing).  
These are used to e.g. dump resources for debugging purposes and other  
debugging stuff. That makes sense on desktop ports of ScummVM, but not  
on consoles. Hence consoles can just ignore any attempts to create  
such files


There are some special cases, too (e.g. the config file needs to be  
both readable and writeable; so it should be a savestate; but you  
don't necessarily want to store them into your savepath). But that's  
roughly it.


Of course you can solve these things completely differently, but the  
above works very well for us, and clearly we have a proven track  
record of being easy to port...


Cheers,
Max