I still don't understand why it can't be a multi-step process? Like, equip and then throw? I mean, the discussion about "ooh does it take 2s or 5s to throw a grenade" is a bit silly (as it'll probably vary from person to person), when the obvious solution (that works for all throw-able items) is to equip the item and then throw it using the LMB.

See my second last post (before this one) for an example video.

That way, you:

1. Throw the grenade just as fast as YOU can, after the initial second or two to equip it

2. Aim properly at where you want it thrown

3. Can't spam because it takes time to perform a multi-step action

4. Throw all items, be it smoke, frags, lights, etc. in a similar way

5. Can engineer air bursts and other things via modifier keys/buttons like the RMB (to cook the grenade, or maybe CTRL+RMB to switch to underhand throw)

6. Can move while the grenade is equipped or being held in a "ready to throw" position.

I can't think of anything else, but i think 6 advantages isn't a small number by itself.

@Sneaky: There's a "marine" above who says it takes 5-10s to get a grenade down range. Who am i supposed to believe? Half the fucking community claims military combat experience.

@SentientCube: my thoughts exactly.

Alright, done:
http://youtu.be/iw-qypnI2cY

Frags have a 5s fuse, flashbangs have a 2s fuse.

True, the CoD way doesn't suit Arma 3, which is why I'm advocating an America's Army style model, which doesn't make it "press button -> instant throw" but at the same time you have precise control over when and where the grenade falls. Plus you can cook it, so air explosions and all.

EDIT: Will upload a video of the AA method shortly.

@Tovarisc: That'll be problematic (the delay), as if you'll sort of lose control over when the grenade is actually thrown.

Going to post this here, since the thread where i had posted this has been closed as a duplicate to this one. Some people liked my ideas as well, so maybe more could review it here.

"G equips a grenade, holding the left mouse button readies (but doesn't cook), tapping right click while ready cooks it.

This is exactly like america's army 2, if anyone's played that."

So yeah. That's what i'd suggest...

It appeared to me that it's reporting conflicts b/w infantry and vehicle controls, which shouldn't be the case unless those controls were common.

ALTIS IS MORE OR LESS FIXED (for me)!

That issue i described in point 4 in my previous post? All gone. Solid 35-50 fps while flying over Altis, i can even turn objects up to high now. Towns still cause an issue, though, but it's less.

Particles still incur a massive performance hit, but it's only noticeable when you're not CPU bound, so most of the time it doesn't matter.

Exception is when firing lots of missiles together, FPS still falls on its face.

Strangely Stratis feels slower than Altis, now.

A friend of mine running a 3570K and GTX 670 reports steady 40 fps at 1080p, though he's not an Alpha/Beta tester so i dunno whether he's actually checking known problem areas.

My specs:
Core 2 Quad Q8400 @2.77
GTX 560 (1GB) @ stock clocks
8GB DDR3-1396

Haven't logged performance yet, too lazy. :P

1. @rogerx: You hadn't heard of Steam till last year? Lol. You're 9-10 years behind on some things, mate (including XP). ;)

2. integ3r: Been suggesting changing how threading's been implemented for a while now, pretty much second what you've said. What's frustrating is that right now is that object distance is currently related to both object draw distance AND object quality, and turning object quality to Ultra STILL SHOWS GRASS POPPING two feet in front of me.

3. Linkin: Yeah, varies depending on settings, but never burst 1GB on Stratis. See point 4 as well.

4. I'm getting a lot of issues flying over Altis in general, especially over the airport, solar farm and other eastern parts. FPS drops to below 15, the game starts scaling back textures/terrain (that only somewhat pushes FPS higher, not much) and it pretty much sucks. FPS takes a huge hit on the western side when i look around while flying.

I think there could be a VRAM bottleneck here, haven't actually checked.

5. Just finished first post-release patch, will test it and get back here.

Rogerx: We were talking about majorities, and from all those charts all i can see is that Windows 7 is above 45%, while 33% belongs to XP. Add that 45% to Vista and Win 8, and you see what i mean (a significant portion of Windows NT 6 based systems are 64-bit). And those numbers include a fair amount of institutions that don't change software for years, unlikely target customers for Arma 3 :P

So i think the most relevant numbers (to this game and discussion) are here:
http://store.steampowered.com/hwsurvey

specifically, here (scroll to the bottom):
http://store.steampowered.com/hwsurvey/directx/

So yeah, among steam users, less than 25% have a 32-bit windows OS, and 7% have XP.

Also, i'd disagree with the last paragraph, XP was based on the NT5 kernel, Vista through 8 are on the NT6 kernel...so not really just piled on. And XP's kernel succeeded Windows NT 4 ;)

@Cheesewilly: I don't see merit in that argument, people who'd implement female characters or melee wouldn't be involved in engine optimization for the most part (only getting involved when their work would meet the engine).

Also consider that:

1. This is the most voted on and upvoted topic.
2. We neither have female characters nor do we have melee.

@rogerx: Windows XP 32 bit is statistically (on steam and the general PC market) a minority now, especially on steam.

On topic: I'm getting a huge performance hit around the solar farm when flying over that area. I'm talking sub 15 fps, western Altis gives me 30 fps approx. Probably worth another ticket.

@iEnemY: Not really, Arma 3 is 32-bit with LAA enabled, meaning that on a 64-bit system the max physical memory it can allocate is 4GB. You're probably looking at virtual memory.

@swiftchocobo: Scroll up a bit, it's been discussed extensively; increasing view distance increases pressure on the CPU, and the CPU utilization stays more or less static due to their coding methods.

GPU utilization drops because it isn't getting stuff fast enough from the CPU to render and draw, opposite happens when you decrease view distance.

If you plot FPS vs GPU utilization, you'll find that the FPS trend matches the GPU utilization.

This must be the most undervoted tickets here. We need an official in-game/in-engine benchmark script!

http://feedback.arma3.com/view.php?id=7599

@sion: zoom into the editor map and watch your fps cross 200.

I dunno whether XP is the majority anymore, if you look at the Steam Hardware Survey, XP market share is less than 10%, while 50%+ for Windows 7 64 bit.

Yeah 32-bit users were/are having issues with Altis. Memory limitation, Tiger Walton was the user (i hope i got their name right) that found that. He said that they had increased the virtual memory limitations and so the issue had been fixed...but see link for more info:

http://feedback.arma3.com/view.php?id=13345

No clue how to graph bus usage...i did profile storage read/writes, nothing particularly demanding, will re-run with 0.76 again. I'm running this game from an SSD.

Yup, that's correct, one core's at about 85% avg through the run, others between 50 to 60%

Usually the others show an average of 45-50%, but this was an experiment, so i'm putting a higher load than i'd usually play with (2200m view/object distance, objects set to standard).

I'm using the stable branch...

p.s. It's interesting that on higher settings, the core that seems to be responsible for rendering (core1, in red) drops in utilization...bottlenecking the GPU and drastically reducing FPS. I'd expect utilization to increase in response to more load, not fall.

nologs does reduce stuttering, but it doesn't do anything for performance hits caused by objects loading or particles :'(

I'm using an Intel Core 2 Quad Q8400 and a GTX 560...

I too, have seen my GPU hit >80% utilization, but that's only when i'm looking at the sea or the sky...and that's the only time my frame rates cross 60 fps.

My FPS also crosses 60 in the map editor :P

Have a look at the last three files attached to this ticket, i've uploaded those.

There's also this stuff:
https://dl.dropboxusercontent.com/u/45160510/arma3_obj_viewD_GPU.jpg
https://dl.dropboxusercontent.com/u/45160510/arma3_obj_viewD_CPU.jpg

This is a graphical representation of what integ3r's pointed out.

I had done this quite some time ago, so i'm not exactly sure what i did to the object settings, but i believe what i did initiailly was this:

1. Placed myself inside the perimeter of the outpost near Stratis airbase.
2. Looked out to see
3. Set the view distance to 500m, i'm not sure what the objects settings were, i might have set objects to ultra and left the object draw distance to whatever the game set automatically for that particular view distance.
4. Ran to two more points, one overlooking Agia Marina and the hills behind it, the other overlooking the airport. I believe i zoomed in at each point, including the starting point.
5. Then i came back to the sea facing view and increased the view distance by 500m.
6. Repeated all steps till the max view distance.

In the next phase i think i set the object and view distance to a particular limit, I don't remember whether it was 2200m or the max possible. Then i think i repeated the three-point run with the objects set from low to ultra.

You can see what the graphs look like.

So yeah, i think integ3r's explanation checks out.

Here's what happens when i fire a large number of rockets from a Mi-48 at Agia Marina:
https://dl.dropboxusercontent.com/u/45160510/arma3_particles_GPU.jpg

This graph shows the game launch, editor launch, mission launch, and shutting down the game. Marked area indicates rockets being fired.

All of this logged with HWiNFO64.

I'm not saying that they're all the same issue, or all relevant to performance, i'm just saying that there are multiple issues with the engine, and from what i've gathered, a lot of these problems have been present in previous Arma games. Which disappoints me. Don't get me wrong, it's a great game, just

1. Um, 1998 was when we had pentium IIs. And you know, i think there are far too many games that use particle effects without incurring a performance hit. A lot of it can be shifted to the GPU as well.

No it's not, i'm dive bombing the town, so i'm flying over the explosions...note that smoke itself doesn't cause issues (i believe they're not using particle effects for smoke, just dust, water spray and explosions). 2200m objects and terrain. And this is less than 500m anyway. But i actually think it's...ok, see, what happens is, if you fire a few rockets, it slows down a bit. Fire a lot of them in a large burst, and framerates drop like stones in water.

The town ALWAYS causes a performance hit. Its like the engine has to render more objects but...*sigh* they're doing something wrong with threading. The GPU can't render stuff because it's being held back. I'd say my processor is too slow or whatever if it would be at >80% utilisation, but currently only one thread is. Rest hang around 50 +/- 10%.

2. It hasn't been fixed, at least not on the main branch, as of 0.76. Everything keeps popping in and out. It's distracting. A lot of games have the issue but it's extremely subtle. In fact, go look at their most recent "live stream" (uploaded on youtube). You can see stuff popping in there as well. On THEIR developer machines. It's very distracting.

If object distance = view distance then the objects should only pop/fade in at that line. I see stuff popping less than 100m in front of me. Again, neither the GPU or system memory has hit its limits.

There exists a ticket for this issue.

Terrain warping too. There is a ticket, but i doubt it'll be fixed. I've reported on the vanishing bullet trails.

I think you're misunderstanding me on the water layer thing. You can see the sea floor from just below the surface as if there wasn't any water.

Also documented (6 months ago) but hasn't been fixed:
http://feedback.arma3.com/view.php?id=678

3. It's absolutely relevant. A lot of these issues appear to have plagued previous ArmA games. Otherwise too, i've not seen these issues (water, terrain warp, this severe object popping, major particle performance hit) in any other game. Maybe Mafia II, but that's with hardware accelerated PhysX turned on.

Another thing: building destruction. They just fall through the floor. You can see them doing that.

The only games where i've seen CPU-bound performance issues are console ports.

Heck, even NFS Shift does better picture-in-picture and surface reflections (we don't even have them in ArmA 3).

Programming the right way is much more slow, but it's absolutely required, especially of a PC-based studio. And in the long run, it benefits the studio making the game, as they have a solid base to iterate upon further.

I respect BIS for what they're trying to do, but they must do it well, it's their job, we are paying customers, and while i can't (and don't) expect the world from them, this is a pretty basic expectation for a game. I *hope* they fix this going forward.

But on topic, i honestly believe that if you're making a PC game, and your game is under-performing and simultaneously under-utilizing resources, you're probably (definitely?) doing something wrong.

I'm sort of sad to say that even of 0.76 Beta, not a single issue has been fixed. -nologs may have improved stutter a tiny bit, but the performance hit while particles are rendered, objects are loaded, buildings are destroyed, etc. is really huge. I've gone from 40 fps to 12 fps simply by firing a lot of rockets at the large town (i can't spell it without googling it) from the Mi-48.

Plus the objects popping into existence for a view distance < set object distance (i've set max view distance=object render distance, so this shouldn't happen) and the ugly terrain warping has been really disappointing. Plus the water layer disappearing at a particular angle, and lack of bullet trails in water after a random distance at sea.

I know making games is hard (game engines, even harder), but honestly, even CoD: MW never had these issues, and that was 2006 or something using a modified, old id Tech engine.

I mean, heck ArmA is a PC exclusive! I really don't mind the game isn't launching with a campaign, but the performance is really going to be a sour point with me, post launch...

@rogerx: Not just linux, any higher level code is translated to assembly and then machine code, as Madoc points out. But yeah, i understand what you're saying now, earlier i thought you meant coding directly in assembly, because you wrote "Not all programmers know how to program in Assembly Language", followed by an embedded application example, where you might use Assemly directly in some cases.

Anyway, it's clear now so...peace.

IT'S WORKING (nologs)

Stutter's quite less with no logs, still a bit while zooming in while flying or when a lot of objects load/pop-in (like the town) but as such it's become much smoother.

CPU Utilization is still lower than 0.70 even with default settings, so will have to experiment some more with cpuCount.

GPU utilization has gone up (after nologs, and only a bit, but it's over 60% most of the time). There's still a lot of loading and unloading to/from the GPU's memory, i wish all objects could be loaded before mission launch.

Still quite a bit of disk access going on during the game, my drive LED blinks constantly throughout. I'm running the game from an SSD, surprised that logging hits performance so much.

@devs: couldn't you log to RAM first and then write stuff periodically to the disk? Might not hit the game so much.

Textures don't hit performance now (since 0.72, nothing to do with nologs), terrain still does, so do objects, PIP, view distance.

On topic, with 0.72, saw a drop in utilization with CPUcount=8, exthreads=7 when previously it was higher.

@Dwarden, thanks, will take a look.

@rogerx: I don't think anyone in PC game development can use assembly, simply because of the multitude of configs. But even then, you have optimisations like SSE, AVX, multi-threading, GPGPU, etc. that can help by speeding up certain workloads.

Most of that work tends to be manual.

When you're developing embedded applications, you're targeting a specific device so you can do stuff in assembly/machine code, on the the PC it's hardly recommended. What you're saying is the very reason consoles last as long as they do, devs chuck old cumbersome routines and re-write and optimize stuff from the ground up.

@white thanks. I'll take a look at that discussion, if i can find it.

Their dev update page mentioned something about improved objects thread synchronization so let's see how that works out.

Most of my testing has been done with the Beta, and some with Alpha, no change between both performance wise.

True, AI is entirely CPU dependent. I'm testing without it for now. How's performance in unmodded Arma 3 PvP? My internet's sort of sucky so i haven't tried yet.

BTW, the cpu=threads=120 didn't work for me. Limiting pre-rendered frames to 1 from 3 game me exactly 2 fps more lol. Still seeing max util with 8 CPUcount and 7 extra threads. Even tried other combinations, but nope. :|

I wonder if they'll still be able to tweak this. If they do, i think even older CPUs like mine should be able to run it well.

p.s. Shadows are just on or off at the moment, right? Can't see any difference between low/ultra.

Hey rogerx thanks for pointing me to darkmere's posts. This is brilliant, exactly co-relates to what i've found, though i never tried 120 core and threads. Max i tried was 32 cores, 63 exThreads (because ex is extra, so master + core-1 workers). This caused a drop, so i reverted to 8 and 7.
See: http://community.bistudio.com/wiki/Arma2:_Startup_Parameters#exThreads

From the table, there didn't seem to be much point going over 7, as it would simply add redundancy. Plus core usage seemed to drop, suggesting that it was looking at the last (or first?) 3 bits (so for 9 it was looking at 001, ignoring the MSB, or it was looking at 100, ignoring the LSB). exThreads=120 would either make it see 111 or 000, so i'll have to see how that works (from the above posts it seems it's seeing 111).

@darkmere, I'm adding you on steam (same name), i have quite a bit of data to discuss.

@jddunlap: AI is a part of the problem, but I haven't used AI in my tests described above. I've been trying to isolate issues, and what settings affect what component, so i'm not really testing with AI too much for now. Neither have i played any multiplayer yet, i should really XD

@rogerx: just chipping in with whatever i've found, mainly wanted to talk about thread scheduling possibilities. Will check your posts to avoid repeating stuff.

@Mobile Medic: Ditto. Except it's never hit 12 fps due to AI, for me, only objects and view distance seem to cause that sort of drop.

Did some more testing, -cpuCount=8 -exThreads=7 -maxMem 6144 seems to enable the maximum resource utilization on a pure quad core, non-HT CPU.

Any higher settings for maxMem (seems to control virtual memory) seems to revert the maximum to around 5100MB (virtual).

with the above CPU/thread settings, i saw around 63 software threads spawned by the game, whereas with CPU=4 and 7 extra threads it spawns around 35 (as reported by Resource Monitor and Process Explorer).

-exThreads=9 with a cpuCount of 8 led to a significant decrease in master CPU thread activity and the other cores saw a fall in utilization.

The render thread needs attention. On the editor, master core(thread) activity drops and the render core/thread peaks, allowing the GPU to actually work properly. In game, the render core/thread holds the GPU back, unless looking out over the horizon or the ground or sky.

The render thread seems to be held back by whichever thread's looking after object count and view distance.

When the game loads, all 4 cores are used, during the editor there seems to be some degree of dynamic core scheduling (thus allowing the render core to peak), but during the game i have an incredibly strong suspicion that static scheduling is used, with a block size smaller than that required to fully occupy cores.

Cores have to synchronize, inducing overhead and/or under-utilization.

I'd currently suggest that this be changed to dynamic/guided scheduling so that cores can be utilized more effectively, but obviously it's not going to be THAT simple, i would guess.

Then there's the issue of memory management, devs may want to consider pre-loading textures and static objects if possible.

Texture and object pop-in seem minimized by setting the object distance to view distance and changing object quality to ultra.

Haven't yet properly tested what sub-systems get affected by PIP and terrain.

@jddunlap: I did some extensive testing with view distance and object quality, extremely CPU dependent, and between 500m to 12000m there's a drop of over 40 fps for me. I guess you have a CPU with higher IPC and/or clock speed than I have (i have a core 2 quad Q8400).

Well, from whatever monitoring i've done, i see one CPU pinned at around 90% while the other three cores sit at around 50%, on occasion rise higher (together).

GPU utilization varies wildly for me, rarely above 90% though.

Mostly CPU bottlenecked here, 26 to 50 fps usually, higher than 50 while looking at the ground, sky, open ocean, etc.

Core 2 Quad Q8400
GTX 560
8GB DDR3-1333

Edit: Added HWiNFO64 logs, images of settings, and DxDiag info to ticket (Arma3_hwinfo64_logs.7zip)

Edit2: Added CPU vs FPS, GPU vs FPS graphs, along with markers explaining activity at that time.

Still exists in 1.48. :/

Still an issue. After 5 months of having been reported. Yay.

Confirmed, happens even if you stand on it.

More info here:
http://feedback.arma3.com/view.php?id=13615

Oh yeah i noticed this once or twice too.

@Aikmofobi - that's not a fix.

@Costavojik - it doesn't, as we've noted above, it hasn't been seen in other games.

@nnbengboy2 - no, Arma 3 isn't crap. It's a massive effort and quite an enjoyable game...still has a lot of rough edges but it's getting better.

@pops: Hope they share the tip with Bohemia.

This still hasn't been fixed :(

EDIT: I don't think i've seen this issue in any game in the last 15 years that i've been playing PC games.

Yeah i was aware you couldn't change the severity, was wondering why the mods kept it so low.

But as you say, it's probably because it's cosmetic, but i hope the solution is as "trivial" as the problem.

I'm still at a loss as to why severity is "trivial". Next to all the texture/object pop-in, this must be the most annoying thing about the game.

Update it to "always reproducible". it's annoying as hell, was about to post a duplicate.

Happens to all terrain, just most noticeable on inclines/uneven surfaces.

There are bipods on some weapons, but you can't deploy them. Could do this pretty simply in America's Army, and is quite useful for long range shots.

(In AA, if you were prone and your weapon had a bipod, pressing 'G' would deploy it. Otherwise, 'G' was usually used to switch to an under-barrel grenade launcher, if equipped)

Happens with hands while swimming as well. Have posted a similar ticket here:
http://feedback.arma3.com/view.php?id=9713

@bez: Happens on concrete too, around the barracks on the Stratis airport.

Also walk through rocks (uploaded image).

(that's from the Commanding showcase, the hill to the SSW where it's suggested you take cover)

Yeah in the Supports showcase, all the OPFOR have their feet inside the terrain, or when they go prone, half of their bodies disappear.