🚀 go-pugleaf

In article <1992Jul29.001213.57596@cc.usu.edu> sl8nl@cc.usu.edu writes:
>I didn't think the interest in text adventure compilers was still there,
>so I didn't release it in the first place.

Well there's plenty of interest.  So let's see it.  We've heard the
claims (which I'm sure you wouldn't make without having had a good look
at TADS first), so let's see the end product.  A precompiled game
without source would be fine if you don't want to make the system
itself available.

>It includes a great many more features.  Trust me, compilers aren't
>that hard to right...especially interpreted ones.

"Trust me, compilers aren't that hard to right (sic)."   And you've
written a compiler.  Ever look at the GCC/G++ source?  No problem; I
guess you could bang out those 100,000 lines in a couple weeks -- no
wait -- you'd write the equivalent in only a thousand lines and it
would fit in 18K.  Your blanket statement is just as absurd to me as
the notion that you could write TADS or an equivalent in two weeks.  I
wouldn't believe even Richard Stallman could write TADS or an
equivalent in two weeks (or even two months).

An interpreted anything is not a compiler, BTW, it's an interpreter.
(There are gray areas like microinterpreters for Forth, but your Lisp 
dialect isn't a gray area here.)

If you're going to disucss things here, please get a grip on reality
and stop wasting your time trying to convince everyone that difficult
things are completely trivial for you.  Not only is it transparent but
it annoys the hell out of people whose work you trivialize (and the
people who appreciate the work that went into others' systems).

>Maybe I'll make the system available, maybe I won't.  I'd have to dig
>it out of my archives.

Ahh, I see.  So trivial you just can't find it.

>Right?  Good.  Now that you understand that point, we'll get on with it.

Guess what, smart guy?  What you're describing is the *theory behind an
algorithm*; one that simplifies the problem a lot (like Apogee did in
Wolf 3D), but theory nonetheless.  You said, "who needs an algorithm,"
but you're using one yourself.  Your algorithm is neither trivial nor
trivial to explain, IMO, and is far from trivial to implement,
particularly in 80x86 assembly.

>A good perspective mapper must scale as it goes.  Bresenham can be used
>to create a scaling routine too that is super fast.  The entire perspective
>mapper is based on the Bresenham line drawing routine...the perspective
>is drawn by a pseudo-line drawer, and the scaling is done by the routine.

Bresenham's general algorithm doesn't count as an algorithm or theory?
Is it also trivial?  As with the 3-D bitmaps discussion, we can *say*
all sorts of stuff like "just apply Bresenham's scaling algorithm, then
rotate the images in real-time, perform lighting calculations, and
viola!" very easily.  The implementation is far from trivial for such
things.  Anyone who thinks, e.g., that Origin (Blue Sky) didn't spend a
great deal of time on their 3-D texture mapping engine needs a serious
wake-up call.

I'm really not sure what your point is throughout this thread.  It
seems like you're just convinced that game design systems are
unnecessary because they're so incredibly trivial to write.  My
contention is that if you think that, you haven't seen a decent game
design system.  Your contention seems to be that you're so smart that
what everyone else spends years on only requires a few weeks of your
time.  Frankly, I don't believe that.

Dave Baggett
dmb@wam.umd.edu