My dreams about ArmA 2/3

[De_little_Bubi 1]

The year 2011 will drastically change the whole computer world, starting with x86 CPU's which will finally have the floating-point operation(due to vector extensions, MUL/MADD, fused multiply-accumulate, etc) grunt it should have.

Year 2008 - Luckily i upgraded my isdn (64kbit) to a highspeed DSL light (380kbit)

2 years left for hmm the dsl 1000kbit?

I want to thanks bis cause i can play arma on the internet (mostly without lag) :)

[Thrash 0]

It's the internet connections we have, most of us still have low bandwidth connections under 20 Mbps.

And even those who do have 20 Mbps connections, don't have enough upload bandwidth.

By 2011 most of us here should have fiberoptical internet connections.

Those that are stuck with DSL/cable connections will probably have better bandwidth aswell due to offloading the grid by adaptors of fiberoptical internet connections.

Thinking about it again, it could possibly be done with our current internet speeds. As someone else posted, you could sync (server/client) the velocity and direction of the projectile (bullet etc...) and let the client physics do the rest, having 1 core could be allocated to destruction physics maybe (assuming dual/quad core). The only problem would be cleint side objects interfering with the server sent objects could cause some upsets.

Or another option is to sync in realtime (server/client) any destruction that is onscreen (say within 500m), while everything that is off screen is simply positioned at its final resting place.

For example you're receiving 10kbps from the server, which is 10,000 bytes per sec, you could easily factor in 50+objects all using 10bytes each for velocity, weight, size, position, etc. You would only have to initially sync the size and weight once, and then only sync the position and velocity after that. It would take some nice fast code to sync everything efficiently, but it could be done i think using a combination of client and server physics.

[Pyronick 21]

Thinking about it again, it could possibly be done with our current internet speeds. As someone else posted, you could sync (server/client) the velocity and direction of the projectile (bullet etc...) and let the client physics do the rest, having 1 core could be allocated to destruction physics maybe (assuming dual/quad core). The only problem would be cleint side objects interfering with the server sent objects could cause some upsets.

Or another option is to sync in realtime (server/client) any destruction that is onscreen (say within 500m), while everything that is off screen is simply positioned at its final resting place.

For example you're receiving 10kbps from the server, which is 10,000 bytes per sec, you could easily factor in 50+objects all using 10bytes each for velocity, weight, size, position, etc. You would only have to initially sync the size and weight once, and then only sync the position and velocity after that. It would take some nice fast code to sync everything efficiently, but it could be done i think using a combination of client and server physics.

Yes, it's all possible.

But developers often soften requirements for internet connections by excluding a lot of features.

We're not far from the year 2010, most people that can afford a computer to play these games have a broadband connection.

With the exponentially increasing amount of fiberoptics users, we'll have plently of bandwidth (20-100 Mbit near symmetrical upload/download) in about 2 years.

I think BIS already done a great job by raising the bar to a minimum of dual-core and Shader Model 3.0 (according to the official system requirements) hardware.

Although they should have made unified shader architecture hardware the mandate imho.

[maddogx 13]

Although they should have made unified shader architecture hardware the mandate imho.

You wouldn't be saying that if you didn't have the hardware. ;)

Doing that is and will remain out of the question for at least another year or two, unless they want to shoot themselves in the foot.

[whisper 0]

I intentionally left out the time.

Go read up on DMM. It can handle an enormous amount of objects shattering, breaking, exploding, and still keep it real-time. DMM takes full advance of multi-core CPUs.

I'm not saying it'll be super duper, I'm just saying that it's possible. And it's possible without too many performance issues, and network problems.

Ofc devs of said solution will never say it might run into issues.

ArmA engine has already its own bottleneck sources because of its particularities compared to the 9 games you mention : like mentioned, none of these 9 depict such a large area as ArmA2 will, with so many units (with the new ArmA2 feature of micro-AI ALREADY taking advantage of the multicore achitecture) acting at the same time, potentially.

With extreme scale and numbers, BI MUST take the extreme case as their base of work. "Physic engine must handle X number of units around Y sqared km doing all Z actions", with X and Y way above normal numbers found in other games. And with multi-core CPU power already used by other apps (micro AI).

Definitely, it's not that simple. Seeing the BI answers, they already digged into that area quite a bit, and finally found it unfeasible.

And honestly, when I see the already average performance in ArmA, I won't blame them. If they say "no, can't do", then so be it.