[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a book or tutorial

Mads Bondo Dydensborg wrote:
> On Tue, 27 Mar 2001, Achilles wrote:
> >       I had a talk today with a professor from the computer science division
> > of my university and he told me that sometimes we may know a lot about
> > some more advanced subjects, but at the same time loose some really
> > practical knowledge about the really basic stuff. And that this
> > knowledge proves very useful when we really get down and dirty with
> > algorithms and techniques.
> I can totally agree (in principle) about algorithms and knowing about the
> basics. Read Folye and van Dam for that. Most of the stuff Mike Abrash do
> is in there, although he implements and optimizes it wildly.
> 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.

  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.

  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.

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.

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

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.

Steve Baker   HomeEmail: <sjbaker1@airmail.net>
              WorkEmail: <sjbaker@link.com>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net

To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.dk
For additional commands, e-mail: linuxgames-help@sunsite.dk