Pyronick

Sprocket = fail nehwayzI'm still hoping for a service like Steam. Or preferably Steam itself.

*hint* BIS should annexate eSim Games *hint*

Actually, it's specifically designed for games. In fact the new Core i5 (Celeron replacement) will have an integrated graphics processor on the CPU-die next to the integrated memory controller.The later Haswell architecture will have the addition of an FMA instruction set, this is often used in graphics processors because it can double the raw floating point operations. It might also have scatter and gather instructions, which is also a typical GPU feature. And raw FLOPS make a fast graphics processor. Yes it is. :D

Yes, there is a huge shift in CPU technology.The new Sandy Bridge architecture (which might use that next generation chipset) has a new instruction set for handling very wide vectors. Which finally solves the floating-point disadvantage of the x86 architecture, but it will still only be a tad faster than the Cell Broadband engine flops-wise. But for your virtualization needs the new Westmere cores are interesting aswell, they have much lower virtualization latencies and a second generation integrated memory controller. The Westmeres with the LGA 1366 socket also work on the current X58 (Core i7) boards if I'm not mistaken. Yes, that always is the wisest decision IMHO.

If I were you and I did that upgrade specifically for ArmA II, I'd postpone that upgrade until after the release of the game.By then the HD 4890 would have been cheaper and the Core i7 aswell. But I think you'll run the game just fine if the developers are right.

Yeah, but it doesn't fix the issues with collision detection though.This one looks pretty funny aswell :D Except for maybe the sounds, and of course the bouncy physics. But since it's not a race simulator, I think the oversteering at 0:35 looks pretty cool. I'm really interesting in the vehicle dynamics in OFP:DR since it's built on a racing game engine. (no I don't consider DIRT/GRID a simulator)

I think that also was due to the low refresh rates.If an M1A1 tank is on collision course with a BMP tank, it often skip the actual first collision frame. The very first detected collision in this case happens when the M1A1 is half way through the BMP. So the physics engine now detects multiple collisions on different faces (because the M1A1 is technically embedded in the BMP now) simultaneously creating a situation which isn't possible with n-body solving. But since it can happen theoretically in simple Newtonian mechanics you build up an impossible force. This can launch the BMP (and M1A1 in the worst case) with an impossible speed at an impossible trajectory. And afaik, tanks aren't damaged by colliding with terrain even at high speeds. So they land unscathed. I think the following needs to change in order to fix this: restrict collisions by the same object on multiple directions simultaneously through an a posteriori set. Increase refresh rate of the physics engine. Develop an a priori prediction system with an n-body solving algorithm. And possibly the most important: Make very detailed shapes of the various collidable objects. If this is done properly, BIS will be the masters of realtime computed collision detection.

What ArmA2 really needs (if they still use the old collision detection) is increasing the refresh rates by at least a two fold, as I mentioned here. The game should make more use of inverse kinematics, that combined with detailed motion captured animations should give very lifelike animations that work in most situations. And hopefully hybrid ragdolls based on inverse kinematics or motion captured death animations constrained by ragdoll physics to make sure the in-game character dies on the same spot for all multiplayer clients but yet looks realistic. As the game gets patched and hardware speeds increase, the refresh rates could be increased in the future for even more precision.

I think it's just a matter of increasing refresh rates of the collision detection, better edge detection and optimized coding.With the multithreaded processors today that shouldn't be a problem.

Well, it depends on the storage medium you are using.I haven't seen any SATA disks which can anywhere near the iops or (random) burst transfer of SAS disks, this is not due to the speed of the harddisk but rather about the interface. If you use an entry class 10k RPM, 8 Mb low-level cache SAS disk. It won't be (noticeably) faster than similar SATA disks even though the seek times are much lower of SCSI hardware. However, the burst transfer (and most of the times sustained transfer aswell) are much higher on SCSI hardware. Even my old Ultra 160 disks outperform most SATA/300 10k disks, except for sustained transfer which is the only advantage of SATA/300 other than parallel connections. They even kick Intel SSD's ass on various points. I can't say anything about motherboard controllers as I usually use Adaptec or LSI Logic controllers, but I don't think it will be any worse than SATA of which the command sets are completely CPU dependant. RAID configurations (esp. striping) are only interesting for large data transfers and all I want are low seek times and fast random transfers.

When PhysX was announced back in 2005 I was really impressed by it.But looking back now, I never understood why they haven't made it more scalable for future hardware. After the annexation by nVidia, I didn't really care about PhysX anymore as it simply became even more of a marketing tool than it already was. But with the newer enhanced Havok engine, I think that hardware accelerated physics will start finally break through. Hopefully we'll have OpenCL-based audio processing soon aswell, as EAX-capable hardware is dying out.

HOLY SH*T! :eek:Octo-core and 4xQPI... That means the possibility of a quadruple Beckton system with 32 logical processors (cores)! The Jasper Forest tech looks promising aswell, with integrated PCI Express connections (on-die controller?). Maybe they could do something similar for discrete graphics hardware to directly connect to the CPU instead of going through an I/O hub. This could multiply bandwidth and decrease latencies by a tenfold! Anyway, I reckon my stock Q9650 should be more than enough for Armed Assault 2. But I'm still considering to upgrade to i7 tech, since those X58 boards also have SAS controllers. Atm. I'm using Ultra320 SCSI instead of SATA, which is faster and offload the processor/Northbridge, but SAS disks and SSDs are becoming more and more affordable these days and it already kills SATA/300 at the same speed not to mention the better efficiency you get with striping.

Like the name says, shadows are arranged in series (cascades) which means the shadows can stack up on each other.

Don't forget cascaded shadow mapping, if things are going according to plan! :D

Haha, what about the new dual Nehalem-based Intel Xeon W5580? :D2 physical CPUs, with each 4 cores, each handling 2 simultaneous threads and some serious overclocking potential due to the D0 stepping.

Woohoo!! The new forums look great! It just lacks a fitting favicon and meta tags. It still identifies as a vBulletin board and not as a Bohemia Interactive vBulletin board... ;)

Yes, I heard that aswell. But wasn't that with like huge resolutions and 8 GB+ RAM?

So ArmA2 is able to address that memory? I think it could if it was a 64bit app, but since its not i dont think it will, however im not a programmer so i dont know. As I pointed out above, memory management is Operating System controlled. At any rate, I'd be kinda worried if ArmA II was consuming more than 4GB of RAM... Well, it would be nice to have extremely high resolution textures though. It would be a waste to have more than 4 GB RAM memory if it isn't used.

So ArmA2 is able to address that memory?

Hopefully they're just doing a sneaky upgrade to a faster Gainestown-based Xeon server.

Still no success?

PhysX only works with Ageia (end-of-life product since a while) and capable nVidia hardware, while means less than half of all gamers. Intel (Havok) and AMD are working on making their new Havok engine through an open standard which works on all capable OpenCL hardware. That means multicore processors, (GP)GPU's, other types of stream processors, etc. PCI Express is serial point-to-point unlike PCI/PCI-X and has no real limits. If you mean the bandwidth of the 1x PCI Express bus, don't worry. It is more than enough for physics accelerating hardware. Somewhere in the future, AI might not be fixed load anymore but scalable. Perhaps through very coarse multithreading, but it seems to me that AI could be very scalable through the amount of bots (or directors) in a game.

Whoops, you are right. It's GeForce PhysX that won't work on some titles. Excuse me. Intel and ATM are working on a proprietary solution, but one that works on all hardware. nVidia has a proprietary solution that only works on their own hardware. That's a humongous difference. Your X-Fi does have hardware acceleration in Vista, but only on OpenAL games or EAX (DirectSound3D) through ALchemy. XAudio2 doesn't have hardware acceleration, and that's what most new games (due to the huge PC-X360 multiplatform crisis) will have instead of EAX or OpenAL.

It's just proper interaction between AI and the physics engine. And it should be very possible on newer multicore processors (especially the Phenom and Core i7 due to core-to-core interconnects) and hardware accelerated physics.

If Armed Assault 2 has a proper balance of fine-grained multithreading for simple tasks and coarse multithreading for AI (Valve calls this Hybrid-threading) it should scale perfectly on all sorts of multicore/multithreaded processors. It won't take long before we'll have octocores with 16 simultaneous threads, so I'm sure they'll make it as scalable as possible.