[Scummvm-cvs-logs] SF.net SVN: scummvm: [29199] docs/trunk/docbook
fingolfin at users.sourceforge.net
fingolfin at users.sourceforge.net
Sat Oct 13 01:09:16 CEST 2007
Revision: 29199
http://scummvm.svn.sourceforge.net/scummvm/?rev=29199&view=rev
Author: fingolfin
Date: 2007-10-12 16:09:15 -0700 (Fri, 12 Oct 2007)
Log Message:
-----------
Added FreeSCI FAQ (feel free to extend & improve it), fixed some typos
Modified Paths:
--------------
docs/trunk/docbook/faq.xml
docs/trunk/docbook/manual.xml
Modified: docs/trunk/docbook/faq.xml
===================================================================
--- docs/trunk/docbook/faq.xml 2007-10-12 22:41:30 UTC (rev 29198)
+++ docs/trunk/docbook/faq.xml 2007-10-12 23:09:15 UTC (rev 29199)
@@ -194,6 +194,59 @@
</answer>
</qandaentry>
+
+ <qandaentry>
+ <question><simpara>Will you add support for Sierra's SCI games?</simpara></question>
+ <answer>
+ <simpara>
+ If you want to play SCI games, have a look at <ulink url="http://freesci.linuxgames.com/">FreeSCI</ulink>.
+ or at <ulink url="http://dosbox.sourceforge.net">DOSBox</ulink>.
+ </simpara>
+ </answer>
+ </qandaentry>
+
+ <qandaentry>
+ <question><simpara>Why don't you merge with FreeSCI?</simpara></question>
+ <answer>
+ <simpara>
+ Again and again people suggest this. The argument usually involves the observation that the
+ two projects have similar goals, and that FreeSCI's development is appears to be quite slow
+ while ScummVM's seems to be very fast. So, people conclude, that a merge would somehow miraculously
+ solve all perceived problems (i.e. increase development speed, increase portability, fix bugs,
+ enhance support for newer SCI games, whatever).
+ </simpara>
+ <simpara>
+ This logic is flawed in several ways. For example, a merge would not automatically ensure
+ SCI support on all platforms ScummVM supports right now; porters would still have to adapt it
+ for each platform. It is however true that this would probably be easier than adding support
+ for all these platforms to FreeSCI itself. Still, it's far from being easy or simple.
+ </simpara>
+ <simpara>
+ Next, it is not true that the development speed would automatically increase. If you look
+ at the internal organization of ScummVM, not all our devs actually work on all engines. Typically,
+ between one and five people work on a given engine. When new engines are added, only a very
+ few people (typically those who performed the merge) actually work on it. That means that in
+ order to support (Free)SCI, we first would have to find people who performed that merge,
+ and who then secondly would continue to work on the added code. One might wonder whether
+ anybody who is capable of such a task and interested in it could not do the very same directly
+ within the framework of the FreeSCI project itself, but saving the hassle of first porting
+ the code to ScummVM... ? So where is the advantage here, exactly? The only potential
+ advantage in this regard would be the hope that other ScummVM devs might develop an interest
+ in the SCI code base and started to work on it. Not a completely invalid hope, but there is
+ a steep and long road from some trivial bug fixes to actual improvements to the SCI engine.
+ Not to forget that those people who know most about how SCI games (its creators aside)
+ already work on FreeSCI anyway... :-).
+ </simpara>
+ <simpara>
+ We are not fundamentally opposed to merging FreeSCI, but the plain truth is:
+ There is not as much to be gained from this as you might naively believe. Nor is it easy to
+ do. There are many more details we could list here, but in the meantime, just have a look
+ at <ulink url="http://forums.scummvm.org/viewtopic.php?t=1979">this thread on our forums</ulink>
+ for a thorough discussion of the subject.
+ </simpara>
+ </answer>
+ </qandaentry>
+
</qandadiv>
@@ -281,11 +334,11 @@
No. If all the game does is to play or loop a tune it would be possible, but many of the games do
fancy stuff like smooth transitions from one tune to another, or turn individual instruments on and
off, etc. There's simply no way ScummVM could take a piece of digital music and emulate that kind
- of behaviour.
+ of behavior.
</simpara>
<simpara>
This question usually comes up in connection with Sam & Max Hit the Road (which has a few
- unusued bonus audio tracks on the CD) and Monkey Island 2 (which is sometimes distributed on
+ unused bonus audio tracks on the CD) and Monkey Island 2 (which is sometimes distributed on
the same CD as the version of Monkey Island 1 that uses CD audio). Both of these games do far
too much fancy stuff to even consider an idea like this.
</simpara>
@@ -435,7 +488,7 @@
invisible.
</simpara>
<simpara>
- There also exists a seperate <ulink url="http://wiki.scummvm.org/index.php/HOWTO-Mac_Games">tutorial
+ There also exists a separate <ulink url="http://wiki.scummvm.org/index.php/HOWTO-Mac_Games">tutorial
</ulink> for setting up Mac versions
</simpara>
<simpara>
@@ -493,7 +546,7 @@
</answer>
</qandaentry>
- <qandaentry><question><simpara>I get "WARNING: Unable to open configration file C:\windows\scummvm.ini!"</simpara></question>
+ <qandaentry><question><simpara>I get "WARNING: Unable to open configuration file C:\windows\scummvm.ini!"</simpara></question>
<answer>
<simpara>
Make sure you have enough permissions to write in c:\windows directory. Also note that this warning the
@@ -505,7 +558,7 @@
<qandaentry><question><simpara>I get "Failed to save game state to file: xxx"</simpara></question>
<answer>
<simpara>
- Check savepath in Options->Paths->Save Path. That should point to writeable directory.
+ Check savepath in Options->Paths->Save Path. That should point to writable directory.
</simpara>
</answer>
</qandaentry>
Modified: docs/trunk/docbook/manual.xml
===================================================================
--- docs/trunk/docbook/manual.xml 2007-10-12 22:41:30 UTC (rev 29198)
+++ docs/trunk/docbook/manual.xml 2007-10-12 23:09:15 UTC (rev 29199)
@@ -57,7 +57,7 @@
<simpara>
At this time ScummVM should be considered beta software, and is still
-under heavy development. Be aware that whilst we attempt to make sure
+under heavy development. Be aware that while we attempt to make sure
that many games can be completed with few major bugs, crashes can happen.
</simpara>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
More information about the Scummvm-git-logs
mailing list