Purg

Helios is a windows based application, Android can't run windows apps.

If it's running Android - I wouldn't think so.

95% of the games I've pre-purchased in the past have been sp that I can play it on release day. This isn't a demo, it's access to a work in progress beta and the final release when it's available. My curiosity got the better of me and I bought the product 23 seconds after I was aware it was made available as a beta (bought the Russian release of BS the day I flew into Singapore for 2 months and then the English version ontop of that - I'm a sucker for anything ED releases). I'm completely speculating but this sort of move is usually to supplement the budget to ease the pressure and continue development though I have absolutely no knowledge as to this teams motives for the release. Even in its current state, it's money very well spent. I'd have been completely satisfied if this was the final release. I know ED wouldn't given their track record on their strive for excellence.. their products have caused me the *least* amount of hassles and frigging to get a stable hi-fidelity and enjoyable sim.

I use my G25 pedals with no issues. If you set the brake and accelerator as combined axis, DCS picks it right up as a device you can map functions to. It's not ideal but fully functional straight out of the box. No need for PPJoy.

I've seen widescreen 21" HP touchscreens for ~$350. Not sure about its performance but 3 of those together would make for a nifty cockpit. :D

3D graphics has improved but is still reasonably limited in a virtual environment. If you did get it to run, I'd expect it to be a slideshow.

Meh. Still a bargain at double the price. It's unfortunate that the project ran over budget but it's likely done so at the dedication of putting out a product worthy of my money. Not even deterred a smidge at buying it.

I'm surprised it's at all necessary to use PPJoy. I have the same setup under Vista. Set the G25 to combined axis on the pedals within its control panel and setup the individual axis for each control input within BS. Simple. No additional software needed.

In order to determine whether it achieved its goal (getting an FPS increase) would be to monitor FPS not CPU load. I understand your skepticism as I also can't work out why this trick works... but it does under Vista. Keep it simple. Load BS. Start a mission. Bring up FPS counter. Pause mission. Modify the affinity (I use SetAffinityII) Ignore the CPU load. Doesn't matter what runs where if performance increases. Go back into BS. Note increase in FPS just on the paused screen. When I do that I'll see an increase of 15-20fps the moment I go back into BS every single time. If I alt-tab back out and change it back to core 0, performance drops back down. It's very repeatable and very noticeable.

Have you got it in a 2.0 port right on the motherboard? I only had problems when I had it plugged into a high speed hub (which they actually warn you against doing on Naturalpoint)

Certainly a much more balanced review than the other guy who only had time to play in arcade mode.

It's no different to setting the affinity of the cores yourself or any number of methods that others use in an attempt to spread the threads over multiple cores found on here. I would also doubt that it would give you any performance boost under XP.

!? The memory footprint is the memory footprint, it's using the amount of memory it needs in order to complete the tasks it's being asked to complete. You can't force an application to consume more memory, it would be absolutely pointless.

I can see people taking to alcohol trying to follow the OP's directions...? Running Vista with a decent amount of memory on a multicore CPU, shutting down all those tiny apps that use a squeak of processor time once in awhile is going to do sod all. Perhaps in XP it might give you an extra frame or two here or there but seems like a whole lot of effort to achieve it. For instance, I happily run BS with 3 virtual operating systems running in the background at the same time. An XP box, A 2003 box and a SUSE box. If I shut each of them down as well as all the other processes that I run in the background I see no change in FPS whatsoever. Right now, as I type this post, 99% of the time, all 4 of my cores are showing 0% utilisation with ocassional spikes to 1 or 2%. If your machine is stretched for resources then by all means, start shutting things down. However, compared to all the other sims I own, BS doesn't have much of a memory footprint and under Vista, doesn't max out any of my cores. I'd suggest the majority of people who have a decent spec PC under 2 years old would gain very little benefit for BS doing this. The rest, just do it manually to see if it makes any sort of difference before trying to automate your impending system meltdown.

Fallout3 isn't a simulation. Sure the Xbox can churn out polygons at an alarming rate but DCS is processor bound, not graphics bound. Fallout3 didn't come anywhere near to maxxing out my CPU but DCS does. If I compare titles I have on both PC and Xbox, the resolution of my PC is pumping out more than double the pixels, the draw distance is greater and the textures are much larger and crisper than that of the 360. COD4 on my PC runs in excess of 400fps most of the time and looks a whole lot better than my 360 version which only runs at 60fps.

Lucky he has Vista 64 then. ;) I think 32 will only report 3.5GB or I could be thinking of 32bit 2003 without the switch to recognise more..

I tend to just set affinity to be spread across all 4 cores on my processor as well. I figure the OS is better at distributing load across the processors than I am so may as well allow it access to distribute it where it sees fit. Bear in mind that it's also not only DCS running but OS threads and other things running in the background. If you've not set DCS to run across all cores and the OS for whatever reason decided to run a CPU heavy thread on one of the cores you selected to run DCS from then you'll potentially have a frame rate hit during that execution.

Trial and error is really the only reasonable response to point 1. Point 2, from what I've read from semi-reliable responses is that the beta version of Windows 7 will be available to the public within weeks. However, if you know how to torrent then there are several beta versions floating around that are easy to find.

Only way I've been able to take them down is to chase them and cannon them with boresight mode. If I try the HMS then the darn thing moves too fast for me to lock in the shkval. Seeing as the KA-50 isn't a A-A platform though, I hope there's someone else around that can take care of them.

Just as I keep telling you, your performance is CPU bound, not video bound. Your card obviously can render the scenes with anti-aliasing at 16x which tells me that your video card clearly has more than enough horsepower to handle what DCS is asking of it plus some left over. I see this on every single sim that I own. If the CPU was largely responsible for your video output you would be lucky to get 1 FPS. Run some of the Futuremark benchmarks and compare the results when a scene is rendered by your graphics card as opposed to when it's rendered by the CPU. Also take note of the quality of each scene, not only is it a fraction of the speed, it looks horrible in comparison.

Of course it's also video dependant if you're asking your video card to render a scene that's more than it's capable of - antialiasing is done solely on the video card and is independant of DCS so the DCS engine doesn't handle the anti-aliasing. I'm just talking in terms of plain DCS.

Beyond my expertise. You'd have to know a whole lot more of how the sim is coded, how Vista gets a boost where XP doesn't and the raw data of the utilisation of the sim on your PC to even come close to answering what's going on. When I first start a mission (and I chose Battle single mission as an example) DCS is running on a single core at 100% utilisation while the sim is paused. If I then tab out and change the affinity to all 4 of my cores, I get an instant ~15fps boost. Therefore it's obvious that the engine isn't being GPU limited but CPU limited. Throw a faster processor, change nothing else and the FPS will rise even more. Now, how Vista is handling those threads within DCS is a mystery to me (there were 22 threads running under DCS.exe when I checked during battle and have seen as little at 18 ) Theoretically, each thread can run on any 4 of my cores. I can't explain why the kludge works for Vista and not XP though. I'm a hardware guy, predominantly server and storage and only dabble in OS and software on the side. Most of the time core 3 on my box gets the most workout when I spread the affinity across all 4 cores and will peg upwards of 90%. Now, whatever thread(s) are on that core are again bound by the limit of the CPU and regardless of whether the other cores are relatively idle, you've again hit a bottleneck. A thread can be as simple as an I/O request from the sim to disk or the whole guts of the sim, depends largely on the code. If you were to look at CPU utilisation as a whole, it wouldn't show a maxxed CPU but if you split it by cores, at least 1 core may be running near max - hence, your ceiling performance wise has been reached even though you have 3 cores worth of CPU cycles relatively idle. Then there's the engine itself, the inner workings that I'm not privvy too. Take FSX as an example, you can limit the FPS so that the engine can devote more CPU cycles to other things (like drawing distance, buildings, AI aircraft, etc). Perhaps DCS is limiting CPU dedicated to FPS in this way so that it has left over CPU cycles for the flight model for instance.

Considering the disclaimer on the campaigns, is there still a marked difference between XP and Vista on a heavy mission or could we assume that the devs and testers prior to release time didn't utilise the multicore kludge?

Because the bottleneck is the CPU not the GPU. We're not at the point where it's complete bus mastering and that anything and everything to do with graphics is done solely on the GPU, it's not. While the image is being rendered on the GPU, it can only render what the CPU is telling it to. Therefore, if the CPU is maxxed out, there's a limit to what it can tell the GPU to do. Making it prettier still burns CPU cycles.