DaveG

How do you think EAX worked? It's basically programmable audio hardware effects like reverb, delay and various filters. If a game implemented EAX the developers have to program these effects and effect parameters themselves to achieve the enviromental effects like occlusion (which would mostly use a filter) etc. Or they would use the canned effects included in the API. CPU's are god damned fast nowadays. All of this work can be done on CPU and take very little CPU time. In Ableton Live I can have tons of audio tracks running with multiple effects as well as soft synths running all at the same time and it barely touches the sides. So, with that in mind how do you think BF3 is implementing these effects? Simple, the same way as they would have done if they used EAX only they've implemented all the effects in software. That's right, they're using basic samples and adding enviromental effects through software, extactly the same way as EAX worked. And as for the consoles not being able to handle it? Well turns out they do it pretty easily. The sound system is almost the same as the PC version, maybe with less channels but the effects are all still there and of the same quality. I would wager that even the "general purpose" cpu in the ps3 is enough to handle the sound but I would not be surprised if it were implemented on one of the Cell's SPUs which would most likely be overkill in terms of processing power.

For a new build first thing I would do is check it with each stick of ram individually then try an old gpu. try and narrow it down.

yes Nod. they also change angle when you move the prop pitch lever!

this is what I was talking about in my post. http://www.youtube.com/watch?v=pGJEYJNweTA not the best video but the only one I could find. you'll notice it's not really a textured disc and the effect is totally governed by the rpm. Also you'll notice the blades become more visible when they catch the sun too. you can't see the in the video but the blades are not flat when viewed from the side either. it looks to be a proper simulation of a prop, at least how a camera would see a prop, but it's a darn site better than any other implementation I have seen.

voted new blur look on the assumption you meant something like the new props on IL-2 CLOD. Those look freakin' amazing!

Hahahahahaha! I'm going to give that a try!

@NodUnit. You're right about the engine desaturating the colours. I'm pretty sure this is part of the lighting calculations. The saturation seems to vary throughout the day with mid-day being the most saturated. Although it's still desaturating the textures at this time. You can see this when you press escape or when you you restart a level or something. the view appears very vivid for a few seconds. If you have ati you can adjust saturation through my digital flatpanels/display color. This is global though so will probably make everything else look garish. IMO the game does appear a little too desaturated even at mid-day, but you know what opinions are like!

if you're monitor is calibrated you shouldn't need to adjust the gamma. Of course, calibrating is not practical for most people so the gamma control can help. Gamma really adjusts the the brightness of the middle brigtness colours (50% grey for example). well it's really a curve that affects the whole brightness range. this can improve contrast making things seem brighter and more detailed but it should not really have an affect on the saturation (how colourful the colours are). It shouldn't affect frame rate at all. Unless the gamma works differently in this game than the rest of the world this should be pretty much true.

I'm no modder, nor even a frequent poster here, but I have been enjoying these games since OFP. Couldn't BIS release some kind of documentation for these special features? Then no reverse engineering would be needed to get your addons working as they should. Or does this exist already?

but the word shit is just fine?

A nice, big, well done campaign will do me. something on the scale of Coldwar Crisis or Resistance will do.

Not true. This is what OpenAL is for and it is used in many games including Arma, although I think I read somewhere that Arma2 does not use it. Regardless 5.1, or 7.1 for that matter, does not require hardware acceleration as it can be handled by the Windows sound system. Also, I hear that Windows 7 will come complete with Dolby Digital Live Plus so even those with "crappy" on board sound will be able to get surround out of their recievers through the spif.

^^ Indeed. Plus (nit-picking here) 3GB/s is the maximum transfer speed speed of the SATA interface. On average those drives can read at about 100MB/s (I have the 300GB version).

I have no idea if this will work for Arma2 but it got it working properly in GRID for me. try downloading the xbox 360 controller for windows software from here: http://www.microsoft.com/hardware/download/download.aspx?category=Gaming

Interesting find. Funnily enough I am a programmer (only 2d as far as games and such) and I had no idea that could happen. but that's the thing about programming, there's always stuff to learn.

Since the rendering and the actual game are done in the same thread (I think only micro ai is performed in a different thread from what I've read) surely it would be impossible for cpu and gpu to get out of sync? I've had this problem since OFP. Arma 1 had it too. I've had multiple machines during that period and it's happened on all of them so I'm quite sure it's not hardware.

It was there in OFP, it was there in Arma and it's here in Arma 2. And it's been moaned about since day one I'm sure. I remember Suma mentioned that Arma 1 used a triple buffering system to negate any frame rate issues caused by v-sync meaning we have to wait a full 3 frames before any input is registered. Just my humble opion but I reckon this is probably the cause since the lag varies considerably with frame rates. The fact that switching v-sync off helps reduce lag reinforces this. Switching to a double buffering system, like most other games, would surely solve this?

I also have this issue without any AA. It seems to happen at the edges of shadows for me anyway.

It might have somthing to do with the water shader which I beleive to be quite heavy. I run a 3870 which runs the game at near enough 30fps all the time but it really chugs as soon as the sea comes into view.

Has anyone else noticed the water shader seems to be incredibly slow? No matter what settings I use when water is in veiw the framerate chugs badly! it's particularly bad on the opening scene with the aircraft carrier. I've got the 505 release all patched up to 1.02. I've got an ATI 3870 which runs the game at a solid 25-30 fps most of the time which I'm quite pleased with but when a lot of water is in view it drops to about 10 fps! Here's my system if you need to know: E8500 HD3870 512MB 4GB Ram Vista 32 The game's great btw! It's a big step forward from Arma no doubt. A lot (but not all) of the old clunkyness is gone. The whole thing just feels a lot snappier. Good work BIS! Arrrgghhh! I just realised I posted this in the arma troubleshooting forum by mistake! Can a mod move this for me?

The game most definitely already does this. OFP did it, Arma did it, I'm sure this game does it too.

The might help if there are any z-fighting issues (flickering decals and textures) but it won't help with overdraw.

Seriously this is what the z-buffer is for! It's pretty much the most efficient way of dong this and is handled in hardware with little input from the programmer. Doing it the way you suggested would involve computing the distance from the camera to each and every polygon in the scene which needs at least one square root (=very slow) per polygon. Then of course all the polygons (probably 10's of thousands) to be sorted according to this depth and rendered accordingly. Trust me, BI know what they're doing!

It could well be. There probably be a lot of overdraw anyway due to all the foliage. And you were near the coast when doing the test so one direction may have had not a lot but sea behind it.

I doubt it's the hdr causing the slowdown since it's working all the time. It's most likely to do with the z buffer which all games use to make sure stuff that's behind other stuff doesn't get drawn in front of it. If there was no z buffer the objects would need to be sorted front to back, by distance from the camera each frame. this will be very slow! using a z buffer is much quicker but from different view points there will be different amounts of pixels that are overdrawn (rendered more than once) and thus you can have different frame rates looking at the same textured polygon depending on what stuffs behind it and what order the data is presented in.