Results -9 to 0 of 33

Threaded View

  1. #25
    Player
    RaineMagus's Avatar
    Join Date
    Nov 2013
    Posts
    82
    Character
    Eliya Maxwell
    World
    Behemoth
    Main Class
    Gladiator Lv 50
    I can now confirm, having checked the market board in the northern section of Uld at multiple times of the day, including prime-time, that there "IS" indeed a performance drop when rotating the camera. The drop is however, very insignificant (2-3 fps dip at the maximum when the game is running > 100 fps, with vsync off and the camera aimed directly into a wall).


    Basically to put it another way: I won't notice it unless I disable vsync, the ingame FPS cap / target, disable high-quality transparent lighting, SSAO / FXAA, etc, and additionally move myself to the back alley facing the board (through the wall) -- [Obstruct LOS to the most possible players / objects]. I also had to move up to using the latest MSI Afterburner to actually "see" the FPS hit, using 2.3's new "Sliding Window" based FPS calculation (rather than the once per second of older versions). (the drop is an almost instantaneous hickup)


    Honestly, I'm not sure that this is a bug so much as intended behavior (an optimization as pointed out by Syx). As long as the camera isn't rotating / moving, the scene isn't changing in terms of static-objects in the world between the observer and those objects to be occluded. If a player is stationary (as players primarily are standing infront of the market board or retainer bell) there's no reason to check object-occlusion a second time (until said time as they move). The same can be said for static geometry behind the wall. It's also not necessary to perform VFC against these objects either, or to recompute the view frustum unless the camera is moved. So really ... the FPS drop during turning could be fully intentional in terms of caching object occlusion, and a check re-performed on an interval during camera position changes (or object movement) rather than every frame (this would explain how certain objects can remain occluded when panning the camera initially around a corner -- not being visible for a split second). It would be expected that complexity is slightly higher during panning the camera.


    I've no idea if the difference is Windows 8.1 or my transition to Ivy Bridge / the P8C WS. Sadly I no longer have my P6T7 WS / Xeon w3580 (Gen 1 i7) to test with (which would be a near identical setup to yours). I can say though that my transition to the E3 1270v2 "did" eliminate all load-stutter that I had in Crysis 3 (without swapping Operating Systems -- as I used to run Win7 until almost the end of Win8 [due to severe issues with the mobo's NIC, TCP packets arriving out of order at the application layer] ). My w3580 was clocked at 4.13ghz on water cooling (the w3580 and w3680 chips are unlocked multipliers, which is extremely rare to see for the Xeon line).. The E3 1270v2 is "not" overclocked, as unlike the 3580 it's a locked processor (the P8C WS [and all C206 chipset motherboards for that matter] also do not permit bus speed adjustments [at all] without tampering with the bios).

    That said, I can't shut off PCI-E 3.0 in the P8C-WS's bios (despite that alot of C206 chip boards do permit this). So, I can't really experiment in terms of what causes the improvement over your setup (minus if it's the OS). I can say though from experience that overkill bus bandwidth does have a very real, though subtle effect, on any loading / resource transfer related stutter in a game (despite that it doesn't impact total and average FPS very much).


    EDIT: I suppose I could test this to the extreme degree by moving my 690 down to another slot that runs at PCI-E 2.0 x4. Yet this would be absolutely crippled due to the 690's onboard PLX bridge, and probably meaningless.
    (0)
    Last edited by RaineMagus; 11-23-2013 at 10:26 AM.