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

G

Guest

Guest
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
 
G

Guest

Guest
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
 
G

Guest

Guest
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
 
G

Guest

Guest
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.
 
G

Guest

Guest
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.
 
G

Guest

Guest
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++.
 
G

Guest

Guest
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...)
 
G

Guest

Guest
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.
 
G

Guest

Guest
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
 
G

Guest

Guest
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.
 
G

Guest

Guest
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
 
G

Guest

Guest
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?
 
G

Guest

Guest
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?
 
G

Guest

Guest
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.
 
G

Guest

Guest
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.
 
G

Guest

Guest
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.
 
G

Guest

Guest
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.
 
G

Guest

Guest
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.
 
G

Guest

Guest
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.
 
G

Guest

Guest
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
 
G

Guest

Guest
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.
 
G

Guest

Guest
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
 
G

Guest

Guest
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
 
G

Guest

Guest
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).