[Request] Sanity-check of new Tads 2/3 port

Archived from groups: rec.arts.int-fiction,rec.games.int-fiction (More info?)

[I'm posting this on behalf of Nikos Chantziaras. He doesn't have reliable
Usenet access right now, so if you have support-type questions about this
new release, you're probably better off emailing him directly - his address
is at the end of the message. --Mike]

(Mac OS X users: "Unix" includes your OS too, so keep reading.)

(Replies to this message will only show up in rec.games.int-fiction. Please
don't change the "follow-up-to" header.)

I was working on fine-tuning a new Unix port of the character-mode Tads
interpreter for the last couple of weeks (it combines both virtual machines;
Tads 2 and Tads 3). It still has some "childhood" problems, but the main
work is complete. I hope that, in the long term, it will replace the
existing Unix port, which is too big and complex, and has a few problems. I
think that maintaining the current port is somewhat of a nightmare, as no
one seems to know what might break if extensive changes are made to it (like
implementing color support; I already tried but all Hell broke loose). One
of the biggest problems is that it has "sub-ports" with maintainers for each
of them. (Of course, it is still very useful for very old systems that lack
even a basic curses library, so I'm not suggesting that it should be
abandoned.) The new terp should be more portable than the current
Unix-port; it even compiles cleanly under Microsoft Windows.

This is how the new port looks like (screenshots taken while the terp was
running in a 80x27 console):

(Intro from Soren Lovborg's "Evil Brain Five")
http://members.lycos.co.uk/realnc/evilbrain.png (1.6 KB)

(In-game menu in Eric Eve's "Square Circle")
http://members.lycos.co.uk/realnc/circle.png (1.8 KB)

(Iain Merrick's "Forever Always")
http://members.lycos.co.uk/realnc/forever.png (6.5 KB)

(Mike Sousa's and Jon Ingold's "Till Death [...]")
http://members.lycos.co.uk/realnc/tilldeath.png (6.5 KB)

(Geoff Fortytwo's "I Must Play")
http://members.lycos.co.uk/realnc/mustplay.png (7.8 KB)

To avoid confusion with the current port, I named the new interpreter
"FrobTADS". Call me a marketing weenie. :)

The terp uses the Autotools (autoconf+automake), so there's no need to edit
makefiles prior to building (there aren't any makefiles; they will be
generated "on the fly"). A "configure; make; make install" is enough to
configure, compile and install it. For masochists who want to compile in
MS-Windows, if you're using MinGW/MSYS or cygwin, just "configure;make" like
in Unix; it should work. A Dev-C++ project file is not provided; it should
be easy to create one by yourself (Dev-C++ is something like Visual C++ but
uses Windows GCC as its compiler; it uses the same system API as Visual C++
(win32), so there's no POSIX emulation layer).

The terp is written in C++, with a simple window class that wraps around the
curses-API, so maintaining it should be a lot easier (at least that's how
C++ works for me). It looks and feels much like Frotz or the MS-DOG Tads
terp. I chose C++ instead of C since Tads 3 itself is C++, so choosing C
would not lower the system requirements and it's is a combined TADS2/3
interpreter.

The code is (mostly) trivial and very generic; it does not rely on any
Linux/BSD/SysV/whatever functions, nor kernel calls. It does not do any
fancy curses-tricks that might not work on broken curses libraries. It
restricts itself to standard C++, with no compiler specific features, no
exception handling, no templates, no namespaces, and it does not make use of
the standard template library. This should make it compile on older C++
compilers. (At least I *hope* it does all these things. If something
slipped through, it's a bug.)

Currently, the main differences to the current port are:

- Automatic configuration prior to building.

- Tads 3 color support (text, background, banners) and configurable
default colors.

- Correct timing with timed operations (millisecond-precision on
almost every system).

- Input like in Frotz; cursor keys, insert, delete, etc., instead
of Emacs-like input.

- Statusline and TADS3 banners look as they should.

- Less source code, more comments.

- More portable

Some things are still missing (like a Frotz-like configuration file).
Terminal-resizing when running in X11 or OS X is handled, but maybe not 100%
since it might not work with some curses libs, I don't know. Your feedback
is needed here.

Anyway, just because it works on my system doesn't mean it works everywhere
else. So I need help in testing the new port. If you have a Unix-like OS
(including Mac OS X) and some spare time, download the tarballs:

(Main package - Interpreter)
http://www.tads.org/frobtads/frobtads-0.1.tar.gz

(TADS 2 compiler)
http://www.tads.org/frobtads/t2comp.tar.gz

(TADS 3 compiler)
http://www.tads.org/frobtads/t3comp.tar.gz

and give it a go. Although you can "configure; make" right away, reading
the README and/or INSTALL files first might be a good idea.

Try the above games if you can, and compare them to the screenshots.

I can be reached at:

realnc (at) users sourceforge net
24 answers Last reply
More about request sanity check tads port
  1. Archived from groups: rec.games.int-fiction (More info?)

    Mike Roberts wrote:
    > [I'm posting this on behalf of Nikos Chantziaras. He doesn't have reliable
    > Usenet access right now, so if you have support-type questions about this
    > new release, you're probably better off emailing him directly - his address
    > is at the end of the message. --Mike]
    >
    > (Mac OS X users: "Unix" includes your OS too, so keep reading.)
    >
    > (Replies to this message will only show up in rec.games.int-fiction. Please
    > don't change the "follow-up-to" header.)
    >
    > I was working on fine-tuning a new Unix port of the character-mode Tads
    > interpreter for the last couple of weeks (it combines both virtual machines;
    > Tads 2 and Tads 3). It still has some "childhood" problems, but the main
    > work is complete. I hope that, in the long term, it will replace the
    > existing Unix port, which is too big and complex, and has a few problems. I
    > think that maintaining the current port is somewhat of a nightmare, as no
    > one seems to know what might break if extensive changes are made to it (like
    > implementing color support; I already tried but all Hell broke loose). One
    > of the biggest problems is that it has "sub-ports" with maintainers for each
    > of them. (Of course, it is still very useful for very old systems that lack
    > even a basic curses library, so I'm not suggesting that it should be
    > abandoned.) The new terp should be more portable than the current
    > Unix-port; it even compiles cleanly under Microsoft Windows.
    >
    > This is how the new port looks like (screenshots taken while the terp was
    > running in a 80x27 console):
    >
    > (Intro from Soren Lovborg's "Evil Brain Five")
    > http://members.lycos.co.uk/realnc/evilbrain.png (1.6 KB)
    >
    > (In-game menu in Eric Eve's "Square Circle")
    > http://members.lycos.co.uk/realnc/circle.png (1.8 KB)
    >
    > (Iain Merrick's "Forever Always")
    > http://members.lycos.co.uk/realnc/forever.png (6.5 KB)

    Wow! Interesting work there. Any chance there will be a port for those
    of us still tripping on DOS, at least even a 32-bit version? Or is
    there something I should try to do?

    --Arnel
  2. Archived from groups: rec.games.int-fiction (More info?)

    "Arnel Legaspi" <jalespring@excite.com> wrote:
    > [about Nikos's new release of FrobTADS for Unix]
    > Wow! Interesting work there. Any chance there will be a port for
    > those of us still tripping on DOS, at least even a 32-bit version?
    > Or is there something I should try to do?

    Nikos said something about compiling for Windows, which I imagine would
    yield a console-mode program that you'd run in a DOS box - from the earlier
    post: "For masochists who want to compile in MS-Windows, if you're using
    MinGW/MSYS or cygwin, just "configure;make" like in Unix; it should work."
    But I don't think there'd be much point, in that I don't think you'd gain
    any functionality vs the standard DOS versions - I believe that FrobTADS is
    based on the same common character-mode layer that the DOS version is, and
    the DOS version already fully implements all of the available character-mode
    functionality. In other words, I think FrobTADS brings the Unix version to
    parity with the existing DOS version. I might be wrong; you'd have to ask
    Nikos to be sure.

    --Mike
    mjr underscore at hotmail dot com
  3. Archived from groups: rec.games.int-fiction (More info?)

    (Looks like Google Groups is my only option right now...)

    Mike Roberts wrote:
    > "Arnel Legaspi" <jalespring@excite.com> wrote:
    > > [about Nikos's new release of FrobTADS for Unix]
    > > Wow! Interesting work there. Any chance there will be a port for
    > > those of us still tripping on DOS, at least even a 32-bit version?
    > > Or is there something I should try to do?
    >
    > Nikos said something about compiling for Windows, which I imagine would
    > yield a console-mode program that you'd run in a DOS box

    Correct. There is no support for plain DOS.


    > But I don't think there'd be much point, in that I don't think you'd gain
    > any functionality vs the standard DOS versions

    The only improvement I can think of right now, is the configurable UNDO
    size for T3 games; in the existing Windows and DOS terps, you can UNDO
    about 5-6 times. With Frob you can UNDO about 100 times, with the
    upper limit being 255 times.
  4. Archived from groups: rec.games.int-fiction (More info?)

    Actually, if anyone does compile it on MacOS X and are feeling
    altruistic, I wouldn't mind some pointers on how to compile things like
    this. I do have gcc-4 and g++-4 installed on my system, but the
    configure step for frobtads failed with a "checking for C++ compiler
    default output file name... configure: error: C++ compiler cannot
    create executables" error. So clearly, my setup isn't correct, but I'm
    not sure what to do next. This is my problem, not anyone elses--but if
    you know the answer or have some idea about how to proceed, I would be
    grateful.
  5. Archived from groups: rec.games.int-fiction (More info?)

    I see. Things are always more difficult than they seem. My gcc and
    g++ aren't the ADT versions, the come from gnu.org. I installed them
    with Fink. It sounds like maybe I should just go back to writing IFs.
    I've had much better luck making Inform, TADS, Hugo, and Alan files
    compile than anything in C++.
  6. Archived from groups: rec.games.int-fiction (More info?)

    drfreeze wrote:
    > Actually, if anyone does compile it on MacOS X and are feeling
    > altruistic, I wouldn't mind some pointers on how to compile things like
    > this. I do have gcc-4 and g++-4 installed on my system, but the
    > configure step for frobtads failed with a "checking for C++ compiler
    > default output file name... configure: error: C++ compiler cannot
    > create executables" error.

    Sounds strange, even if I never tried GCC 4 (still using version 3). I
    already got a report from an OS X user that it compiled without
    problems. Are you sure the compiler can actually compile C++ files?
    Enter this into a text editor and save it as tst.cc:

    int main() {return 0;}

    Open a terminal/console, go to the directory where you saved the file,
    and try to compile it by entering:

    g++ tst.cc

    These should be no errors, and an executable file called "a.out" should
    have been created. If not, there's probably something wrong with your
    setup.

    By the way, the package does not require GCC. You should be able to
    use any C and C++ compiler the configure script recognizes (but I have
    no idea what compilers are available for OS X besides GCC...)
  7. Archived from groups: rec.games.int-fiction (More info?)

    Uli Kusterer wrote:
    >
    > But I vaguely remember that GNUstep gave a similar error message when I
    > tried to compile it with a non-GNU GCC, so maybe that is exactly the
    > problem...

    It would be nice if such error messages would be reported back to me.
  8. Archived from groups: rec.games.int-fiction (More info?)

    In article <1121957743.150194.154940@o13g2000cwo.googlegroups.com>,
    "drfreeze" <dhall_phd@yahoo.fr> wrote:

    > Actually, if anyone does compile it on MacOS X and are feeling
    > altruistic, I wouldn't mind some pointers on how to compile things like
    > this.

    I have to admit, while I got T3 to compile as part of Workbench, that
    only could be achieved by using the existing Darwin Makefiles. I never
    succeeded in actually compiling a working T4 "manually" using Xcode...
    just too many odd dependencies and such to work out...

    > I do have gcc-4 and g++-4 installed on my system, but the
    > configure step for frobtads failed with a "checking for C++ compiler
    > default output file name... configure: error: C++ compiler cannot
    > create executables" error. So clearly, my setup isn't correct, but I'm
    > not sure what to do next. This is my problem, not anyone elses--but if
    > you know the answer or have some idea about how to proceed, I would be
    > grateful.

    Where did you get that compiler from? Apple's Developer Tools (aka
    "Xcode Tools") should already contain GCC. IIRC GCC 4 is new with Xcode
    2 (i.e. MacOS 10.4 "Tiger"), but it should just work. Did you use that
    version of GCC, or did you install your own?

    Apple's version of GCC is a slightly modified version, though, so it may
    just be that the configure script tests something that is different in
    Mac GCC, though that's unlikely.

    But I vaguely remember that GNUstep gave a similar error message when I
    tried to compile it with a non-GNU GCC, so maybe that is exactly the
    problem...

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  9. Archived from groups: rec.games.int-fiction (More info?)

    Nikos Chantziaras wrote:
    > drfreeze wrote:
    >
    >>Actually, if anyone does compile it on MacOS X and are feeling
    >>altruistic, I wouldn't mind some pointers on how to compile things like
    >>this. I do have gcc-4 and g++-4 installed on my system, but the
    >>configure step for frobtads failed with a "checking for C++ compiler
    >>default output file name... configure: error: C++ compiler cannot
    >>create executables" error.
    >
    >
    > Sounds strange, even if I never tried GCC 4 (still using version 3). I
    > already got a report from an OS X user that it compiled without
    > problems. Are you sure the compiler can actually compile C++ files?
    > Enter this into a text editor and save it as tst.cc:
    >
    > int main() {return 0;}
    >
    > Open a terminal/console, go to the directory where you saved the file,
    > and try to compile it by entering:
    >
    > g++ tst.cc
    >
    > These should be no errors, and an executable file called "a.out" should
    > have been created. If not, there's probably something wrong with your
    > setup.
    >
    > By the way, the package does not require GCC. You should be able to
    > use any C and C++ compiler the configure script recognizes (but I have
    > no idea what compilers are available for OS X besides GCC...)
    >

    You are absolutely correct. I deduced something was wrong with my g++-4
    installation. Never used g++-4 before (sorry).

    Here's my installation problem, btw

    TADS/dev > g++-4 test.cc
    g++-4: installation problem, cannot exec 'as': No such file or directory

    I guess I need to find 'as' and install it.
  10. Archived from groups: rec.games.int-fiction (More info?)

    "drfreeze" <dhall_phd@yahoo.fr> wrote:

    >I do have gcc-4 and g++-4 installed on my system, but the
    >configure step for frobtads failed with a "checking for C++ compiler
    >default output file name... configure: error: C++ compiler cannot
    >create executables" error.

    FWIW, I got that error message when I tried to run configure with
    CXXFLAGS=fno-strict-aliasing or some such, and forgot the leading
    '-'.

    Anyway, I tried to compile it on BeOS, but no matter which gcc I use
    (the original BeOS gcc 2.95.beos-special-thingy or gcc 3.4.3), it
    chokes on wcslen and wcscpy, which my compilers don't seem to have.
    Are these standard functions?

    --
    Sophie Frühling

    "El arte no viste pantalones."
    -- Rubén Darío
  11. Archived from groups: rec.games.int-fiction (More info?)

    Once I got the assembler installed the compilation worked flawlessly. I
    am now running frobtabs on Mac OS X 10.4.2 looks good. Now I'll compile
    the compilers. Need anything else done?
  12. Archived from groups: rec.games.int-fiction (More info?)

    Once I got the assembler installed the compilation worked flawlessly. I
    am now running frobtads-0.1 on Mac OS X 10.4.2 looks good. Now I'll
    compile the compilers. Need anything else done?
  13. Archived from groups: rec.games.int-fiction (More info?)

    The wcs* functions are used by TADS3 and belong to the ISO C99 standard.
  14. Archived from groups: rec.games.int-fiction (More info?)

    Mike Roberts wrote:
    > [I'm posting this on behalf of Nikos Chantziaras. He doesn't have reliable
    > Usenet access right now, so if you have support-type questions about this
    > new release, you're probably better off emailing him directly - his address
    > is at the end of the message. --Mike]

    > I was working on fine-tuning a new Unix port of the character-mode Tads
    > interpreter for the last couple of weeks (it combines both virtual machines;
    > Tads 2 and Tads 3). It still has some "childhood" problems, but the main
    > work is complete.

    I strongly recommend users of Unix boxes to try out this new port and
    let Nikos know how they got on. It has a few teething troubles but
    otherwise it's a very
    solid implementation.

    My experience with a Solaris box was good. The only significant
    problem was with the resizing code, but this compiled and executed
    correctly once I'd linked with release 5.4 of ncurses. There was also
    a bug affecting white-on-white text (used by the TADS 3 menu system),
    but Nikos sent a patch which fixed it.
  15. Archived from groups: rec.games.int-fiction (More info?)

    Now that I have this portable port running on Mac OS X, I've been
    playing with it. It seems to work fine, but I'm no power user of TADS.
    Are there any specific games I should try with frobtads that would
    give it a good work out? Are there good tads source files that I could
    test the compilers with. Both the TADS2 and TADS3 compilers appear to
    be working fine, but I haven't done anything but the simplest
    tests--namely checking to see that I do get a compiled game file that
    works.
  16. Archived from groups: rec.games.int-fiction (More info?)

    Sophie Fruehling wrote:
    > [...]
    > Anyway, I tried to compile it on BeOS, but no matter which gcc I use
    > (the original BeOS gcc 2.95.beos-special-thingy or gcc 3.4.3), it
    > chokes on wcslen and wcscpy, which my compilers don't seem to have.
    > Are these standard functions?

    If they're really (as Tor said) C99 functions, then they don't really
    belong in the base code; maybe Mike didn't know this. I'll introduce a
    check for these functions in the Autoconf script and provide fall-back
    implementations for systems that don't provide them. They code really
    should not require any C99 features.
  17. Archived from groups: rec.games.int-fiction (More info?)

    David Picton wrote:
    > [...]
    > My experience with a Solaris box was good. The only significant
    > problem was with the resizing code, but this compiled and executed
    > correctly once I'd linked with release 5.4 of ncurses.

    The intention is actually to make it work with plain curses, so that
    there should be no need to update to ncurses in the first place.
    Expect a patch soon.
  18. Archived from groups: rec.games.int-fiction (More info?)

    drfreeze wrote:
    >
    > Now that I have this portable port running on Mac OS X, I've been
    > playing with it. It seems to work fine, but I'm no power user of TADS.
    > Are there any specific games I should try with frobtads that would
    > give it a good work out? Are there good tads source files that I could
    > test the compilers with.

    The best Tads 3 stress test is already in the package; the library
    sampler. Just compile it with:

    make sample

    after the compiler is built. You could also run the Tads 3 test suite;
    the INSTALL file has info on it.
  19. Archived from groups: rec.games.int-fiction (More info?)

    Mike Roberts wrote:
    >
    > Nikos - I'm not sure if there's an easy autoconfig way to detect whether the
    > wcsxxx functions are available, but if there is, adding in the wc_patch
    > stuff where needed could be part of your autoconfig script.

    That's the one single thing Autoconf is best at. It's trivial to
    introduce this check. Will be in the next update.
  20. Archived from groups: rec.games.int-fiction (More info?)

    "Sophie Fruehling" <sfruehling@LOVELY-SPAM.aon.at> wrote:
    > Anyway, I tried to compile it on BeOS, but no matter which gcc
    > I use (the original BeOS gcc 2.95.beos-special-thingy or gcc
    > 3.4.3), it chokes on wcslen and wcscpy, which my compilers
    > don't seem to have. Are these standard functions?

    They are, but not they're not universal at this point. For compilers that
    don't provide them, there are portable implementations in the tads3/wc_patch
    subdirectory - just add tads3/wc_patch/wchar.c to your makefile, and add
    tads3/wc_patch to your include path, and it should work.

    Nikos - I'm not sure if there's an easy autoconfig way to detect whether the
    wcsxxx functions are available, but if there is, adding in the wc_patch
    stuff where needed could be part of your autoconfig script. If not, maybe
    the solution would be to add a manual autoconfig option, if that's possible.
    Alternatively, it might work to compile in wc_patch unconditionally on
    Unix - presumably the explicitly-linked versions of the functions would just
    override any libc versions without conflict. The wc_patch versions are
    (barring bugs) functionally equivalent to any libc implementation, so the
    only disadvantage of overriding libc versions would be that the libc
    versions might be better optimized - and that should be insignificant, since
    these are small functions that aren't called enough to matter.

    --Mike
    mjr underscore at hotmail dot com
  21. Archived from groups: rec.games.int-fiction (More info?)

    Nikos Chantziaras wrote:
    > drfreeze wrote:
    >
    >>Now that I have this portable port running on Mac OS X, I've been
    >>playing with it. It seems to work fine, but I'm no power user of TADS.
    >>Are there any specific games I should try with frobtads that would
    >>give it a good work out? Are there good tads source files that I could
    >>test the compilers with.
    >
    >
    > The best Tads 3 stress test is already in the package; the library
    > sampler. Just compile it with:
    >
    > make sample
    >
    > after the compiler is built. You could also run the Tads 3 test suite;
    > the INSTALL file has info on it.
    >

    Check. So far so good. No problems on this end. The sample.t3 game
    plays well.
  22. Archived from groups: rec.games.int-fiction (More info?)

    In article <1121973883.793526.43680@f14g2000cwb.googlegroups.com>,
    "Nikos Chantziaras" <realnc@hotmail.com> wrote:

    > Uli Kusterer wrote:
    > >
    > > But I vaguely remember that GNUstep gave a similar error message when I
    > > tried to compile it with a non-GNU GCC, so maybe that is exactly the
    > > problem...
    >
    > It would be nice if such error messages would be reported back to me.

    I filed bugs against this and I had whole threads on gnustep-discuss
    where people tried to help me. In the end I got a pretty broken
    installation and everyone told me that was how it's supposed to be. Then
    I reported bugs and then real life called.

    -- Uli
    http://www.zathras.de
  23. Archived from groups: rec.games.int-fiction (More info?)

    "Mike Roberts" <mjr_@hotmail.com> wrote:
    > "Sophie Fruehling" <sfruehling@LOVELY-SPAM.aon.at> wrote:
    > > Anyway, I tried to compile it on BeOS, but no matter which gcc
    > > I use (the original BeOS gcc 2.95.beos-special-thingy or gcc
    > > 3.4.3), it chokes on wcslen and wcscpy, which my compilers
    > > don't seem to have. Are these standard functions?
    >
    > They are, but not they're not universal at this point.

    Ah. I thought gcc 3 was more or less C99-compliant, so I was wondering.

    > For compilers that
    > don't provide them, there are portable implementations in the
    tads3/wc_patch
    > subdirectory - just add tads3/wc_patch/wchar.c to your makefile, and add
    > tads3/wc_patch to your include path, and it should work.

    That's great, thank you. I haven't tried it yet, though, so I can't tell
    whether it works.

    Sophie
  24. Archived from groups: rec.games.int-fiction (More info?)

    (Hope my new news server works... Better than Google, in any case.)

    Sophie Fruehling wrote:
    >
    > "Mike Roberts" <mjr_@hotmail.com> wrote:
    > > "Sophie Fruehling" <sfruehling@LOVELY-SPAM.aon.at> wrote:
    > > > Anyway, I tried to compile it on BeOS, but no matter which gcc
    > > > I use (the original BeOS gcc 2.95.beos-special-thingy or gcc
    > > > 3.4.3), it chokes on wcslen and wcscpy, which my compilers
    > > > don't seem to have. Are these standard functions?
    > >
    > > They are, but not they're not universal at this point.
    >
    > Ah. I thought gcc 3 was more or less C99-compliant, so I was
    > wondering.

    Well, the compiler has C99 support. I guess it's the version of the C
    library you're using that lacks these routines (after all, the compiler only
    compiles code, it doesn't offer any functions; that's the library's task).
Ask a new question

Read More

Games Video Games