karoshi

The devs have stated: Which is quite different from your statement. The devs state cpuCount does something. You say the devs said it didnt do anything. You seem to have reading comprehension problems. We can go over the sentences and compare what each of us understands, maybe im not understanding the bolded parts of both your statement and suma's statement. As I see it, the original statement by suma is misleading and states the contrary of what you say. Somebody might, sorry, lots of people have lost their time tinkering with -cpuCount. They might as well have been trying the optimum -bananas=X parameter. -cpuCount does nothing. It's misleading. If I change affinity, yes, it lowers performance as expected. Stop talking about affinity, this thread is NOT about affinity. Thanks for the tip. I know how to set a running program's affinity with the task manager, with procexp and to start a program with a predefined affinity using the vista/w7 start.exe. Now I know about another program to do it. This thread is NOT about affinity. Ah yes, that thread. Have you read it? The thread i was talking about in my original post, the first post in this thread, post #1 here. Have you read my 1st post in this thread? If you check my posts in the last 2 pages of that other older quad-core thread you are referencing you will see the test I've conducted now (procexp checking of number of threads created). In particular i explain my tests in the following post (ignore i7 talk): TESTING METHODOLOGY POST The other single post you reference in that thread was conducted under affinity settings: yes, the game uses more than 2 cores and no, -cpuCount does nothing. It's only affinity doing what it's supposed to do. This thread is NOT about affinity. For the 3rd time: I'm not interested in setting affinity to limit the number of CPU cores. I'm interested in what cpuCount does: it does nothing, nada, -bananas=42. This thread is NOT about affinity. Anybody can check my tests by:

You are still not understanding what I'm trying to say. Im not trying to simulate a 1/2/3 core system with my 4 core cpu. Im trying to see what arma2.exe does when I use the cpuCount parameter. I know what affinity does. Im not interested in that. With affinity I tell the OS scheduler to (not) use a set of cores for the process in question. Result: cpuCount seems to be ignored. Completely ignored. This contradicts public developer statements. You can use affinity to simulate a less-core system for any process. cpuCount (if it existed) would be arma2 specific and is what interests me. In particular i wanted to see what cpuCount=8/16 or even a higher absurd number does. It does nothing. Ever. Am i being clear? Stop saying to other people to tweak the cpuCount number (i7, whatevers). It's like saying: and start with the parameter -bananas=42 for better sound quality and improved stability. It's misleading, :yay: and a waste of time.

You miss the point of the original post. I´ve read the original thread and was trying some things out. It seems cpuCount has no effect at all. Check my posts in the quad-core thread you are referencing. I've got the game now and can try what i asked other people to try before i had the game in my hands. Checking the number of threads spawned with procexp (sysinternals.com) there are no differences with cpuCount 1 to cpuCount 4.

505, latest patch (1.02 2nd edition). Was doing some testing about the multicore cpu usage. Trying to see what the load is with different cpuCount arguments. It seemed cpuCount did nothing. Further on, if i search arma2.exe for cpucount (case insensitive) there are no matches, on the contrary, if i search for "nosplash" there is a match, and near that match is a lot of text that seem to be the command line options. None of them has got anything to do with "cpuCount". So, is cpuCount not yet implemented?

+1 Got my copy today from amazon UK, first 3 servers i went were hacked, including a nice message on screen about "hacked by ...". Great. Everybody was locked in the dancing animation, or suddenly 2km up in the air, or suddenly wounded and not able to walk. Can you imagine microsoft saying: "sorry, we dont care about security, it's the hackers resposability not to hack, not ours. Good luck using our products as internet servers." Get a punkbuster license, or whatever anti-cheat product WORKS.

What about writing a small .NET utility to read from the registry the install path of a1 & a2 and do the pbo dance automatically with kegetys tools? No permission from BI for that, I assume.

125% is supersampling' date=' by itself. There is no extra SS going on. Kinda like 125% squared, 1,5625xSSAA :rolleyes: For two reason: it's using MSAA, that has lower performance requirements compared to SSAA, and it's using the specialized hardware inside the GPU to accelerate MSAA rendering. Also, it's using RGAA, not OGAA. For the same AA level RG gives better quality compared to OG: 4xRGMSAA will look better than 4xOGMSAA. All modern GPU use only RGAA, no OGAA (maybe in some weird modes, like nvidia has for SLI), but not for the mainstream 2x,4x,8x MSAA modes you can select on the control panel. I understand what he says as: hardware based MSAA rendering will be supported. You can select to undersample or supersample (SS) that MSAA rendering. Examples: screen resolution 1280x1024' date=' fillrate 200% , MSAA 4x. You have quad SLI 295, you render the game at 2560x2048 with 4xMSAA, then display it at half that resolution because you run out of money and could only buy a 1280x1024 monitor. You are running a hybrid 4xSS+4xMS AA mode. [*'] what arma1 (and many other games do now), screen resolution 1600x1200, fill rate 100%, MSAA 8x. The game is rendered at 1600x1200 with GPU hardware accelerated 8xMSAA. Then it's displayed 1:1 on your screen. No SS (1xSSAA), 4xMSAA. what marek talks about: screen resolution 1920x1080, fillrate 75%, 2xMSAA. The game is rendered at 1440x810 with GPU-accelerated 2xMSAA. Then it's displayed at a higher resolution. You are running a mixed 2xMSAA + 0,5625xSSAA (well, USAA, lol). The point is: the text and UI is rendered 1:1 on your TFT, it doesnt look blurry. The added 2xMSAA doesnt look completely horrible when upscaling it, you only have to puke every 2 hours instead of every 15 minutes. Also it's much faster than equivalent 2xSSAA (square root of 2 fillrate: 141%), because it's MSAA vs. SSAA and because that AA is GPU accelerated.

I´m eagerly awaint patch 1.08. Any news on 1.08 release date?

It adds FS-SS-AA to everything' date=' not only the edges. 200% fillrate is [b']exactly [/b]4xOGSSAA but bypassing all the AA hardware in your GPU, and using a horrible OG pattern instead of the RG pattern used for all MSAA and SSAA by modern GPUs. Nvidia did only OGSSAA a few generations ago (FX5800 era, IIRC), but they've been implementing (and accelerating) RGSSAA and RGMSAA for a few generations already.

From what I've read around here it sets the size of the render target. If you set it to 50% it render 25% of you resolution pixels, if you set it to 200% it renders 400% of your resolution pixels. Examples: screen resolution 640x480, fill rate 200%, the game is rendered at 1280x960 then displayed at lowered resolution. This is called OGSSAA, it's one of the least efficients forms of AA, specially since it's an Ordered Grid (worst quality sampling pattern for AA) and it's bypassing ALL the hardware in your GPU specialized in making AA fast. screen resolution 1920x1080, fill rate 50%, the game is rendered at 960x540, then it's upscaled to higher resolution. It looks like crap, of course, no AA and horrible rendering resolution.

Depends, you can try with cpucount 8 and no affinity or cpucount 4 and affinity 1&2&3&4 or 1&3&5&7. I dont know how the virtual cores are assigned, maybe first real core is virtual cores 1&2 or 1&5 and last real core is virtual cores 7&8 or 4&8. The idea is that you only have a thread per real core. If you have 2 threads per real core you are kind of reducing your per core cache in half. You can tell us what works best on i7. I dont have arma2 yet and only a e21xx dual core, cant test myself. What im curious about is the load on the different threads Run procexp (as admin under vista/w7). Open menu view->"update speed"->10 seconds Run arma windowed, create a shortcut adding -window to the command line parameters. Let arma run in a smallish window 800x600 or even less. Start (editor?) a mission with 100+ AIs in a firefight, should tax your cpus. If you have a uber-system, copy-paste a few more hundred AIs until you see your frame rate go down. Switch to procexp while arma is running the heavy firefight. In the list of processes locate arma2.exe and double click on it A new window appears with information about the selected process (arma2.exe). The window has multiple tabs on the top, select the threads tab. The threads tab shows all the threads the process is running, you can sort by CPU usage by clicking on the top of CPU column (2nd column from the left). Bring the small arma window to the foreground, while keepin the threads tab in view. The foreground arma window should not overlap the procexp window with the CPU per thread usage data. This way the game runs in the foreground but you can still see the reported data in the other window. Report on how many threads there are. Each line in the threads tab is a single thread. Each thread has a "start", thats the address where the thread started running, i believe. In any case, let's name the thread by it's start address. Now report how much % of CPU each one is getting. Usually not all threads are running all the time. See which ones are running (using the "name" from the last point) and report what CPU% column for each thread reports. The cpu usage % usually is not constant, just try to give us an average for it. Now repeat with cpuCount set to 1, 2, 4 (and 8 for i7). Doint this test will tell us: how many threads is arma2.exe starting for each configuration selected (1,2,4,8). And how much are those threads doing. For example, if there is a thread calculating sounds, that thread should be doing around 5% or less. If you are in the menu, possibly only 2 threads are running, one doing sound and another drawing. If you start a heavy firefight with 1000 AIs, 8 threads should show CPU usage as arma2 lets each thread handle some AI each. DO NOT SET AFFINITY, please. Also, running fraps while testing could be usefull to get a quick and unscientific feel for performance. thank you

Can someone with a2 and a quad or i7 do the following test, please? Get procexp from sysinternals.com (it's microsoft, they bought sysinternals) Run procexp (as admin under vista/w7). Run arma windowed. Start (editor?) a mission with 100+ AIs in a firefight. Switch to procexp, double click on arma2.exe, select the threads tab, sort by CPU column. Bring the small arma window to the foreground, while keepin the threads tab in view. Now repeat with cpuCount set to 1, 2, 4 (and 8 for i7). Report on how many threads there are and how much % of CPU each one is getting. DO NOT SET AFFINITY, please. thank you :)