Jump to content

Fireball

Member
  • Content Count

    341
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Fireball


  1. It seems to me that tree LODs (or LOD switching) had been modified. They look now much more proper and foto realistic, but FPS suffers during flight.

    This is also apparent in my latest Coastal Flight BM run;

    - blue is 70951 with exThreads=3

    - yellow is 71213 with exThreads=7

    - red is 71726 with exThreads=7

    armafpsanalyzer_2010-06-24_032708.png

    As you can see, latest beta hogs flight view performance pretty much. I like the view though.

    It would be a good compromise to switch to low LODs if FPS drops below 15, IMO.


  2. I have already checked this issue before and it looks long and confusing to me. The primary description is way too general ("Bushes and deciduous trees are an absolute performance killer, these need to be optimised. ") and I cannot see any repro steps in the issue at all.

    I agree, it's been held too generic and got cluttered up.

    But I've made a self-running repro mission using camera scripts. So no repro steps needed there; that's why I've linked directly to my comment where the link to the attachment is visible.


  3. I've been trying some single player (EW campaign) with -exThreads=7 and since I had a sluggish feeling ("jumping" movement), switched back to -exThreads=3. The jittery movement didn't go away, so I terminated Skype which had blown up itself again to ~200 MBs memory usage and then it was smooth again.

    And as expected, switching back to -exThreads=7 it's all fine, but with my GPU I didn't expect improvements;

    Indeed that is the case, but it was still a recordable difference; the coastal flight FPSAnalyzer curve (% spent below fps) looks a bit flatter on the top than with -exThreads=3 (thus the high FPS shots had average more FPS again), the average FPS has improved by 1.

    One thing I noticed; the scripting performance went bad drastically again; after one hour of host server of a Warfare BE session, 1 "second" of the respawn timer equaled roughly 2 real life seconds again.


  4. why no one of you guys don't tried switch to "aware" mode

    instead post here long ? instructions ?

    how to make from arma another one COD-like-shooter????

    The problem is, if above in the poll stated "additional reasons" come to pull, you can (still) not override the "Danger Mode" (bounding overwatch) using the Aware/Safe Mode order.

    IMO it should be kind of "reset" with the Aware Mode order and only (permanently) overridden with "Safe Mode" though.

    EDIT:

    Another problem, which the poll does not address, is that if you're getting under fire or order "Take Cover", the whole crew starts the bounding overwatch and might be pinned with slow (bad!) tactics in the middle of a large field without any cover and you can't get them to MOVE THE HELL OUT!


  5. First run - try it out without addon/mods (=vanilla) and report good or bad things :)

    Actually it's supposed to fix crashes from previous betas concerning file packing, empty LODs etc. so go and do test it as usual ;)

    (Keep in mind though, that Addons may deliver other bugs, which should not be connected with the core game.)


  6. Guys why do you test beta patches with custom mods. Tests should be on vanila A2. For sure there is something wrong than with that addon if it crashes

    Well, for one it's sure we should check core game aspects and basic performance only without mods, but since ArmA II lives from the modding/mission making community, it's imperative that BIS does not break stuff for them.

    There is also the script performance cutting in - missions like Warfare BE with or without ACE2 e.g. make great use of scripting. Just because scripting performance is not optimal (specially in long missions) the solution is not telling people to play vanilla ArmA II instead.


  7. I've made a comparison of patch 70951 (exThreads=3 vs 71141 exThreads=7) with the same settings (most settings to Normal, Shadows to Very High, PP off, AF Very High), Resolution 1680x1050.

    I've used the Coastal Flight FPS BM.

    fps-coastal-flight-70951vs71141.png

    Specially the % time spent below FPS tells the most interesting.

    The lower (or flatter) the cuve, the better; so the blue measurement being the exThreads=7 from 71141 shows slightly better average FPS in the lower regions but it didn't go over 40 FPS so much anymore.

    I guess that means with my 10% OC'ed Core i7 920 (HT off), that with my 8800 GTS 512MB, the GPU usage was already maxed pretty much.


  8. I've seen Suma's remark after I've ran all the benches and I'll thus only summarize the results:

    ArmAIIMark

    It ran on all options pretty much the same:

    Test1: 28-31

    Test2: 34-36 (Hangar fly-by)

    Test3: 30-31

    Test4: 42-43

    Test5: 15-41 (Space capsule)

    So, as we can see, the differences in value are neglectable, the raw numbers are not so important here thus, except for two special mentions:

    Test2, the hangar fly-by stutters considerably with 1.05 and beta (noparam) but with exThreads 1 and 3 it becomes smooth.

    OTOH, Test5, the "space capsule drop", is the most remarkable of them:

    1.05: 15 fps

    beta: 41 fps (no param)

    beta: 27 fps (exThreads=1)

    beta: 31 fps (exThreads=3)

    So interesting is that this is the only test which performs worse FPS-wise on the beta, but with exThreads=3 it feels definitely a lot smoother.

    ArmAIIMark values:

    1.05: 3131

    beta (0): 3649

    beta (1): 3310

    beta (3): 3456

    Chernogorsk Benchmark

    Interesting enough I couldn't find significant differences between any version and param setting, also personally I only vaguely noticed increased stutter on raw 1.05 there.

    I'll do some gameplay testing, as wished, during the next few days and report back.


  9. The stuttering I'm referring to is not really very "micro", though. I do get some "micro" stutter when flying around, but it's hardly noticeable and doesn't bother me. I'm talking pretty considerable framerate drop stutter when turning quickly with Video Memory set to anything other than Default.

    I got the same but I think it is not (BETA) patch related, I think it's the latest Nvidia driver(s), but I <was too lazy>|<did not want to> roll back to earlier drivers in order to confirm it, but I DID already roll back to February BETA which was performance-wise running fine (in this regard) and experienced the same issue, still.

    Please, other Nvidia users with this issue, tell me if you tried by rolling back BETA or drivers.

    EDIT: currently I'm -FLUSH'ing the VRAM all ~30 minutes in order to play


  10. Hello Beta community!

    Since here are many interested testers and many of you probably know of the issue, that some of the very elaborate leaf trees are pulling down FPS very hard:

    http://dev-heaven.net/issues/7866

    I have three pleads to those affected:

    a) deliver feedback about your CPU/GPU/driver involved

    b) help me reproduce the issue

    c) vote up the bug to show some approximate numbers of affected people

    Thanks!

    Remark: I've noticed that (shift)-FLUSH resets the FPS, when the issue with the trees seems to be very strong.


  11. Hello and good evening,

    Situation:

    I have a little Linux Dedi Server (You can't call it a "Server", it isn't a Hardcore Bam Bam Computer, it is only a computer :D). Well, I made settings for a Server with ACE Mods (For Warfare BE 2.059 ACE Lite) and Vanilla ArmA2.

    Definately a problem:

    If I run the ACE Warfare mission, my Client crashes after some time (the 69872 ran for maybe 2minutes, than crashed). With the new Version, it stays for... 10 minutes? But it still crashes - means - he restarts.

    I didn't test it this much without ACE, but it seems to run more stable on Vanilla, but I can't give 100 % for me.

    Yes, be careful with ACE2, since they need to adapt everytime a new beta patch appears, use vanilla for testing and feedback. Check back with ACE2 in a week or so, until they caught up with Beta.

    For me recently, the issues with the trees got worse, but I think it's driver related; see http://dev-heaven.net/issues/7866 - if you notice this issue too, please give some feedback about GPU, CPU and drivers involved. Thanks!

    EDIT: Well, since -FLUSH resets the FPS, it's probably not only driver related...

    Are the latest betas nvidia- patches or what? I still have up to 30% performance- loss since 63826 with i7 920/ 5850.

    Can you see if your issue disappears by rolling back to the february Beta patch? You probably experience the same as I do, and yes if rolling back does not help, it's the driver.


  12. Danny;1614458'](...)

    The Post Processing option ingame does not work after restarting the game' date=' its been this since the devs screwed it up in a early patch. Why isn´t this fixed yet?

    Basicly if you set it to "very high" and restart the game it will be back to low/off (even though it still SHOWS as "very high" ingame). You need to change it to e.g. high and then back to veryhigh to get it working..[/quote']

    Did you try stopping ArmA2, deleting your ArmA2.ini and restarting ArmA2 again?


  13. Overall feels smoother, except there is heavy lag when looking through a zoomed scope. I agree, it seems like the AI have improved somehow, but I'm not quite sure what it is.

    Confirmed on the scope causing reduced FPS. Greatly reduced in fact. I thought it was the clutter addon at first, but I'm back on the old patch, and scope no longer causes fps drop.

    Could you two contribute evidence/computer specs etc. to my A2 CIT bug ticket

    http://dev-heaven.net/issues/10271

    That would greatly help to pinpoint this, since I had this too, but was unable to reproduce it, after starting A2 up for a second time only in vanilla editor. Thanks!


  14. I've got significant FPS issues when going prone, standing up, zooming in by holding RMB or scoping, while apart from aforementioned situations, FPS seems "normal".

    Example FPS measures vs. action:

    walking around normally: 25 FPS

    dropping to prone & standing up: stutter down to 7-10 FPS

    zooming in & scoping: stutter during zoom operation and FPS steady around 7 FPS

    I've tried to make a video but it did not record the FRAPS FPS indicator top left, for some reason.

    EDIT:

    Video on

    for those with the good eye mark (since FPS indicator went missing)

    I tried to repro it in vanilla editor mission with no luck yet.

    EDIT2:

    http://dev-heaven.net/issues/10271

    EDIT3:

    Started some Warfare BE locally on my machine with no such issue yet, maybe a one-time issue, but maybe it will also surface much more after many player tried it for a longer while...


  15. Yes, please do not mix two (or even three) different issues.

    1. what I mean is the grass layer and only that one not hindering AI view

    2. what has been discussed here too, is a good AI feature (anticipation where the enemy could go)

    3. what has been confused with 2. is suppression precision, which is too high; the AI just has a better idea where it lost line of sight to you, than a human normally would have


  16. I know this has been claimed all so many times, but it never has been proved, I think. Maybe this is obvious to those who understand how AI sees, but I was asked continuously to provide a repro for that. So here we go.

    I'm bothered by that issue for a while already and I finally managed to do a repro mission and made a video of it even:

    http://dev-heaven.net/issues/show/5785

    As it seems, if it's about detection, grass is considered if you're hidden in it. But if the line of sight is obstructed by grass and you're already discovered, then AI becomes clairvoyant.

    That produces scenes, as to where AI sees you, dives to (visual) cover into high grass and shoots you precisely, as if they saw you from there.

    I think that behavior is super-human (sort of cheating) and should be fixed. :protest:

×