Der_Richter

Well so it seems, but as i said, if you reapply the same settings as you already have in-game, like select same preset and click apply again, ithe nvidia profiler frame limit works again... I also like to keep it limited at 30 to prevent fluctations in framerate despite running 45-75 fps without limiting. I absolutely can not stand non synced displays, they make me physically ill. Note that ingame vsync is always off in my case, so no interference. But if it is by design anyway, that the nvidia limiter is supposed to be disabled, then ingame should have the half refresh option as well...

Has been debated over and over again, and you ARE wrong. Simple as that. Precisely measuring on my end shows pretty even spread on all 4 cores (measuring by processes and per core), with threads spawning all over the cores nicely. The cpuCount parameter is however useless, but for the simple reason that the engine assigns the threads automatically. To return on topic, i am seeing slight changes in FPS as well, but not as major as described... Have anything else changed in your setup recently?

Exactly. But it works if i reset all ingame settings to the same values as before (just change to the same values) and apply video settings again. Then it works. So i have to do this every time i run ARMA3. Also, it is not only the VSYNC for me, it seems to ignore some of the profile AND ingame settings (AA etc.) completely sometimes, until i re-apply video settings, then it uses the set values (that are the same as before, just re-applied)...

Hello. No big issue, but i would just like to see if anyone else have this issue with 337.88 drivers for NVidia... I set adaptive vsync and prerendered frames, in my NVidia profile for ARMA3. This has alway worked before... Also, i set my settings ingame for AA etc. This usually gives me 60fps, when looking at "intro scene" in the main menu, i can see this due to always having FRAPS active to record. I recently reinstalled ARMA3 and the new NVidia driver, and now the same settings in the profiler and ingame gives me everything from 40 fps to 70 fps (thus not correct ingame settings sometimes and definitely no adaptive vsync) UNTIL i go to the video options and select the exact same options again and apply them. Then it's back to good framerates (correct settings) and/or adaptive vsync... There seems to be a bug that requires you to apply the settings EVERY launch of the game to make them active, both for ingame settings as well as profile settings. I can do this every launch, so not critical, but just a heads up to other NVidia users.

The most important setting for benchmarking is the view distances total and object... The fancy graphics are not that straining and pretty well optimized as it is... Try the same at a total view distance of 3800 with objects at 3200 or so and you will see what i mean :) What distances did you use when getting your numbers now? Oh, and since the new update i can see a good increase. 4ghz. Quad core and gtx680 4gb with ssd and high speed 8gb. Ram now yields playable 25 to 50 fps in most situations. So for more fps you need say... 4,5 ghz. Cores. :) ---------- Post added at 06:59 ---------- Previous post was at 06:53 ---------- By the way, small edit, has anyone seen yet what the default view distances are online when set by the server?

Ok. Further measurements that i have done over a longer time has now led me to the conclusion that GPU is not under large pressure, regardless of settings. However, what really kills the framerate is object count. High detailed objects choke the FPS like mad. But contrary to what you may think it does not choke the GPU at all, it brings the CPU down. The more objects that happen to be in your viewpath (accounting also VD setting), the worse the CPU load at least on one core. The same behaviour can be found for A2 as well... A small question to a dev, if possible... Is there reason to believe this is due to preprocessing of frames loading all geometry on the CPU? Lower your Object Detail and you should never drop below 60 fps, at least i don't...

I could use some ACE reference myself actually. Thanks! About the whole ignorant players thing, i agree. What really grinds my gears however is comments like "too bad DayZ wasnt made with a real game engine, arma engine is crap cause i cant have 60fps with my b34st master rig. It runs battlefield on ultra yo! " Of course there lies a failure to understand that the rv engine is probably the only one capable of doing what DayZ does... But despite my irritations sometimes i actually like having some patience and every once in a while you find a new player drawn in by the franchise and thats where we need helpfulness and good guides. I think you have to 'learn' to appreciate what arma is... And on your own, that can be daunting.

Interesting intel there... And yes i would agree with the points raised, although it is not really the problem. Threads is one thing, but when we can see 40% TOTAL cpu usage while the simulation as well as rendering thread grinds to a halt something is locking it. Its not the cpu being bogged down as much as it seems to be routines taking a long time to complete. As for resource sharing, my work in the past in similiar fields was constructed so that we put a render thread that was constantly fed by calculation engines on multiple threads. This however was possible when locking the update tick of the calc threads to a peedetermined rate. This would imply locking the framerate as well, to keep the render thread sync to calcs. This way the grunt work was theeaded but fed the gpu pipeline at the same sync, and the pipe counted on not being fed data out of sync. I was working on predetermined hardware with smaller subset of simulation however so i can understand the woes of bis on this one... But as stated, i think the 40% total cpu time usage is more worrying, than how it spreads on the cores and spawns threads as that would indicate some single thread routines taking their fair time to process. Or in fact, a deadlock, where it is threaded, but the threads wait for eachother far too long. My opinion without knowing jack about this particular engines internals is that it is related to movement of objects and specifically AI.

Could you motivate why we should avoid helping new people who might stay in our beloved armaverse? Really? Aren't you a tough soldier!

I have a TeamSpeak up if anyone wants to get in and talk some basics, and have a go at some proper COOP without any pressure or such. Will probable be COOP 4 or 8 depending on joiners. I have an old mate joining me as well, who is also quite new to ArmA. If anyone feels like jumping in and having fun and trying out to squad lead without pressure, get in TeamSpeak at: 37.2.153.200

If i would dare a guess i would say large chunks of "something" being stored in memory as a single bitmap and transfered as one chunk, probably object data for the GPU, this will stall the buffer like this. But since my knowledge of the RV3 engine is as good as anyone elses not working for BIS i'd just take it as a general area of investigation. I don't think rendering is defered to it's own core, it must be sharing with something...

Ok. I have tested and TeamSpeak server seems to work fine. I have tried to host with 4 players and it seems to work ok. Should be ok with more players as well. I will run a maission from time to time to get this rolling. The idea is to let the new players take roles that need practice while being backed and helped by veterans, in a laid back atmosphere, i.e. noone is to blame if something fails, we restart mission midpoint if needed, we can experiment as much as we want. No problems. I will sign in as veteran at this first event, and hopefully tremanarch, as he so willingly volunteered :) I was looking at running this: http://www.armaholic.com/page.php?id=19294 for training of fireteam command and navigation. If interested in joining, let me know, and i will set a time for server go... Remember, i live in the cold arctic hell hole known as Sweden, so times will be GMT + 1 //Richard

I actually think chat would be preferable due to easier understanding and clarity, and also due to not all players having mic. Teamspek for announcements/chat would be active however.

I get the exact same behaviour. I think there is a problematic object somewhere in that general direction... In my case rotating the view as little as 3-5 degrees bumps framerate up again...

Alright... I was thinking of trying to host a first session myself this weekend with some coop squad play. My plan was to let new players take turns in leading and commanding the squad and i will just be along as a regular gi joe for the ride. This way i can also answer questions on commanding and tactics as we go along. Commanding a fire team is something that is crucial also in single player, in arma... If interested pm or shout here and i will see if i can get a private teamspeak going. Any veterans wanting to help out, are also very welcome. Bear in mind that my machine while powerful, may not be able to accomodate anything over, say coop-15