glob2-devel
[Top][All Lists]
Advanced

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

Re: [glob2-devel] New unit allocation system almost done


From: Kai Antweiler
Subject: Re: [glob2-devel] New unit allocation system almost done
Date: Mon, 26 Mar 2007 12:29:12 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (linux)

What happens when a game is saved after you place one of the invisible
forbidden fields, but before it taken away again?
Does the reloaded savegame handle this correctly, or will this field
be an eternal blocker?


> I've looked into this. What I've observed is that forbidden ressource
> gradients don't recompute if none exist, saving a small ammount of
> CPU. 

I don't think this will save anything, since virtually everyone
uses forbidden areas for resource management.
(Unless we implement no harvest areas, which shouldn't be difficult
 and won't need gradients)


> Also, a unit getting trapped is no big deal. One square of
> forbidden gradient should cause the algorithm to quit quickly with its
> completed gradient.

That is only one part of the gradient computation.  This part is very
fast since Simon came up with his forbidden gradient optimization idea.
But initiating the gradient maps takes a long time.  For resource gradients
usually 1/5 of the time that the rest of the algorithm takes - if I remember
this correctly.


> Forbidden gradients aren't even close to a bottle
> neck. I highly doubt that even under heavy usage where we arranged the
> forbidden zones just right for maximum cpu usage, it still wouldn't go
> above 1% for the entire game.

Did you measure anything, or is this a blind guess?
The analogy of a bottleneck isn't quite correct.
Glob2 execution is in linear order (except for graphic/sound-calculation
done by graphic/sound-card).  All computation times add up.

By the way:
Can we profit from dual processors?
Those seem to become standard.
I have the impression, that we are memory intensive but don't rely
much on heavy computation.  Maybe a separate thread which creates a
queue of random numbers?


-- 
Kai Antweiler




reply via email to

[Prev in Thread] Current Thread [Next in Thread]