[Scummvm-cvs-logs] SF.net SVN: scummvm:[38310] docs/trunk/docbook/faq.xml

fingolfin at users.sourceforge.net fingolfin at users.sourceforge.net
Sun Feb 15 23:00:53 CET 2009


Revision: 38310
          http://scummvm.svn.sourceforge.net/scummvm/?rev=38310&view=rev
Author:   fingolfin
Date:     2009-02-15 22:00:53 +0000 (Sun, 15 Feb 2009)

Log Message:
-----------
Updated our FAQ a bit

Modified Paths:
--------------
    docs/trunk/docbook/faq.xml

Modified: docs/trunk/docbook/faq.xml
===================================================================
--- docs/trunk/docbook/faq.xml	2009-02-15 21:57:51 UTC (rev 38309)
+++ docs/trunk/docbook/faq.xml	2009-02-15 22:00:53 UTC (rev 38310)
@@ -165,14 +165,16 @@
 	<qandaentry><question><simpara>Will ScummVM support other games?</simpara></question>
 	<answer>
 		<simpara>
-		The ScummVM team is currently focusing on bugfixes for our next release.
+		That depends on several factors. First off, it has to fit within the scope of ScummVM,
+		i.e., has to be apoint and click adventures with 2D graphics. 
 		</simpara>
 		<simpara>
-		We do <emphasis>NOT</emphasis> generally add support for non-SCUMM
-		games! Reverse engineering a completely new game without source is a
-		long process, and our developers are all very busy as it is... so unless
+		Secondly, there must be a developer (or multiple) who are interested on working this
+		and both willing and able to perform the work required for this.
+		Reverse engineering a completely new game without source is a
+		long and difficult process, and our developers are all very busy as it is... so unless
 		you work for a company interested in providing us with source code for
-		one of your classic titles, please do not ask.
+		one of your classic titles, or want to do the work yourself, please do not ask.
 		</simpara>
 	</answer>
 	</qandaentry>
@@ -197,53 +199,13 @@
 
 	<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).
+		FreeSCI has now been merged into ScummVM, see <ulink url="http://www.scummvm.org/?shownews=20090215.xml">this news item</ulink>.
+		However, many SCI games still not supported, so you may also want to check out <ulink url="http://dosbox.sourceforge.net">DOSBox</ulink>
+		if you want to play all SCI games, especially newer ones.
 		</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>
 


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