Add multiplayer to GC3 only if you are sure about that you do not have to sacrifice any cool features for single player or the game in general.

I agree 100% with that.

I also think that your team has took the good decision for GCIII (comes after the new  fantasy game). GC III will be just  better!!

Regards,

P.S. Sorry if my English is not good.

Can't wait to actually play or maybe beta test all the new nifty things, the good thing is, i just like every theme and Not-MoM will be very interesting.

Since you did understand all my crap your english should be fine. I'm german and usualy have alot of gramma issues or typos.

Actually, I think having multiplayer component can only enchance single player AI.

That way, when early testers start to play with each other they can more easliy think of the good strategies that can be lated coded into AI. Also, having AI open to moding would be even better.

It worked greatly for Civ4.

Shader 3 - that's DirectX 9, right? That's the GeForce 6 and 7 series - you should be able to get one for $20.

But hey - if they support shader 2, that's great . The more systems it supports, the better.

Well, a possible issue with this method is that some threads may barely be using the cores, while others might saturate the core(s). You may get uneven usage, and if there are a lot more threads than cores, overhead may become an issue.

For maximum performance and minimum overhead, the ideal number of threads is the number of cores the system has, and each thread should have the same workload as the other threads.

There's an intresting article at Ars Technica about how Valve decided to takle multiple cores. Might be worth a look.

No matter what Valve decided to use they still must heap the stack like everyone else - pipelining their ways to indirect leveling of call ops shouldn't (correct this -- CAN'T) raise the bar on available resources provided by whatever happens to connect with the target 'devices'.

But, i've seen engines so tricky (registry dispatch, off'top'of'my'silly'head) - current facts may just be old news -- since last i checked for the latest gimmicks.

The downside is with multiplayer, games get figured out a lot more quickly as well.

"indirect levelling of call ops?"

Those words make perfect sense separately, but not in the way you put them together.

The article states, by the way, that the results were better than expected:

Oh, but i agree with the assumption or proof that this 'simultaneous threading with FOUR target devices' is an excellent solution (given Valve has mastered the results, somehow) - it's just that *in principle at least* the entire experience has no formal application as of now (or even a predictable market until MUCH more home PCs enter the realm of quads or that they become common & widely supported)... never hurts to step ahead into good potential though. That's for sure and wishing outloud.

(I only meant when operands 'call ops' MUST be synchronized to be efficient enough... not far from what i used to see on *16* dispatched registries instead the a,d..x schemas!)

Besides, who's counting? The upcoming 128bits dream (technically 256 or 512 are still total fiction)? Or software engineers?

INTEL's best were certainly laughing at me in 86 when i was suggesting full 64 width pipelines on boiler plates near hell ratios. Time proved many wrong, including yours truly it seems. The tricky joke went really bad since, i say.

If i had to buy a card with shader 3 i would want atleast an high-end 7800+.

But yeah, s3 cards are actually cheap

The problem is seldomly the costs of the card, the problem often is lack of compatibility with modern hardware. Imagine someone having a PC with a single voltage AGP 2.0 slot (Many Pentium 3/Athlon class machines exist with it). A new video card means a new mainboard, therefore a new cpu and new memory. And if you do something like that, you often don't want to buy the cheapest of cheapest.

Still doable for someone with a normal salary by the way, but for some people, like young game players, it can become unaffordable.

Well, for Valve it means possible speedups in their physics and graphic engines. Graphics and physics are easily parellelizeable. You can easily split an image into separate sections, and each thread can perform computations on its section of the image.

. . . and why are we discussing "call ops" anyways? I don't see the connection between calls and threading. Not all calls are threads or cross thread boundaries. In fact, you want as little sharing of memory/calls/whatever as possible because synchronization can be expensive: As much as possible should remain inside the thread.

No OpenGL(2.1/3.0) support?

Just one silly 'clug' is too many, which is why multi-threading is an acrobatic attempt that requires extensive "monitoring" of conflicts... quite simply, a single re-allocation of some stack at the wrong nano-moment or shared location would collapse the entire advantages gained from synchronized accessing of specific memory. It's one thing to go fast, another to lag **because** CPU1 & CPU4 are battling for a memory call or even, double duty (wasting precious processing) on the exact same task.

Don't get me wrong, combining resources is an excellent function... all it takes is extremely precise coordination.

What OS(s) will be supported in both the Fantasy and GC3?