Mail Archives: djgpp/2000/09/11/22:47:40
Thanks for your advice, it sounds wise and is very encouraging.
BTW, what exactly are race conditions and mutexes, and would I really
encounter them if I used threads in a (relatively) simple program like this?
Thanks again,
Edmund.
> -----Original Message-----
> On Mon, 11 Sep 2000, Edmund Horner spoke the following immortal words,
>
> > 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?
>
> If you are not familiar and even if you are familiar with threads, my
> adivce would be don't use them, as there is no justification for using
> them when other simpler and equally(more?) effective methods are
> available.
>
> The trick is to do the above steps in a order, ie Responding to input,
> then updating the units, and then redrawng the screen. If the above are
> done fast enough it will give the illusion to the user that everything is
> hapenning at once, which is the effect that you want to achieve I assume.
>
> Also please consider this, if you use threads for each of the above tasks,
> you would have to worry about thread synchronization, and to prevent race
> conditions, mutexes etc....if you don't know much about those issues..then
> why bother with the added complexity and bugs that it might introduce.
>
> The plain and simple illusion method is the best IMHO.
>
> Great games like doom etc don't use threads, so there is no restriction in
> creating great games just because you don't use threads.
- Raw text -