Batch, batch, batch, that's the name of the game.

Are you guys really taking advantage of the multicore systems so abundant today?

Ah, something related to dynamic dispatch?

I've found game component systems to be very hard to get right. If you take the standard hierarchical path, it's far too rigid and hard to adapt in all the strange ways that games tend to require.

It'd be nice if Elemental could use all 8 threads on my i7, but at least 4 is absolutely necessary. I want good AI, and if it takes more CPU power, then by all means use it.

The map sizes you guys churned out for gc2 are what made it for me, I still remember when that immense size came out...man that was funny stuff...and awesome! I guess that's what performance means to me, have a good week!

Oh...any idea what a lower end system is for elemental? ballpark? anything?

I have no idea of the exact specs, maybe a dev will answer, but I would guess any level of computer that is still in use in the U.S. in decent numbers. Go to Newegg.com and look at the lowest components available at any price, and that would probably be a good idea.

My guess would be 1 gig of RAM, 128 Meg video card, I have no idea what is considered a low end CPU, I am sure single processor CPUs are still in use... this is just me spitballing, I know nothing.

[quote who="Servius" comment="10"]

I pray every night that my pentium II, 250megs of ram and my voodoo II video card can run this!

[/quote]

Can you even run anything past Windows 3.11 with that?

I will add you to my prayers bro

I am sensing a perturbation in the kitchen. A good one.

Just the fact that you guys are concern that this game should work on lower end machine is a blessing to everybody who as three kids and is not rich enough to buy up to date computers all the time...

Thank you

You have a strange definition of "ok", methinks .

I had 512 MB ram with WinXp and while it certainly worked, having to use freeware programs to free up as much RAM as possible in between games was a real hassle, not to mention the massive swap file writing to the harddrive whenever I tabbed out of a game. After I installed 1.5GB in that PC, it was like entering heaven itself, the difference was unbelievable. I don't think I'd dare try it with 64MB

In my more modern computer, the jump from 2GB to 4GB (well, 3.4'ish with 32 bit XP) was awesome as well. From 4GB to 8 was good too, but nothing as noticable as the previous two.

It puzzles me a bit how games seem to demand increasingly more powerful graphics cards that cost oodles of money, but no one jumps on the 64bit wagon and shows us what they can do with 6-8GB of RAM. Can't we just leave 32 bit to die in a ditch already, please?

I'm pretty sure Stardock are unreasonably serious about this. If GC2 is a good comparison, I'd about bet money that with a very conservative set of video and audio options enabled on a sub-spec machine, the RTM version of the cloth map will play well enough even on middle-largish maps. That's how GC2 worked for me, anyway.

This is an example of what I dislike about talking about performance: giving a size to a dictionary will improve your insert time depending on the average size of the dictionary upon use. To be able to estimate that, you have to run tests, take metrics,... And unless it's a constant, sometimes you will end having to resize on an addition, so it's a pretty hard to measure this performance gain.

Performance is nice, but in lots of cases is hard to get an idea about where are the performance bottlenecks without the whole software running. You can spend 1 month and gain 50% performance in some code, and when the development advances discover that the code you improved uses 0.0001% of the computing time...

I prefer the idea of building things that work, and then, if they don't work fast enough, analyze why and make them run fast enough.

Yes you're right. Before optimizing you have to measure and figure out what to optimize.

My point  about giving a size is when knowing how many items will be inserted (forgot to specify it, my bad), like after getting back some data from a database. So at that time you may initialize the dictionary with the size of the query result, before inserting items.

It's simple, efficient and does not take 1 month to measure it or to implement. So why wait until a "slow" system when it can be done right at the beginning, when coding the 1st time?

And there is dozen other "case" like that..