Re: [freesci-develop] this is what I propose...

[Christoph Reichenbach]

Kevin,

On Sun, Nov 20, 2005 at 04:37:14PM -0800, kevin wrote:
> Hi Christopher, I'm not really an IRC chat type  guy, plus I doubt that
> anybody is listening heavily on irc under the  subject for SCI stuff at this
> late date.

  No worries, there are always people there (I at least am almost always
logged in, even though I don't always check what's going on ;-)

>   But here is what I can do for this project, I am a old-timer 2d/3d game
>   programmer and I only need the resources to reconstruct a game, don't
>   really need to worry about pixel scaling problems, or sound issues, or
>   game save problems.

  What do you mean by "reconstruct" here? Should I imagine this as something
similar to what the Tierra guys are doing?

> As I am planning on resurecting some existing code
>   that will do everything the sierra engine did and more. The only real
>   challenge will be interpretting the script language.

  Well, you probably won't find ready-made systems that properly support their
sound cueing system and the text parser (if you want to go for SCI0), though
you can probably get their z-buffered graphics system out of OpenGL with some
tickling.

> I am thinking that
>   it will be a matter of post-processing it into Lua. And re-creating  code
>   for all the hooks of the original script into whatever the  resources
>   formating needs are.

  So your goal is effectively to replace the virtual machine part with a
binary (dynamic? static?) from SCI bytecode into Lua bytecode?

  Lua is a dynamically typed language with support for dynamic dispatch, so I
see no inherent issues on that end. Sierra's array support may be a little
awkward in that context, but that too can be solved (by treating everything as
an array during the translation). Note, however, that it is possible in SCI to
get references to the stack and to points in the current "script", and to use
these references for strings. With a little bit of
keeping-your-fingers-crossed, you may be able to emulate that with a hashmap,
though. My understanding is that "Conquest of the Longbow" uses a dialogue
system for which some amont of closeness to the original VM is neccessary; I'm
not sure which low-level hacks are used here.

  I'm not sure if this will buy you anything over using the FreeSCI VM, but it
is a different and somewhat interesting challenge in its own right, so I see
why you might want to prefer that approach.

>   Absolutely the first step in porting any game over, is to make sure
>   before beginning, that all the resources are separated and the format
>   understood.

  We seem to have a fairly decent understanding of them at this point (at
least Lars has).

> Forget about writing game emulation code until all the
>   resources are extracted and their format understood.

  I'd rather not. That's a bit detrimental to motivation. In general, though,
I believe that all of the SCI1-and-below stuff and possibly all SCI1.1
resources (not sure about compression) are understood, the exception being
some subtleties of the Said() kernel call.

>   I do have time to hook up a very powerful 2D game engine that can be  used
>   to play sierra games and even allow you to Mod the games. And even  play
>   them at higher resolutions than even the resources were designed  for.

  Great! Note that the FreeSCI graphics subsystem has full support for
graphics with a bit depth of up to 24 (8 red, 8 green, 8 blue) and 8 bits of
transparency (though we only have very limited support in the graphics
backends for drawing this). To avoid duplication of work, I highly recommend
that you have a look at what we've done so far. FreeSCI's graphics subsystem
currently improves SCI graphics in the following ways (check the README for
info on how to set this up in your config file):

- Scaling pixmaps by a handful of filters
- Modifying graphics in the configuration file by changing the specific
  palette used by pixmaps
- Scaling SCI0 background graphics (which are vector graphics with flood
  filling)

Here's an example of what all of that put together looks like:

  http://www.teksolv.de/~jameson/palette-config-demo.png

  It's not perfect, and any help would be appreciated, but I believe that we
have the infrastructure to accomodate for many other options, such as
completely replacing cels or pics. If you're interested in re-using our
graphics subsystem, please feel free to do so and to ask any questions you
might run across!


>   But I am hoping that somebody has already extracted (or can just re-run
>   the extraction tools) and can provide all the resources separately.

 Sciunpack will extract everything for you. Within the FreeSCI engine, you can
use the resource manager to access data "as if you had decompressed it". Let
me know if you would like details and I'll look up the header files for you.

>   Because I dont have the time to hack and poke at the resource files to
>   figure out how they are put together. Does anybody on this list have a
>   harddisk full of the separated resources? namely kq5 which I am most
>   familiar? 

  I haven't tried sciunpack with non-SCI01 games, I'm afraid, but at least for
SCI1 games it should work.

>   If somebody could do that, then I could quickly reconstruct the game. The
>   minimum I would need is...
>   
>   Background images

  Those are the so-called 'pic' resourcs.

>   Sprite images

  Those are 'cels', grouped in 'loops' grouped in 'view' resources.

>   sound files (midi, and wav)

  'sound' resources (SCI1 may have additional wave resources, I keep
forgetting). I'm not sure if KQ5 already had GM support; earlier games didn't
(GM hadn't been defined), so you will also need instrument maps to estimate
the approximate GM instruments (or to derive the proper MT-32 instruments, or
the proper AdLib settings); cf. 'patch' resourcs.

>   hotspot files (tells the script what to do when areas are clicked)

  There is no such thing in SCI, to my understanding (Lars, feel free to
correct me here). Polygons (not implemented in FreeSCI) are (sometimes?) used
for this task; these are stored as part of 'script' resources (they can be
updated dynamically). Also, the control map (maybe even the priority map?) is
sometimes used for this purpose in SCI0, i.e. it's stored implicitly in 'pic'
resources.

>   path following files (tells script where avatars can and cannot go)

  cf. hotspot, above. Where someone can go is defined both by polys (where
present) and by the control map, though scripts can override this in many
ways.

>   Script files

  Class definitions, objects, external objects and functions, locals,
relocation pointers (for the linker) etc. are stored in 'script' (and, in
SCI1.1, also in 'heap') resources.

>   Or better yet, the resource file is so well understood, that the  original
>   resource file could be left as is, and the engine could pull  these
>   on-demand (just like the original game).

  I strongly recommend that you have a look (a) at our documentation and (b)
at our header files (which are intended as API documentation). It seems to me
that you might save yourself a lot of worries by making sure that you
know at least the more interesting chunks of the functionality already
provided by FreeSCI. I recommend that you get the latest version of our SCI
documentation from CVS and build it from there (only LaTeX is needed for
that); if that's an issue, let me know and I'll update the pdf I have at

  http://www-plan.cs.colorado.edu/creichen/freesci/sci.pdf



  Also, please do not ask for game data or offer game data on this mailing
list or in the IRC channel. The Sierra games are still under copyright by
whoever owns them these days (Vivendi, I think), and redistributing them
without permission is illegal-- and one of our most fundamental goals in
FreeSCI has remained to remain legal (which is also why we're not using
decompiled sources as basis for our implementation).


-- Christoph