Gigahertz race was over ages ago

[Peter_Bullet 0]

When OFP came out, it required 700 MHZ processor to play smoothly. When I got it, I had 1.5GHZ processor. Needles to say, large battles played nicely in the mission editor.

Does anyone remember a mission called "Abandoned Armies"? -If you haven't played AA, you haven't played OFP, they said on OFPEC forums, "OFP was built for this kind of battles". AA was a huge whole Island sized battle with 400+ soldiers.

Recommended was a 3GHZ processor. I couldn't play it. This mission required 4 times more CPU power than the original game. The reason why this mission was possible, was the increase in the clock frequency of microprocessors. (Finally we got a new computer. The 2.5ghz dual core would run this mission with only 20fps..)

Let's assume ArmA II will run on 2.5ghz dual core. If someone wanted to make Abandoned Armies for Arma II, he would require 10GHZ dual core. However, even 5ghz processors will propably never come out (the higher the frequency, the smaller the chip has to be. However, the heat output is much bigger). However we will have 2.5ghz 16-core processor one day. (intel has said one day they will produce 100-core processors)

This is why Arma II really should support Multicore (according to intel, multicore means ability to take advantage of ANY number of processors). A BIS developer said on another thread "ArmaII might run better on a 3.5ghz dualcore than 2.5ghz quad core". A guy replied "So 3.5ghz quad core it is" This is ridicculous, I don't think you can even get 3.5GHZ dualcore without overclocking. (maybe you can, but you get the point) People are talking about technology that may never exist.

It really doesn't matter if you play COD4 on 2.5 or 10GHZ processor, it runs smoothly anyway. There isn't room for adding more units. But in a game like OFP and ARMA, anything is possible with more efficient hardware. One day you could make chernarus a real living world with hundreds of civilians and thousands of soldiers.

However, without n-core support, that will never be possible. There will never be 30GHZ processors. I do understand that syncing the cores is a very difficult task, and BIS propably doesn't have the resources to implement it, but maybe in future patch and definitely in Arma III.

Ps. I used to think OFP2 will kick Arma's ass. However, having observed both forums and listened to sahrani radio, I am really starting to think that arma2 will be awesome, Quad core or not. (OFP2 doesn't even have civilians or real ingame screenies) I just hope they don't change the weapon simulation (fun and realism is currently perfectly balanced) and make better firing sounds (G36 was my favourite weapon in OFP, solely because it had such nice firing sound :P ).

Ps.Ps. Am I ready for Arma2?!?!?! I have 6.6ghz Liquid nitrogen cooled 8core processor and Geforce X26 000 with 8.5GB video memory.. Grow up kids, it's not the size, it's how you use it.

[Pulverizer 1]

tldr: Make ArmA2 support multithreading please. 5GHz processors will probably never come out.

[Deadfast 43]

Multi-core support is confirmed.

[Pyronick 21]

This is why I like valve's approach to multithreaded computing.

Their "Hybrid-Threading" is scalable to an infinite amount of threads as long as they are x86, as far as I know.

With all these other games being built with the expectation of 8 cores, they will require massive engine code rewriting for a proper sequel on the same engine.

The secret is to have a modular engine, which is updatable over the years.

And with the Steam platform, you'll never have outdated technology.

[Pulverizer 1]

What has Steam to do with game engines, it's just a distribution channel. I have Steam games that use exactly the same engine versions you get with normal patches. They don't magically support multi-threading or SLI and DX10 all of a sudden just because I downloaded them from Steam.

[Pyronick 21]

What has Steam to do with game engines, it's just a distribution channel. I have Steam games that use exactly the same engine versions you get with normal patches. They don't magically support multi-threading or SLI and DX10 all of a sudden just because I downloaded them from Steam.

Steam gives the developer the ability to update on the fly.

Specific Steam games like the Half-Life series and Red Orchestra: Ostfront 41-45 are updated regularly.

Most retail games have about 1 or 2 patches.

The games mentioned above have at least 8 patches.

Not because they are buggy, but because it's much easier to have a modular base to work it.

On top of that everybody gets the patch, most gamers (excl. all hardcore gamers) don't even know what a patch is.

I'm not talking about just Steam, any distribution platform which have automatic gamepatching would suffice.

Or an integrated solution, like including an auto patcher (with registration and game activation) in a game would work aswell.

[baddo 0]

From the BIS developer blog

http://www.bistudio.com/developers-blog/arma-2-expectations_en.html

Quote[/b] ]We are aiming for a mix of fine-grained and coarse-grained parallelism, similar to the way most other game developers seem to do.

it can be understood that they plan to use a combination of common threading models,

a) fixed number of threads pre-assigned for certain jobs (coarse-grained)

b) pool of threads waiting to do tasks (fine-grained)

The pool of threads would be the one which can scale up or down depending on how many processor cores a computer has.

[Pyronick 21]

From the BIS developer blog

http://www.bistudio.com/developers-blog/arma-2-expectations_en.html

Quote[/b] ]We are aiming for a mix of fine-grained and coarse-grained parallelism, similar to the way most other game developers seem to do.

it can be understood that they plan to use a combination of common threading models,

a) fixed number of threads pre-assigned for certain jobs (coarse-grained)

b) pool of threads waiting to do tasks (fine-grained)

The pool of threads would be the one which can scale up or down depending on how many processor cores a computer has.

Yes, this is similar to valve's Hybrid-Threading, aswell as CryENGINE 2.0's SMT implementation I believe.

As long as it's properly (hopefully infinitively) scalable, it should work just great.

You never know what hardware changes are going to come in the next years.

Before you know it we'll have a superscaler CPU divided over hundreds of Pentium Pro like cores.

If the software can only address 8 cores, how on earth would Armed Assault 2 work?

[Pulverizer 1]

Quote[/b] ]Before you know it we'll have a superscaler CPU divided over hundreds of Pentium Pro like cores.

If the software can only address 8 cores, how on earth would Armed Assault 2 work?

How would anything at all work? It would render so much software useless that it could not happen overnight just like that. There's absolutely no sense in trying to take such drastic speculated changes into account.

The only way for software to be 100% future proof is to release it as source code and that's not gonna happen.

[Pyronick 21]

Quote[/b] ]Before you know it we'll have a superscaler CPU divided over hundreds of Pentium Pro like cores.

If the software can only address 8 cores, how on earth would Armed Assault 2 work?

How would anything at all work? It would render so much software useless that it could not happen overnight just like that. There's absolutely no sense in trying to take such drastic speculated changes into account.

The only way for software to be 100% future proof is to release it as source code and that's not gonna happen.

You never know, look at what Apple did to the PowerPC architecture.

It works on the x86 architecture, but that's about it.

Or Glidefx, or for that matter Savage3D/ViRGE and PhysX.

Things can get strange very quickly.

Especially for a simulation game like Armed Assault 2, you need to make sure it'll work for the long term aswell as the short term.

[Pulverizer 1]

Quote[/b] ]Especially for a simulation game like Armed Assault 2, you need to make sure it'll work for the long term aswell as the short term.

That's simply impossible though. Without a time machine or psychic powers.

Let's say there's going to be some extremely cool new combined gfx and physics middleware that makes everything we know obsolete. How do you program support for it, when it does not exist and you know nothing of it? It is not possible.

And PhysX is not dead. Especially now that new Nvidia cards have hardware support for it. Also, Glide can be emulated.

[Pyronick 21]

Quote[/b] ]Especially for a simulation game like Armed Assault 2, you need to make sure it'll work for the long term aswell as the short term.

That's simply impossible though. Without a time machine or psychic powers.

Let's say there's going to be some extremely cool new combined gfx and physics middleware that makes everything we know obsolete. How do you program support for it, when it does not exist and you know nothing of it? It is not possible.

And PhysX is not dead. Especially now that new Nvidia cards have hardware support for it. Also, Glide can be emulated.

You can't know when some kind of new middleware will be introduced.

However, if you have a modular platform/engine you can update on the fly. You can always add support for newer functions after the game has been released.

Valve does this with Half-Life 2, Tripwire Interactive does this with Red Orchestra: Ostfront 41-45.

In 2004, nobody knew what was possible with Shader Model 3.0, they knew of it's existence though.

If you have some sort of auto-patcher or digital distribution system with auto-patcher, you can modify the game the way you want to.

PhysX is a whole different cake, it's on life support by using the CUDA architecture.

But CUDA is obsolete as we now have new parallel computing GPGPU standards like DirectX 11 Computer shaders, OpenCL, etc.

Obviously there are no games using that technology yet.

But it is very likely that the Source engine will use compute shaders, aswell as CryENGINE 2.0 (Crysis, Crysis: Warhead, etc) via a patch or next-gen games.

The only thing nVidia can do is either wait with converting PhysX to computing shader standards, update it to newer standards or drop the whole project.

The NovodeX engine will survive, but I doubt that the PhysX API or CUDA will.

Especially with Intel's Larrabee and AMD's Stream processing.

[Pulverizer 1]

Quote[/b] ]However, if you have a modular platform/engine you can update on the fly. You can always add support for newer functions after the game has been released.

Something as complex as a modern game engine must be modular for manageability's sake alone. That's a default, not something that only Valve does. I really don't know what you're asking here, that every game company would support their games forever?

That's just not gonna happen, if you always updated your old game to the same engine capability as your new one, you'd be out of business with something as mod-based as ArmA.

Not to mention the raised testing costs. You'd have to check that each and every game you released would still work as intented with each little update to the engine.

[Pyronick 21]

Quote[/b] ]However, if you have a modular platform/engine you can update on the fly. You can always add support for newer functions after the game has been released.

Something as complex as a modern game engine must be modular for manageability's sake alone. That's a default, not something that only Valve does. I really don't know what you're asking here, that every game company would support their games forever?

That's just not gonna happen, if you always updated your old game to the same engine capability as your new one, you'd be out of business with something as mod-based as ArmA.

Not to mention the raised testing costs. You'd have to check that each and every game you released would still work as intented with each little update to the engine.

Yes, that's true.

However, the modding community would only have to make small changes every 3-4 years to keep up.

There is no interest in support old games forever, they could extend it's lifetime by doing small but significant updates.

Testing would be a problem though, you can have public beta tests but those aren't reliable enough as they aren't proper thorough tests.