NeoThermic wrote:Again, I never had such issues. I'd assume, then, that these are bugs native to the Linux version?
I don't think so. I've been tinkering a lot with "circuit bending" mods where I take advantage of unusual parameter sets and special unit and building setups to achieve novel behaviors probably never intended by Chris. I've verified that most if not all of these quirks behave the same under WinXP on the same machine (although with sometimes 50% the fps preformance, even with all the most recent drivers).
Probably your system balance is CPU heavy compared to mine. I've got a 1.8GHz single core Athlon and an old Nvidia 6600GS (LE < GS < GT) 128K GDDR2 running the proprietary Nvidia drivers, but the old 7174 release. So I'd guess you aren't seeing the CPU bound behavior I'm seeing. There's no way I can even get close to 50K DGs. I think my system tops out somewhere between 5-10K without any AI challenges (not AIUnit directed behaviors). Battles involving 2-3k on each side are passable at maybe 20fps.
Here's another observation to back up what I'm saying (at least on my sytem). I can place or spawn a patch of several thousand virii with no problem as long as they have no enemies to attack or other things to track. Rendering at a distance is fine, but extreme closeups chug. (The engine doesn't seem efficient when compositing thousands of texture maps with transparency -- maybe that's my GPU?) Anyhow, as soon as souls start to appear on the map, fps drops -- presumably because virii are now searching for them and the data structs aren't optimised for mass searches. Once the souls rise (or if a global SpawnPtMaster is placed on the map) the fps also rises.
Another example is with laserfences. I have a test level with a couple hundred fence segments which rise and fall randomly. (Hard maximum transparent bldgs = 255 or 256 = laserfence segmants + trees.) Every time a segment finishes changing state, the entire ObstructionGrid is recalculated for the whole map. I can watch the server messages for this in a terminal window. On this particular level each full recalc takes 50-60ms. So whenever 5-10 segments change state simultaneously, huge CPU stalls of 0.5-1.0sec occur. Obviously an optimised approach would use a data struct that could add and remove individual segmants (and other building obsticles) without having to recalculate the entire ObstructionGrid. But it is what it is.
What I'm seeing is definitely CPU bound behavior -- bumping up against data struct searches that were never optimised for heavy use. Or at least that's what I tell myself....
I'm not arguing that CPU >> GPU for all performance issues. That would be silly. But on systems similar to mine, I'd bet that peformance is limited mostly by CPU as long as you have a modest GPU. And I think GPU performance will scale much better than CPU because drivers are optimised while it seems lots of data searches are not optimised in the darwinia engine. Notably the neighbor searches, and especially when they have to deal explicitly with the third dimension (like when DGs aim lasers into the sky).
Obviously you and I are both running the engine far outside it's design parameters!
But that's fun, isn't it?
However, CPU bound issues normally keep quiet as the GPU lets down first. Laptops are always a good example of this 
... umm, I mean, I guess I'll just drop this point - conceded, it doesn't slow down at all beyond normal exponential decay.