# Re: a book or tutorial

```On Tue, 27 Mar 2001, Steve Baker wrote:

> Mads Bondo Dydensborg wrote:

> > In practice, I would say that today you have very little reason to know
> > about how to scanconvert your own lines using only integer arithmics, etc.
> > If you are not (somehow) using hardware for this (even in 2d), you are
> > doing something wrong. (Exceptions are if you are writing a general
> > purpose library, like Mesa, or the GIMP or something similar).
>
> It's like this:
>
>   1) You need to know stuff like that.  How to scan convert a line for
>      example - because it comes up in other context.  Less than a week
>      ago I needed to check whether two characters in a game could see
>      each other over a lot of intervening terrain.  I had a height map
>      of the terrain built - and one way to test for intervisibility was
>      to walk across the height map using Bresenhams line drawing algorithm
>      in 3 dimensions. (It turned out that I used a MIPmapping trick and
>      did it better/faster without that).
>
>      So, these old techniques are useful even when you have hardware 3D.

This is a good example of why I must retract part of my statements. Ok,
doing a line between to arbitrary points in space may be usefull. OTOH you
ended up not doing it. So, knowing the algorithm is probably
usefull. Knowing how to optimize it for 486 assembler is probably not.

And, btw. wouldn't the most correct solution be to determine if there are
any line of sigth with a "cone"? Starting from one of the figures
viewpoints the outline of the cone would be sort of shaped like the other
figure? Isn't that like casting a light? Couldn't you place a light in one
of your figures viewpoint, direct it a the center of the other figure, let
it shine, and see if the other figure received any of the light? Couldn't
you maybe use hardware for this?

And even if you didn't do it like that - if you use a triangle
representation, couldn't you traverse the triangles between the two
figures, determing if any intercepted the line between them? Might have
been an OK solution?

The ? are serious - I have no idea if I am rambling.

>   2) OTOH - with modern CPU's and graphics cards, you can very often get
>      graphics that are PLENTY good enough without the need to optimise
>      the heck out of it.  Code that's written clearly and without a lot
>      of bizarre twists to optimise it is generally easier to read and debug
>      and to re-use in future projects.  So DON'T OPTIMISE UNLESS YOU HAVE TO.

Amen.

>
>   3) Very often, you'll get a better game if you spend those valuable man-hours
>      writing deeper plots, more subtle puzzles, more weapon types, more bad guys,
>      etc, etc.  We may well not need 60Hz frame rates if the games is 'better'
>      for other reasons.

Exactly. OTOH freeing up CPU cycles may leave room for AI improvements,
and so on.

>
> So, there are times when you need to optimise something to death - but I certainly
> don't agree with the virtual obsession with some people to squeeze every last
> machine cycle out of an algorithm.

Exactly.
>
> > BTW: I have the greatest respect for Mike Abrash's work. I just don't
> > think its worth investigating it today. Unless you have a special interest
> > in these kind of things. The time spent reading about optimizing a texture
> > mapper for a 386 is just better spent profiling your own code, and making
> > sure you understand and use your graphics library as optimal as possible.
>
> Yes - but that's an *OLD* book - and when it was written, that was what you
> had to do.

Actually the "black book" is a collection of books, that was printed in
1997. (OK, that may be old). It was marketed as containing all the goodies
of his older books, and lots of new exiciting stuff about Quake.

Having never read his books, I bought it, and I consider it a waste of
money. I may have overreacted a bit in my reaction to forgot-whos
mentioning of it as *the* book. Certainly there are better books available
that are quite a bit more relevant today.

I am _not_ against learning books, and not against learning to "crawl
before you walk". I just wish people would finish their games instead of
optimizing their line drawing routines.

> There *are* still times when knowing these ancient algorithms is useful though.
> Just like we still spend YEARS of our childrens education teaching them
> long multiplication and long division - only to present them with \$3 calculators
> the day after they finally grok it all...so we need to spend *some* time to
> understand these old tricks - just so they available when we need them - as
> with my intervisibility problem a few days ago.

In principle I agree. In practice I am bit more so-and-so on many of the
techniques. Each of us only have very limited time available (so, why am I
writing this? ;-) - often the time is better spent with other kinds of
game related problems and their solutions.