🚀 go-pugleaf

In article <76626@ut-emx.uucp> baylor@ccwf.cc.utexas.edu (Baylor) writes:
>	I'd love a games library (I assume this is really a sprite 
>library; no hack and no reason to intigrate a good infocom parser).
>Many of you know that i've leached more code from you guys over the 
>past year than anyone else I know. I beg for code from different people
>to do things I quite often can already do.

(Baylor makes some good points here.  I'll use his message as sort of a
jumping off point for some related discussion.)

I suspect the folks who are more interested in a game library for its
educational value are in the minority.  When you use C++ (or Pascal
with Objects, to avoid the current debate), do you really have an urge
to get source for the compiler so you can "learn how to write your own
code?"  If your library were more than just a patchwork of routines why
would you care how the system worked overall, beyond what you needed to
know to get the most out of the system?

The argument that you should be able to subvert all the system's
freatures is parallel to an argument that says you should have source
to your C compiler so you can change the language syntax as you see
fit.  In general this is a bad idea since it's a substantial virtue to
have all people speaking the same dialect.  Suppose there were a
whizbang game development system for PC's: think about how difficult it
would make discussion if everyone had their own customized add-on
routines!  Portability is a good thing not only for porting, but for
cooperation as well.

When I write a program in C, I almost never care what the resulting
assembly looks like; likewise I care *even less* about how the compiler
does its job, *as long as the resulting exectuable works*.  I certainly
wouldn't go and edit the GCC source to change the for loop syntax to better
suit my liking; perhaps that's just me though.

I think the idea that a game library should be educational is simply
provoked by an outdated idea of what a game library (or a game
authoring system in general) should be.  If, when you talk about "a
game library," you're only considering a small, ungeneralized set of
functions for blitting objects around the screen and making some bleeps
and bloops on the console speaker, you're not really talking about a
"game system" at all, IMHO, anymore than you could classify a little
suite of your own favorite file handling utilities as an operating
system's I/O subsytem.

A game system is a massive undertaking, even if it's for a fairly
limited set of game styles.  Mike Roberts has been working on TADS
since 1987 or so, and that's just for text adventures.  The reason that
everyone (as a previous poster mentioned) starts their own game library
but bever finishes is the same reason most people start a *game* and
never finish, or start a *novel* and never finish.  It's a lot of work,
and requires *years* to complete.  As with all things in computer
science, it's easy to talk about but much, much harder to *do*.

Game systems are also geared towards niche markets.  Sure, *you folks*
might give your eyeteeth for a good game system, but how would the
potential sales of such a system compare to word processor sales, or
compiler sales?  And following that up, if writing a game system is as
difficult as writing a word processor or compiiler, why would any
company write a game system instead of a word processor or compiler?
Why would any company put up all the money to finance the development
of such a labor-intensive and (at the same time) risky product?

Not only that, but a top rate game system would have to have as much
documentation as a good compiler, and similarly good technical support,
and believe me, these things are not easy or free.  It's not clear that
the market could even support the kind of game system you're looking
for, even if someone invested the time required to write it in the
first place.

>	That's because I love seeing how other people do things. I've never  
>actually used anyone else's code before - i just print out and highlight
>things that strike me then see if I can rewrite it from memory and quite
>often run it through several reference manuals.

In my opinion, the place for this kind of instruction is textbooks.
There really should be some texts on writing games, even if they're
specific to a particular platform.  The problem is that no game writers
want to write books; they want to write games.

>	The graphics books out there don't really cover anything to useful
>to games programming (except maybe the never-can-find abrash book).

For a real laugh, look up the "animation" section in *any* porpular PC
graphics book.  What a joke!  They'll tell you to use XOR for pete's
sake.  Or "simply erase the old image and draw it in the new location,"
as if you could actually get any decent results without some
approximation of double buffering (page flipping).

(BTW, does *anyone* have a copy of Abrash?  Where can you get it?  I've
tried every big bookstore I know and no one's ever heard of it.)

What the PC-UGLY crew should do is write a book.  I don't think library
design is manageable (as has been evidenced here annually), and
language design by committee is even worse (e.g., Ada), but perhaps a
book would be easier to coordinate.  There's already a lot of
documentation available on the net (including source code) -- a major
part of the task would just be assembling the pieces.

Dave Baggett
dmb@wam.umd.edu

In article <1992Jul27.141122.11139@wam.umd.edu> dmb@wam.umd.edu (David M. Baggett) writes:
>
>>	The graphics books out there don't really cover anything to useful
>>to games programming (except maybe the never-can-find abrash book).
>
>(BTW, does *anyone* have a copy of Abrash?  Where can you get it?  I've
>tried every big bookstore I know and no one's ever heard of it.)

Depending on which Abrash book you're talking about, it may be out of
print. Abrash's "Zen of Assembly Language," which I very much wanted a
copy of but no local bookstore ever carried, went out of print just a
couple months before I got fed up waiting to find it in a store and
tried to mail order it. :-(

In article <Bs1z68.Dt3@news.cso.uiuc.edu> tmkk@uiuc.edu (Khan) writes:
>
>In article <1992Jul27.141122.11139@wam.umd.edu> dmb@wam.umd.edu (David M. Baggett) writes:
>>
>>>	The graphics books out there don't really cover anything to useful
>>>to games programming (except maybe the never-can-find abrash book).
>>
>>(BTW, does *anyone* have a copy of Abrash?  Where can you get it?  I've
>>tried every big bookstore I know and no one's ever heard of it.)
>
>Depending on which Abrash book you're talking about, it may be out of
>print. Abrash's "Zen of Assembly Language," which I very much wanted a
>copy of but no local bookstore ever carried, went out of print just a
>couple months before I got fed up waiting to find it in a store and
>tried to mail order it. :-(
>

Is this the same guy that writes for Dr. Dobb's?  If so, I believe he was
going to put out a book based on his series of articles on PC graphics.
I'm pretty sure the publisher was going to be M&T books.  If you can't locate
the book, look for back-issues of Dr. Dobb's.  Also, I found his code
somewhere on anonymous ftp.  Can't remember where, but if I was looking, I'd
start with wuarchive.wustl.edu.  Good luck.

> When I write a program in C, I almost never care what the resulting
> assembly looks like; likewise I care *even less* about how the compiler
> does its job, *as long as the resulting exectuable works*.  I certainly
> wouldn't go and edit the GCC source to change the for loop syntax to better
> suit my liking; perhaps that's just me though.

That's you.  I have to know what the assembly looks like.

> A game system is a massive undertaking, even if it's for a fairly
> limited set of game styles.  Mike Roberts has been working on TADS
> since 1987 or so, and that's just for text adventures.  The reason that

I dunno.  My text adventure compiler handled everything (it was similar
to the ADVSYS library), and it took me a couple of weeks.  I could do
everything Infocom could do and more.  The resulting executable was 18k.

> everyone (as a previous poster mentioned) starts their own game library
> but bever finishes is the same reason most people start a *game* and
> never finish, or start a *novel* and never finish.  It's a lot of work,
> and requires *years* to complete.  As with all things in computer
> science, it's easy to talk about but much, much harder to *do*.

True.

>>	That's because I love seeing how other people do things. I've never  
>>actually used anyone else's code before - i just print out and highlight
>>things that strike me then see if I can rewrite it from memory and quite
>>often run it through several reference manuals.
> 
> In my opinion, the place for this kind of instruction is textbooks.
> There really should be some texts on writing games, even if they're
> specific to a particular platform.  The problem is that no game writers
> want to write books; they want to write games.

Since when did textbooks offer you the advanced info only professionals know?

> (BTW, does *anyone* have a copy of Abrash?  Where can you get it?  I've
> tried every big bookstore I know and no one's ever heard of it.)

Que
11711 N. College
Carmel, IN 4603{

Power Graphics Programming $24.95

Call 1-800-428-5331.

That's the info in my book!

Josh

In <1992Jul27.190320.57533@cc.usu.edu> sl8nl@cc.usu.edu writes:

>> A game system is a massive undertaking, even if it's for a fairly
>> limited set of game styles.  Mike Roberts has been working on TADS
>> since 1987 or so, and that's just for text adventures.  The reason that

>I dunno.  My text adventure compiler handled everything (it was similar
>to the ADVSYS library), and it took me a couple of weeks.  I could do
>everything Infocom could do and more.  The resulting executable was 18k.

Cough!  Splutter!


I think you should check out TADS, if you think that ANY 18k program stands
a chance of even coming CLOSE to equal.  Sure, I can write any of the Infocom
games with just a BASUC interpretter, but TADS would make life much easier...


--
Warwick
--
  _-_|\      warwick@cs.uq.oz.au            /Disclaimer:
 /     * <-- Computer Science Department,  /  
 \_.-._/     University of Queensland,    /      void (if removed)
      v      Brisbane, Australia.        /  

In article <1992Jul27.190320.57533@cc.usu.edu> sl8nl@cc.usu.edu writes:
>> A game system is a massive undertaking, even if it's for a fairly
>> limited set of game styles.  Mike Roberts has been working on TADS
>> since 1987 or so, and that's just for text adventures.  The reason that
>
>I dunno.  My text adventure compiler handled everything (it was similar
>to the ADVSYS library), and it took me a couple of weeks.  I could do
>everything Infocom could do and more.  The resulting executable was 18k.

If you wrote it in a couple weeks, believe me, it doesn't handle
anywhere near "everything."  You're falling into the same trap I
mentioned before:  using a totally outdated notion of what a "game
design system" is.  A decent game design system is far more than just a
suite of routines you write for your personal use.  You can do
"everything Infocom could do and more" directly in C, but that's not
what we're talking about here -- a game design system should take care
of all (or at least many) the tedious grungy details for you.  E.g., if
I want to extend the parser in a TADS game, I need only define a new
"deepverb" object.  If I want to add an actor I just have to say,
"foobar: actor" and supply some simple methods.  This is a far cry from
having to write everything directly in C.

It's the same kind of thing as the "sprite library vs. blitting library"
distinction.  A sprite library deals with _sprites_ -- objects that
operate at a higher level that just raw image data.  A sprite should
animate automatically (whether via interrupts or otherwise), should
be able to detect its own collisions and report them to the programmer
on queries, etc.  There's a lot more to this than just moving shapes
around.  Moving shapes around is the boring work that a game programmer
shouldn't have to do -- it's not interesting from a programming standpoint
and has no bearing on the design of the game.

I really feel that a game design system is one that allows the
programmer to spend his/her time on *design* rather than programming.
Some people would rather write every last line of code in assembly, and
for those people a game design system is not attractive.  For people
who just want to write *games* (as opposed to game *code*), a game
design system is better than sliced bread.  IMHO, TADS is such a
system.

>> There really should be some texts on writing games, even if they're
>> specific to a particular platform.  The problem is that no game writers
>> want to write books; they want to write games.
>
>Since when did textbooks offer you the advanced info only professionals know?

Well, almost all the time, for most fields.  Even within computer
science it's rare that you *cannot* find documentation that describes
an algorithm or process.  Most CS texts go into a lot more detail than
many professionals would use, in fact.

A good example from game programming is the nifty texture mapping that
Origin and Apogee use for their 3D games.  That technology has been
around for several years (check SIGGRAPH proceedings) and is
well-documented in many places.  Sure, the optimizations that make the
process possible on a 386 are not freely available, but one would hope
that with a firm understanding of the algorithm you could adapt it to
80x86 assembly language yourself.  Specifics like this would be good
topics for the Internet PC Graphics Guide.  1/2 :)

Dave Baggett
dmb@wam.umd.edu

>>I dunno.  My text adventure compiler handled everything (it was similar
>>to the ADVSYS library), and it took me a couple of weeks.  I could do
>>everything Infocom could do and more.  The resulting executable was 18k.
> 
> Cough!  Splutter!
> 
> 
> I think you should check out TADS, if you think that ANY 18k program stands
> a chance of even coming CLOSE to equal.  Sure, I can write any of the Infocom
> games with just a BASUC interpretter, but TADS would make life much easier...

I did.  That's why I wrote mine.  It works kind of like this:

  (define room
     (property north,south,east,west)
     (property desc)
  )

and then I would go like this

(room WaterRoom
  (north Room1)
  (south Room2)
  (desc  This is my description)
)

and so on...

TADS is more structured.  My language could be written to simulate an ELIZA
program if I wanted.

Josh

>>I dunno.  My text adventure compiler handled everything (it was similar
>>to the ADVSYS library), and it took me a couple of weeks.  I could do
>>everything Infocom could do and more.  The resulting executable was 18k.
> 
> If you wrote it in a couple weeks, believe me, it doesn't handle
> anywhere near "everything."  You're falling into the same trap I
> mentioned before:  using a totally outdated notion of what a "game
> design system" is.  A decent game design system is far more than just a
> suite of routines you write for your personal use.  You can do
> "everything Infocom could do and more" directly in C, but that's not
> what we're talking about here -- a game design system should take care
> of all (or at least many) the tedious grungy details for you.  E.g., if
> I want to extend the parser in a TADS game, I need only define a new
> "deepverb" object.  If I want to add an actor I just have to say,
> "foobar: actor" and supply some simple methods.  This is a far cry from
> having to write everything directly in C.

So does mine.  That class is included in an include file.  I just go:

(noun Monster
  (adjective Grungy, Dirty, Ugly)
  (synonym Thing)
)

and so on.


> A good example from game programming is the nifty texture mapping that
> Origin and Apogee use for their 3D games.  That technology has been
> around for several years (check SIGGRAPH proceedings) and is
> well-documented in many places.  Sure, the optimizations that make the
> process possible on a 386 are not freely available, but one would hope
> that with a firm understanding of the algorithm you could adapt it to
> 80x86 assembly language yourself.  Specifics like this would be good
> topics for the Internet PC Graphics Guide.  1/2 :)

Who needs an algorithm?  I did it with a modified Bresenham line drawing
routine.  As fast as it could possibly go...unless there is a method
to zap it there instantly.
\
My game language was written generally enough that it could handle any 
text oriented operation.  With the proper class designations, I can 
simulate anything.

Josh

I've got the Abrash book.  I'm not sure where to get more, but if you need
anything out if it, give me a buzz and I'll see what I can do.

Gary

In article <1992Jul27.141122.11139@wam.umd.edu> dmb@wam.umd.edu (David M. Baggett) writes:
>In article <76626@ut-emx.uucp> baylor@ccwf.cc.utexas.edu (Baylor) writes:
>
>>	The graphics books out there don't really cover anything to useful
>>to games programming (except maybe the never-can-find abrash book).
>
>
>(BTW, does *anyone* have a copy of Abrash?  Where can you get it?  I've
>tried every big bookstore I know and no one's ever heard of it.)
>
>
>Dave Baggett
>dmb@wam.umd.edu

The closest I have come is at B. Dalton, where they looked his name up, found
the titles of his two books, then boldy pronounced "They're no longer in 
print." ie:  the publisher stopped publishing them.  

I'm planning on getting Abrash's address out of DDJ and writing him a letter
to see if he has any stashed in his back room he'd mind sharing with me.

 
Matt Smith
msmith@peruvian.utah.edu
Student - University of Utah Department of Computer Science

I'd sure like to have access to a 3d game library. There's a simulator I
want to do, but I want to prototype; I don't want to recreate a wheel
that's been created 500 times.

Sean

-- 
                  |``Wind, waves, etc. are breakdowns in the face of the
Sean Casey        | commitment to getting from here to there. But they are the
sean@s.ms.uky.edu | conditions for sailing -- not something to be gotten rid
U of KY, Lexington| of, but something to be danced with.''

>In article <1992Jul31.082534.12208@hellgate.utah.edu> msmith%peruvian.utah.edu@cs.utah.edu (Matthew Smith) writes:

>The closest I have come is at B. Dalton, where they looked his name up, found
>the titles of his two books, then boldy pronounced "They're no longer in 
>print." ie:  the publisher stopped publishing them.  
>
>I'm planning on getting Abrash's address out of DDJ and writing him a letter
>to see if he has any stashed in his back room he'd mind sharing with me.
>
>Matt Smith
>msmith@peruvian.utah.edu
>Student - University of Utah Department of Computer Science
 
If you subscribe to DDJ, you get their standard set of junk mail, err, I mean
programmer information.  Eventually, you'll get somthing called the 
Programmer's Power Pack.  This is a set of index-like cards which various
advertisers use.  Well, on one of the cards, it advertised the re-publishing
of the Abrash _Zen of Assembly Language Programming_.  So, I believe it is
back in print.  Also, the _Assembly Language From Square One_ is also being
re-printed.  Since I already have the Zen book, I threw away my cards, so
that's the only info I have. 

For hard-to-get books, you might want to try inter-library loan.  I have
found the _Power Graphics Programming_ book by Abrash in this way.  My
mom and I have used this, and have *never* failed to find a book that we
were looking for.  Granted, you don't own it, but you can at least get a
a copy of the book for a while to look at.

Mike Burns