MavericK96

I hear a lot of people talking about running at 150% or 200% fillrate. I don't know about anyone else, but that completely kills my framerate. 200% is unplayable, and even 150% most of the time. I've tried 125% or 133% but neither of those look any better than simply running AA at High or Very High, and with AA I get the same or even more framerate as with boosing the fillrate.

That's good to know, thanks. I've been cropping the .RPT files to just the latest instance of ArmA2, but maybe even then that can get too long. ---------- Post added at 04:50 PM ---------- Previous post was at 04:48 PM ---------- You guys need to read through the last couple beta threads. http://forums.bistudio.com/showthread.php?t=99972 http://forums.bistudio.com/showthread.php?t=99927 exThreads is a parameter that has just been introduced as of the last dozen or less betas, so it's likely not going to be in any ArmA2 launcher program.

Nice beta, a few average FPS increase over the last couple betas. Stability seems decent as well. Good work, BIS. :cool:

Is there any reason to change it, say, if you have a much faster upload connection than 64kbps?

You should have those files in your ArmA2 AppData folder after a crash, including your ArmA2.rpt file, and potentially ArmA2.bidmp and ArmA2.mdmp dump files.

Yeah, in the program I get a max of 20 Hz as well. Might be contributing to the issue.

Agreed, except if the bug is something in the game that could break in an "official" mission or something as well. Though, it would be nice if the devs divulged what they changed that broke a bunch of the mods this last beta.

Typically it seems to be anywhere from 1% to 10% CPU power.

In terms of what? Features? Performance? Stability? My vote goes for stability.

Honestly, I didn't see a significant performance increase in terms of stuttering when going to an SSD. Load times improved pretty dramatically, but the stutter is about the same.

Interesting. I'm using a Microsoft Lifecam VX-3000 I believe. I just tried it with your exact settings and I still get a ton of stutter (also, it's way too sensitive for my camera). I'm uploading a YouTube video right now to show. Oddly enough, as soon as I triggered FRAPS to record, the stutter decreased quite a bit. Without FRAPS recording, the jitter is a lot worse than it looks like in the video, but you should still be able to get the idea. ---------- Post added at 04:50 PM ---------- Previous post was at 03:17 PM ---------- Here's the video: Maybe I will try using a camera to take a video instead of FRAPS since FRAPS seems to cause the stutter to be lessened for some reason (less framerate maybe?) ---------- Post added at 05:09 PM ---------- Previous post was at 04:50 PM ---------- Okay, here is a video I took with my camera rather than FRAPs. It's not great but you get the idea. The kind of stutter I experience is awful and unplayable. I'm using the same settings as before (the same as your settings, S-M). I've tried setting them differently and nothing reduces the kind of jitter I'm seeing.

Much better. And wow, yours looks a million times smoother than mine. What webcam are you using?

Final release is only 25 days away...I'm guessing the demo will be released simultaneously with the game.

I can confirm that the Boot Camp missions are fixed in this build.

I stay up late and sleep in late. (unemployed at the moment :() Performance-wise, this beta seems about the same, maybe even a tiny bit better than the previous one. Nice work, BIS. Still need to do some stability testing but I'm guessing as quickly as this one came out there's no major change.

That's what I meant by "Max Frames Ahead"...There is no other option in the nVidia control panel that allows those settings (1 through 8). And I have PhysX GPU acceleration on. I've heard of people getting better performance with it off, but I've tried both on and off and seen no difference whatsoever.

I'm using Max Frames Ahead set at 8 because it seems to make the mouse movement smoother, though I've tried setting it back to default (3) with no change in stability, personally.

Here is the link to the issue now that Dev Heaven is back up: http://dev-heaven.net/issues/10884

What's going on with Dev Heaven? It's been down for quite some time now.

There's really not a lot of free looking in that video. Could you just post one of you standing still and looking around perhaps?

Already been reported in the CIS. Though Dev Heaven seems to be down again at the moment.

Dragging this thread back up because it seems to be down again. Can anyone confirm?

That's interesting. So by using no exThreads parameter, it will default to 7 on a quad core? I tested exThreads=0, and that was different than 7, but it sounds like 0 is not the default for a quad core anymore, or am I mistaken?

The only issue so far is those random 3-5 FPS bouts of slowdown that I'm getting in the costalFlight benchmark. As I posted before, every time it occurs I get a bunch of this repeating in the .RPT file: Virtual memory total 2047 MB (2147352576 B) Virtual memory free 167 MB (175837184 B) Physical memory free 3284 MB (3443736576 B) Page file free 7924 MB (8309960704 B) Process working set 1149 MB (1205788672 B) Process page file used 1367 MB (1433468928 B) Runtime reserved 486 MB (509607936 B) Runtime committed 293 MB (307253248 B) Longest free VM region: 14811136 B, busy 1988648960 B, free 158769152 B Small mapped regions: 10, size 53248 B This is a similar .RPT instance to when I was getting the "Receving..." screen in the middle of gameplay, except this has no "error in v-buffer creation" at the start. So I guess overall this is an improvement? Massive slowdown is better than a crash or a "Receiving..." screen I suppose, but still a little bit of work to do to get it totally ironed out. :cool: EDIT: I've created a tracker issue for this problem here: http://dev-heaven.net/issues/10994

Initial tests with _FPS6_Cherno bench: Build 71141 Avg AvgMin Max Min exThreads = 0 35 25 51 9 exThreads = 1 35 25 52 11 exThreads = 3 36 25 52 10 exThreads = 5 35 25 51 12 exThreads = 7 36 25 53 10 Not super conclusive, but exThreads=5 and =7 definitely seemed a bit smoother to me. Less hard (0 FPS) stutter but still a fair bit of pull (low FPS) stutter. Haven't tested stability yet, but I will do more tomorrow when I have time. ---------- Post added at 03:14 AM ---------- Previous post was at 03:00 AM ---------- I just ran the bmCoastalFlight benchmark, and a couple of times during the flyby the framerate dropped to somewhere between 3-5 FPS for anywhere from 10 to 30 seconds, and then resumed normal framerate. Almost all the way through the second run, the game crashed, saying "ArmA2.exe has caused an error" or whatever the standard Windows APPCRASH message is. RPT is filled with stuff like: Virtual memory total 2047 MB (2147352576 B) Virtual memory free 134 MB (141500416 B) Physical memory free 2962 MB (3105906688 B) Page file free 7435 MB (7796940800 B) Process working set 1191 MB (1249083392 B) Process page file used 1408 MB (1477398528 B) Runtime reserved 487 MB (510656512 B) Runtime committed 304 MB (319045632 B) Longest free VM region: 9179136 B, busy 2022985728 B, free 124432384 B Small mapped regions: 10, size 53248 B Followed by lots of: Memory store: Failed mapping, already mapped 4392 KB, error 8 Virtual free 22859776 B, page free 4294967295 B, physical free 3141357568 B Memory store: Failed mapping, already mapped 4396 KB, error 8 Virtual free 22794240 B, page free 4294967295 B, physical free 3141361664 B Memory store: Failed mapping, already mapped 4392 KB, error 8 Virtual free 22859776 B, page free 4294967295 B, physical free 3141357568 B ... File read error: addons\plants2_tree.pbo,ERROR_NOACCESS Error 3e6 reading file 'addons\plants2_tree.pbo' ErrorMessage: There’s a problem with the disc you’re using. It may be dirty or damaged. And finally: Mods: CA;beta Distribution: 1459 Version 1.05.71141 Fault address: 00999C13 01:00598C13 C:\Program Files\Bohemia Interactive\ArmA 2\beta\arma2.exe file: BM_coastalFlight (__cur_sp) world: chernarus Prev. code bytes: 8B 46 08 8B 40 08 03 46 20 8D 4F FF 85 C9 7C 09 Fault code bytes: 8A 10 88 13 43 40 49 79 F7 01 7E 20 29 7D 08 74 Registers: EAX:00000C5C EBX:016FC604 ECX:00000003 EDX:00000001 ESI:19440D00 EDI:00000004 CS:EIP:0023:00999C13 SS:ESP:002B:016FC5D4 EBP:016FC5E4 DS:002B ES:002B FS:0053 GS:002B Flags:00010206 ======================================================= error: Minidump is unavailable, dlghelp.dll load error... Basically it seemed like every time the "Out of Memory" error might occur, the game slowed down to 5 FPS and puttered along, finally regaining performance in a bit. The game did this about 5 times total before crashing. In any case, I'd say this is somewhat of an improvement. At least there is no "v-buffer creation error" going on in the RPT, and the crash is different.