Messages

1

Mega Tokyo SCI Archive / Re:Compatability

« on: January 01, 2004, 11:28:58 AM »

John,

Come on, someone here must know!

such a port is a delicate process, particularly because (as I understand it) the existing code base (for the various editors, not for the compiler) is deeply rooted in some proprietary API which simply doesn't exist on non-Win32 systems. As such, porting the program will almost certainly not be a simple process like searching and replacing certain strings, but involve understanding someone else's source code, understanding the meaning, intent, and interrelationships of the semantics underlying it, mapping those to whichever new API you are using, and re-implementing the code in question (possibly re-using some existing parts). Depending on which APIs are involved, the process _may_ be simpler in some cases, but there is no guarantee that this will be the case.

If you really want to go through with it, your best bet would be to use a well-documented cross-platform API such as one of those listed at http://www.geocities.com/SiliconValley/Vista/7184/guitool.html.

I would _STRONGLY_ recommend you to try porting one tool at a time, starting with the easiest one(s).

I do not know any of these toolkits, have never touched Win32 programming and have no relevant experience with programming windowing systems, so I don't feel that I could do the "tutoring" part here.

-- Christoph

2

Mega Tokyo SCI Archive / Re:SCI1 pic resources

« on: April 27, 2003, 03:33:08 PM »

Hi,

SCI1 pics are essentially the same as SCI0 pics, except that they use embedded views for foreground (visual map) images. I'm not entirely certain what the format is, but you're invited to have a look at the source code if you want to know.

Our docs are currently being ported from docbook SGML to LaTeX, so it may take a while to get the next update done.

-- Christoph

3

Mega Tokyo SCI Archive / Re:Legal Questions

« on: April 27, 2003, 03:29:27 PM »

Hi,

I'm not certain what Brian's standard scripts are licensed as, but the concrete license of SCI Studio should not result in any licensing issues for any of you (unless you intend to ship modified versions of SCI studio with the game).

But, strictly apart from that: The GPL does not prevent you from creating "commercial" software. It simply requires you to distribute the source code on demand and to allow the sources and binaries to be distributed.
  This does not imply anything about your graphics and sound, which you can license separately.

-- Christoph

4

Mega Tokyo SCI Archive / Re:Why doesn't the SCI Studio's language follow C-style notation

« on: October 23, 2002, 12:27:46 PM »

Hi,

just for completeness' sake (although this is somewhat orthogonal to the point you're trying to make): The number of parentheses you'll use in well-written haskell code (recall that you _can_ use parentheses to arbitrarily obfuscate almost all existing programming languages) is considerably smaller than the number of parentheses you'll need for corresponding C or C++ code. Example:

C++:

template <class N> N fact(N v)
{
    if (v == 0)
        return 1;
    else
        return n * fact(v-1);
}


Haskell:


fact 0 = 1
fact n = n * (fact $ n - 1)


Just trying to point out that functional != "needs a lot of parentheses". Neither does "functional" mean "dynamically typed"; usually, the opposite is the case. LISP and Scheme, by benefit of having been very early mostly-functional languages, have somewhat confused matters historically. In fact, you should find that Haskell and (to a lesser extent) SML require less syntax than the C/C++ family of languages.

As pointed out, that's orthogonal to the point you're trying to make; however, as someone who is particularly fond of Haskell, I couldn't let this slip by uncorrected-- hope you'll forgive me ;-)

-- Christoph

5

Mega Tokyo AGI Archive / SCI documentation

« on: January 24, 2002, 03:05:00 AM »

Hi,

Try this:
http://darmstadt.gmd.de/~jameson/freesci-docs-onehtml.tar.gz

You can also generate them from docs/sci.sgml from the FreeSCI source distribution by using an SGML processor and a DSSSL spec for the 'docbook' document type (Unfortunately, the docs are in no shape for XSLT processing ATM). Please note that I've been unable to generate PDF or PostScript documentation yet; looks like the document structure is too weird for the DSSSL to handle.

-- Christoph