64 or 32?

[Werewolf13]

Somehow, somewhen I got the impression that CMANO was a 64b executable. Today I noticed that it is actually a 32b executable.

If it is 64b where's the executable and if it is 32b are there plans to change it? If so when. Sure would make a difference.

[User2]

Hi.

While it is not difficult to recompile a VB.NET/C# source code into a 64bit app, the game uses lots of 32bit external dlls. That's the problem in my opinion: 64bit windows apps can not use 32bit libraries.
Besides, it may turn out that the performance boost of 32bit->64bit transformation will not be noticeable.

[Werewolf13]

Thanks for the reply. 32b then. Disappointing and explains a lot.

I agree with your take on recompile though IMO that's not the real issue. Recompiling is easy. What isn't is rewriting the code to take full advantage of multiple cores.

That said: even without rewriting to take advantage of multiple cores just being able to store everything in memory is IMO the single most impactive factor when it comes to overall performance (the most memory I've seen any game/simulation ever use is a bit over 12GB) and 16GB is getting closer and closer to becoming the norm.

Nice to know about the 32b DLL's. That is a big problem.

Thanks for the info. Interesting but disappointing.

[thewood1]

I think Command already uses multiple cores. Maybe not like a fully, from scratch, native 64 bit app.

[Dimitris]

Command already uses multiple core-threads, up to 4 depending on the scenario.

We also include special code to disappoint Werewolf13. It's a standard feature since v1.06.

[thewood1]

The disappointment code was left out of 1.14, wasn't it?

[ultradave]

ORIGINAL: Dimitris

Command already uses multiple core-threads, up to 4 depending on the scenario.

We also include special code to disappoint Werewolf13. It's a standard feature since v1.06.

Oh, man, now I have to clean the bourbon out of my keyboard!