From: Andrew Apted <ajapted AT netspace DOT net DOT au>
Date: Tue, 12 Sep 2000 16:38:18 +1000
To: djgpp AT delorie DOT com
Subject: Re: Threading Advice
Message-ID: <20000912163818.A1204@ajax.netspace.net.au>
References: <968648551 DOT 338928 AT shelley DOT paradise DOT net DOT nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <968648551.338928@shelley.paradise.net.nz>; from ejrh@paradise.net.nz on Mon, Sep 11, 2000 at 05:04:35PM +1200
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Edmund Horner writes:

>  My game has several things it needs to be doing all the time:
>  
>  1. Redrawing the screen.
>  2. Responding to input.
>  3. Moving and updating units.
>  4. Occassionally doing big things like pathfinding.
>  
>  Can any of you guys tell me whether I would be advised to use real
>  threading, or how I can accomplish an adequate solution without it?

For a game engine, I wouldn't recommend using threads.  DOOM does fine
without them: it breaks each second into 35 "tics", and for each tic
it updates the play simulation.  The basic game loop is:
  
  1. Redraw screen
  2. Get/handle input
  3. Compute how many tics have elapsed since last loop
  4. For each tic, perform 1/35 second of simulation
  5. Goto #1

For big things, try to do a little bit each tic rather than the whole
lot at once.  Precomputing some data might help too (e.g. DOOM has a
utility for determining which areas of a level cannot see each other,
allowing many monster line-of-sight tests to be skipped).

Cheers,
__
\/   Andrew Apted  <ajapted AT users DOT sourceforge DOT net>