[jameson: Re: [freesci-develop] FreeSCI configuration]

[Christoph Reichenbach]

Sorry, that one should've been a group reply.

----- Forwarded message from jameson -----

To: Matt <address@hidden>
Subject: Re: [freesci-develop] FreeSCI configuration
Reply-To: Christoph Reichenbach <address@hidden>

Matt,

> >I'm not sure if we can generalise the drag&drop to everyone's
> >satisfaction, but I agree that as much as possible of the
> >loader/configurator functionality should be integrated. I'd suggest
> I know that for OS X the drag drop functionality would be difficult to 
> get to work via X Windows only (unless X11 would be integrated into the 
> system, right now it still requires an additional installer).

I'm not sure about what you're getting at-- at any rate, I'm not
trying to advocate completely ignoring OS X system specifics; if we
need Cocoa (or whatever) for this to work smootly, let's, by all
means, use Cocoa. Or whatever.

> This would not be a big issue though, the drag drop could be 
> implemented via cocoa to at least start freesci (the dropped folder 
> name would be passed as an argument).
> From there an integrated detailed game setup could be launched. This 
> would leave the detailed game setup in freesci.

I'd argue that we could go as far as making this the default behaviour
on OS X. Right now, our startup code is squashed into main.c (and
game.c, for the engine initialisation); if we were to factor things
out a little, relocating config file and command-line argument parsing
into a separate module, different platforms could use different 'main'
files (I believe that the DC port already does something like that,
but please don't quote me on that as Walter currently isn't in
shouting range).

> >That depends on whose ease you're concerned about ;-)
> >It's fairly easy to understand our config format with a mere lexer (->
> >src/config.l)-- perhaps not quite as easy as it would be with an XML
> >file, but the format we're using has the advantage of being reasonably
> >convenient for people to edit by hand.
> Agreed, the ini like flow of config makes it an easy manual changeable 
> file. I have been looking at this from a reading/writing perspective 
> from a non Windows point.

I'm not familiar with 'ini' files or Windows, so I can't comment on
these parts. The style is based on the config style of something I
had to configure used ages ago-- though it's possible that it copied
from the Win32 world.

> I coded some pieces (actually I created a 
> WritePrivateProfileString and GetPrivateProfileString, functions I 
> thought I would never see again after I switched to Mac) and noticed 
> them becoming complex.

We already have lexers. Writing out stuff shouldn't be too hard.

> The thought of XML came up because any XML parser would take all the 
> work away from reading and writing the file and I would think it would 
> reduce some coding in freesci.

Granted, there are existing xml parsers that we could use. My own
experiences with DOM, however, would seem to indicate that it would be
less painful not to use them (unless DOM has improved significantly in
the last 5 years to allow for static inspection, which I rather
doubt).
  Anyway, we have an existing config file parsing mechanism (that
could be refactored a little) already and could spit out everything we
parsed with relatively little pain-- barring comments, but that's a
price I'm willing to pay.

  But I'm not trying to say that this is the only way to go. I'd
suggest that we see what other people on the mailing list and in IRC
think about that first. I simply do not currently see that using XML
would make anything easier for us (please have a look at config.l,
where we're using fairly compact code to express the meanings of
various configuration options-- yes, you can do the /checking/ with
DTDs or these new XML Schema things too, but the translation into the
C layer-- string parsing etc.-- is not, to my understanding, handled
by any existing mechanism).


> >  Anyway, the real issue you attempt to address with that seems to be
> >round-trip configuration (de)serialisation, i.e. we need to add
> >facilities to FreeSCI to serialise the configuration setup, and also
> >to manipulate it (for this to serve any purpose).
> >
> >  Since you've already spent some thought on that (unlike me), do you
> >have any suggestions as to the architecture or API that such a
> >round-trip configuration subsystem should provide?
> Writing an API for external game setup would show the user an 
> 'OS-fitting' UI. I have played with ScummVM and the internal setup is 
> pretty nice so if thats possible with freesci (which sounds like it) 
> then I would prefer that over any API.

Makes sense to me. The current internal system only allows for games
to be selected, from what I understand; as such, more options (and,
perhaps, a refactoring of the configuration mechanism into a separate
configuration subsystem) would be called for.

> >The correct video/audio setup should be autodetectable, but your
> >drag&drop approach seems like a very nice feature that should become
> >part of FreeSCI one way or another.
> I remember there was a discussion if all video drivers would stay all 
> supported. I believe there was a wish to reduce the number of video 
> server/driver possibilities. Does Glutton still support SDL and 
> X-Windows or will X-Windows (and maybe DreamCast) become the only 
> supported video driver?

*I* am not planning to kick out any graphics/input drivers, but I
don't know about everyone else. The problem right now is that the xlib
and DC graphics/input drivers are the only ones being actively worked
on (the ggi driver is, more or less, a curiosity, the directfb driver
is fairly usable but would need to be updated for the latest version
of the directfb library-- they followed the rather dangerous path of
changing their API with every minor release-- the DirectX driver is
probably still broken, though I'd have to ask Matt (the other one)
about details, and the SDL driver is a big problem not because no one
likes it but (a) because it is vastly less efficient than the xlib
driver and (b) no one is actively maintaining it-- mind you, there
could well be a link between these two points....).
  The graphics subsystem is virtually unchanged between glutton and
the stable branch. There was a minor change to the widget layer to
allow 32 bit object IDs (as used by the glutton VM), and per-resource
palette specifications were allowed for glutton only, but that's about
all I can think of ATM.

> I am close to completing the launcher for OS X and will send it and the 
> code out pretty soon. Just checking if everything runs nice on non 
> debug machines.

I actually have an OS X machine here I can test on. Looking forward to
seeing it in action :-)


Sorry if my writing's a little incoherent tonight, but it is rather
late here.

-- Christoph

----- End forwarded message -----