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 _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
