Major Performance Issues

[Arab]

Yeah, but if you get 250fps you won't even see 80 fps drops in performance
(bumping for DEV input)

Well, as soon as a developer has time, they will answer I'm sure. There's no rush. After all, deadlines set always puts un-needed stress and pressure on people. Meanwhile, just try my suggestions.

But all when the developers have the time to improve the mod apart from real-life. I mean, if I was the developers, I need to concentrate more on life and not let the addiction/fun of mod creating get to me too much just to please alot of people. People are important, but game is not number 1 priority. Breaks, life, we are all human, so just be patient, the developers are just normal people who are part of the community, not EA/Dice.

Patient Bear

[Michael Z Freeman]

Good things come to those who wait.

[KaB]

Good things come to those who wait.

This gave me shivers.

[Prevtzer]

[Boris]

Oh well, here goes with this lot...

So yeah, did a load more testing here fwiw, learnt a thing or two along the way (though no great revelations)...

* TLDR at bottom of post *

First off, I wanted to run some more 'real-world' benchmark tests as opposed to just taking fps readings on empty maps. I picked Ramiel here as it's a pretty heavy map I find, similar to Fallujah West. I ran the 0981 version Ramiel map throughout, as PR 0981 wouldn't like the 1036 version ARF faction, so probably wouldn't work without messing about editing it. This should also help keep the tests consistent between versions. I did edit the AI config on the map though to remove controlpoint neighbouring - so that bots would spawn and stay put instead of running off to cap the next flags - to enable frame rates to remain consistent between tests.

I won't display the accompanying screenshots here, so click the links if you want to view them.

First up, Ramiel 0981 map in PR 0981, all-high graphics options, 96-bots loaded:

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	0981	36	all-high

Running well here considering there's a lot of bots running, with probably about 30 of them in the immediate vicinity. You might notice the sky is pretty clear here with just a small smoke plume in the distance.

...

Next up, same setup, but in PR 1036:

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	1036	11	all-high

OK, so, a big performance drop here compared to PR 0981. The huge obvious difference here is that PR 1036 renders numerous huge black smoke plumes compared to PR 0981, even though it's the same version map running on both.

...

So, it seems effects could be having some impact here on fps, so let's run a test with all graphics options set to "Low" to try to even the version differences out in that respect:

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	0981	39	all-low

OK, so not that far off the frame rate achieved in the all-high graphics settings test above. There's been a marginal increase in fps, I guess due to removal of the effects like the small smoke plume in the distance, though I'm not sure what else. Note that shadows are still enabled here though as the "Low" option still leaves them switched on.

...

Now, the same setup, but running in PR 1036:

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	1036	18	all-low

So, again, a big drop in fps happening there even though we're configured to all "Low" graphics options. What's obvious though is that the big smoke plumes are still being rendered, in spite of running on all-low settings, which I suspect are having quite an impact on frame rates. I didn't look into this closely, but it seems like the "Low" quality plume animations run at a lower frame rate than the high versions, so I guess that could be the change that occurs here when switching between high/medium/low configurations - that they're always drawn, just at higher frame rates at higher settings.

...

Right, so I decided to edit these smoke plumes out of the map to run some tests without them, to see if they really were causing a significant impact on fps. I decided to strip out all fire/smoke staticobject effects from the map, though in truth I might have only needed to remove the smoke-producing objects, but I couldn't identify those that specifically produced smoke plumes easily at the time versus those that didn't, so I just removed all fire-smoke objects in the end instead to ensure their removal:

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	0981	38	all-high, fire/smoke removed

At 38 fps, that puts Ramiel in PR 0981 without fire/smoke only slightly above the same setup with fire/smoke at 36 fps, so the fire/smoke effects are not having a big impact here.

...

Now the same on PR 1036:

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	1036	21	all-high, fire/smoke removed

At 21 fps, that puts PR 1036 10 fps higher than in the earlier test with the fire/smoke enabled, so, fire/smoke is definitely having a significant effect on performance here.

...

But, there's still a big difference in frame rate showing between PR 0981, and PR 1036 here. I'm thinking shadows are probably a big part of this. So, I wanted to compare the difference shadows were having here separate from the fire/smoke impact, so ran a couple more "all-high" tests with just shadows set to "Off":

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	0981	48	all-high, shadows off

48 fps with shadows off in PR 0981 - that puts it 12 fps higher than with shadows enabled in earlier tests, so a significant performance increase there, even in 0981.

...

Same test in PR 1036:

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	1036	27	all-high, shadows off

27 fps without shadows puts PR 1036 16 fps better off than with shadows at 11 fps. That's a very significant difference, too, so shadow effects are certainly kicking arse here on this system, costing a lot in performance.

...

OK, so, assuming shadows and fire/smoke are the primary causes of apparent differences in performance between PR 0981 and PR 1036 here, then if we strip both of these from the map, then we should hopefully be getting about the same fps for each version afterwards:

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	0981	52	all-high, shadows off, fire/smoke removed

52 fps equates to a 16 fps increase in PR 0981 versus having shadows and fire/smoke enabled.

...

Same thing in PR 1036:

Screenshot

Code: Select all

map	ver	pr	fps	options
ramiel	0981	1036	46	all-high, shadows off, fire/smoke removed

46 fps equates to a 35 fps increase in performance in PR 1036 than with shadows and fire/smoke enabled - a huge difference. But, we can see that there's still a difference between PR 0981 and PR 1036 versions in fps without these effects enabled, though it's only pretty small now at 52 fps versus 46 fps for 0981 and 1036 respectively, so they're not a million miles off now, indicating fire/smoke and shadows seeming to be the biggest culprits here on frame rates. I don't know where that 6 fps difference is coming from though as yet.

All of the above tests paired together for easier direct comparison:

Code: Select all

map	ver	pr	fps	options
ramiel	0981	0981	36	all-high
ramiel	0981	1036	11	all-high

ramiel	0981	0981	39	all-low
ramiel	0981	1036	18	all-low

ramiel	0981	0981	38	all-high, fire/smoke removed
ramiel	0981	1036	21	all-high, fire/smoke removed

ramiel	0981	0981	48	all-high, shadows off
ramiel	0981	1036	27	all-high, shadows off

ramiel	0981	0981	52	all-high, shadows off, fire/smoke removed
ramiel	0981	1036	46	all-high, shadows off, fire/smoke removed

...

But, there's more to this story...

Still wondering about the earlier posts I made here where I was finding a big frame rate hit as soon as I approached the lone repair station on the stripped-out Ramiel map, I did some messing about between the versions, and between vanilla and pr, and between running 1 versus 2 (in SLI) graphics cards, and eventually discovered something about that.

In the end, I found that the majority of the shadows problem actually appeared to be being caused by the Nvidia driver software in use, not - as it seemed at the time - by PR itself.

To cut a long story short, the problem appears to have arisen as a consequence of PR having renamed the main game executable from "BF2.exe" to "PRBF2.exe". The reason this resulted in problems is that the Nvidia driver software automatically scans an HDD during installation to detect known games so that it can apply special configurations where necessary for a particular game to run optimally. The problem here though is that - with "BF2.exe" now being named "PRBF2.exe" - the software no longer detects it as a recognised executable, and so doesn't apply any specific optimisations/configurations to it when it's run.

I noticed this around the time PR v1.0 came out, as it was about this time a lot changed here with the PC I was running (bought a bunch of new hardware), in that I noticed the driver didn't want to engage SLi on the 7800GT cards I had installed at the time when running PR. To correct the issue I had 4 options available in the driver software that could control this:

Code: Select all

Nvidia Recommended
Single-GPU
Force Alternate Frame Rendering 1
Force Alternate Frame Rendering 2

It was running as "Nvidia Recommended", and defaulting to Single-GPU by default. To force this otherwise leaves 2 options: AFR1, or AFR2. As I understand it, these modes force the graphics cards to run in unison (as "SLi") by alternating the frame rendering load between each card. The idea here being that one card processes every odd frame (1, 3, 5, 7, etc), the other card every even frame (2, 4, 6, 8, etc). Apparently, from what I read online, the difference between these two modes should simply be that AFR1 = GPU1 does odd frames, GPU2 does even frames, versus AFR2 = GPU1 does even frames, GPU2 does odd frames. Simple enough, right? So, to force SLi I just set them to use AFR1, checked SLi was running, and forgot about it.

But, as it turns out now, there is actually a big difference between these two settings. So I took a look at what the driver software configures by default for the vanilla BF2.exe: "Force Alternate Frame Rendering 2". Hmm, why AFR2, and not AFR1? What's the practical difference? Anyway, so I created a custom "PRBF2.exe" profile in the driver software and configured it to AFR2 to match the vanilla BF2.exe config - and it made a big difference. Running tests in PR after this showed the issue where fps would drop out drastically as I neared the repair station in PR 1036 no longer apparent, operating the same now as it did in PR 0981, where the point at which shadows switched on would show a far less significant drop in frame rate.

Some figures:

Code: Select all

map	ver	pr	fps	options
ramiel	0981	0981	232	all-high, shadow on
ramiel	0981	1036	92	all-high, shadow on, afr1
ramiel	0981	1036	230	all-high, shadow on, afr2

So, PR 0981 there - still being "BF2.exe" - has the Nvidia driver automatically detect it as a recognised game and configure AFR2 for it by default. PR 1036, now "PRBF2.exe", isn't detected automatically, so required manually configuring for SLi operation. But, of the two possible settings here, the difference in performance is obviously huge. Now, with it set to AFR2 as it should've been, frame rate change for PR 1036 when shadows enable operate the same as for PR 0981, clearing up the massive discrepancy between them. I've no idea why this is so at this point, but there you go...

...

I ran a couple of extra Ramiel 96-bot "real-world" benchmarks afterwards, as tested above, to see the differences there:

Code: Select all

map	ver	pr	fps	options
ramiel	0981	1036	11	all-high, afr1 (before - test #2 above)
ramiel	0981	1036	23	all-high, afr2 (after - fixed afr setting)

ramiel	0981	1036	21	all-high, fire/smoke removed, afr1 (before - test #6 above)
ramiel	0981	1036	38	all-high, fire/smoke removed, afr2 (after - fixed afr setting)

Now, let's compare these new, fixed results with PR 0981 performance:

Code: Select all

map	ver	pr	fps	options
ramiel	0981	0981	36	all-high (before - as test #1 above)
ramiel	0981	1036	23	all-high, afr2 (after - fixed afr setting)

ramiel	0981	0981	38	all-high, fire/smoke removed (before - as test #5 above)
ramiel	0981	1036	38	all-high, fire/smoke removed, afr2 (after - fixed afr setting)

So, we see now that with the correct AFR setting configured, and with fire/smoke removed from the map, there is apparently no difference in fps between PR 0981 and PR 1036. This is good, as it should hopefully show that the causes of the differences here, on this system, have been boiled down correctly, in this case to a combination of two things: PR v1.0 fire/smoke effects, and broken shadows handling as a consequence of a bad GPU driver config for 'SLi' operation.

Incidentally, and not recorded here, is GPU utilisation, which improved hugely compared to when running on the AFR1 setting in earlier tests. On AFR1, utilisation would drop right down to around 35% the instant shadows became enabled on the object, whereas with AFR2 enabled the cards were showing as good as full utilisation in the same scenario. Good and fixed, I'd say...

...

TLDR; (1) PR v1.0 black smoke cloud effects are heavy, even on Low settings. (2) Nvidia graphics card drivers might not detect PR:BF2 v1.0 correctly, and so not automatically configure itself appropriately to run it, requiring manual intervention to correct.

[AncientMan]

If you use Nvidia Inspector to insert prbf2.exe into the Battlefield 2 profile applications list, does that work the same?

Does the driver profile just affect SLI configurations, or do you see FPS improvements when running a single card as well?

Do people with AMD/ATI cards have similar issues, and if so, do driver profiles targeting prbf2.exe help?

[Michael Z Freeman]

Ah, ha ha ha. Don't believe I did not check this in the Nvidia control panel Boris. Will do as soon as poss. It's easy to forget I guess when everything is using the same Battlefield 2 engine. Dying to find out if this is all it is but my machine is booted into Linux at the moment. Someone needs to give you an honorary certificate from the PR University in Hawaii for this

EDIT:

Anyway, so I created a custom "PRBF2.exe" profile in the driver software and configured it ...

So how did you do this ? In the Nvidia control panel or using something like Riva Tuner and Nvidia Inspector ? Looking into this now but could do with some kind of help with it before I start accidentally hitting overclock settings and launching video cards into orbit

EDIT: OK, I used Nvidia Inspector to add "prbf2.exe" to the Battlefield 2 profile. On my machine it did not make any difference to PR 1.0. Afterwards I loaded AIX2 up into BF patch 1.50 and had a high frame rate game with high responsiveness. Someone mentioned loading PR in windowed mode which I've not tried yet. Anyone tried that ?

[[FSA]IrRahman]

Hey, are you the Boris Vorontsov, creator of ENB mod?

[Boris]

If you use Nvidia Inspector to insert prbf2.exe into the Battlefield 2 profile applications list, does that work the same?

Unfortunately I can't easily test that now as I've since swapped the SLI'd cards out for something better (single card - and it'd be impractical to revert even temporarily as it's a water-cooled setup). I might have an opportunity to test it here at some point fairly soon though if/when I get around to setting up a second system. I guess it should work fine though?

Does the driver profile just affect SLI configurations, or do you see FPS improvements when running a single card as well?

I don't know if the Nvidia profile for "BF2" only affects SLI. Certainly the "AFR2" setting it configures is only for SLI, but I don't know if there are other configuration changes taking place in the background for "BF2" that could also affect single-card setups. As far as for what Nvidia Control Panel showed, the only change being made for the "BF2" profile when running SLI was that "Force Alternate Frame Rendering 2" was configured. From memory, the "AFR" option isn't available when running on only a single card, I don't believe, so the whole "BF2" Nvidia profile just echoes whatever the driver Global Settings are set to: "Use global setting" (though I can't go back to confirm 100% at this point).

As far as for how things ran when SLI was disabled, I believe fps performance was about the same between versions during the stripped-out Ramiel only-the-us-repair-station shadow test, meaning that I was only seeing the big fps hit when SLI was active (due to the shadows issue). I never tested for Nvidia "BF2" profile effects when running specifically on only a single card though. To do this, I would have had to disable a card in the system, then check for differences with and without any Nvidia "BF2" profile that might still have been applied by the driver.

On the new, single Nvidia card I've since installed here, though there's no "AFR" option showing (as there's no SLI possibility), there does appear to be other optimisations occurring when looking at the Nvidia profile for "BF2.exe" that were not present when running the older cards, so it's entirely possible that different cards/setups will have different configurations being set by the Nvidia driver software for BF2 (bf2.exe) when detected, so I wouldn't assume at all that the only special customisation being applied by the Nvidia profile for BF2 is AFR2 rendering for SLI setups. Really, it might be best if everyone were to add PRBF2.exe to any existing BF2 driver profile where possible to be sure the hardware is being configured right for the application.

[Boris]

So how did you do this ? In the Nvidia control panel or using something like Riva Tuner and Nvidia Inspector ? Looking into this now but could do with some kind of help with it before I start accidentally hitting overclock settings and launching video cards into orbit

Heh, nothing more complicated than opening Nvidia Control Panel > Manage 3D Settings > Program Settings > Add > Browse to PRBF2.exe, then duplicate the settings shown for the "Battlefield 2 (bf2.exe)" profile, which on mine simply showed "Force Alternate Frame Rendering 2" as being the only configuration difference that differs from the default Nvidia 3D profile.

EDIT: OK, I used Nvidia Inspector to add "prbf2.exe" to the Battlefield 2 profile. On my machine it did not make any difference to PR 1.0.

I'd never even heard of 'Nvidia Inspector' before seeing it mentioned here, so it's all new to me, but it seems like the better way to go about doing this than to try to recreate the BF2 profile for PRBF2 through Nvidia Control Panel. I don't think the change is going to make any difference for anyone who doesn't run an SLI setup though, assuming the only special optimisation that occurs for BF2 is the AFR2 rendering option, and not a bunch of other stuff that relate to single-gpu setups, too.

IrRahman;1956368']Hey, are you the Boris Vorontsov, creator of ENB mod?

No. I just dodge bullets.

[iwingi]

I just check in the NVidia control panel, bf2.exe had all the same options as Global Settings which prbf2.exe uses.

[Michael Z Freeman]

Accept Nvidia Control Panel does not show all the special settings flags that Nvidia Inspector shows. If these have any bearing on optimisations I do not know. However applying them to PRBF2.EXE by adding that exe to the same profile as BF2.EXE makes absolutely no difference on my machine.

I'd never even heard of 'Nvidia Inspector' before seeing it mentioned here, so it's all new to me, but it seems like the better way to go about doing this than to try to recreate the BF2 profile for PRBF2 through Nvidia Control Panel. I don't think the change is going to make any difference for anyone who doesn't run an SLI setup though, assuming the only special optimisation that occurs for BF2 is the AFR2 rendering option, and not a bunch of other stuff that relate to single-gpu setups, too.

I don't have SLI, so if that?s the the only optimisation then, yeah, I would not expect to see any difference.

So, dammit ! I want to get to the bottom of this. There's not reason I should be running PR 1.0 @ often 20fps while on the SAME machine and SAME Battlefield version I am running Forgotten Hope plus AIX2 and getting up to 40 to 60fps. Occasionally it dips to 20fps but the responsiveness is vastly better than PR, all the effects and so forth are running in the proper way. My God, what is going on in PR because its something. Massive frame rate drop as well as huge occasional freezing glitches for a few seconds. This is all on LOW settings and as a small resolution @ about half my normal 1440x900.

... and, drum roll please ... low and behold ...



Notice the lack of threads. Think this was mentioned somewhere in this thread.

Compared to AIX2 (remember, same machine and same BF version) ...



Notice the extra threads.

Now just in case its useful, AIX2 cpu activity ...



vs, PR ...



BTW don't take the fps counter as representative as I have vsync off and so it goes all over the place, plus FRAPS is not always representative of the overall responsiveness of BF.

I noticed this when I first installed. Both the launcher and PRBF2.EXE both create shortcuts with an ADMIN icon on them. Both of them are requesting admin privileges for some reason, whereas I can run Forgotten Hope and AIX2 without admin privileges. This sometimes effects Vista's handling of game performance. Plus these EXE's are seriously effecting threading performance of BF2 in some way.

So. Maybe its time to put this in as an official bug report. I think I've narrowed this down to a problem with PR launcher and PRBF2.EXE seriously effecting performance on many machines.

(Thanks to Boris for almost forensic troubleshooting inspiration).

[Boris]

Notice the lack of threads. Think this was mentioned somewhere in this thread.

Compared to AIX2 (remember, same machine and same BF version) ...

[image snipped]

Notice the extra threads.

You could use something like Process Hacker (free/open source) to view those threads; it should show what's what, why there's more, etc:

[ATTACH]7901[/ATTACH]

[Michael Z Freeman]

Thanks Boris. I'll check this out when I get some time

EDIT: OK, interesting little util but I don't think anything else needs to be done here.

1. Your extensive testing has shown the fps discrepancies.

2. I have shown there is a threading problem causing the lowered performance.

As if I needed convincing I ran Basrah Pronvince 16 (forget what its called in PR 1.0). On a rooftop in 1.0 fps drops to ~20fps. In the same map, same rooftop, on BF 1.41 I get ~60fps just dropping down to 55 a bit. Different BF patch but I get the same behaviour with other mods in BF 1.50.

So enuff said. I've said my bit, time to leave this to the every wonderful PR devs

[Heavy Death]

Ok. I have this idea that might be onto something or a complete kick in the dark.

So according to Boris' tests, when an object shadow is present, performance takes a hot. Is is possible that a command line initializes the shadow being rendered, but it gets called again and again every frame, bogging down the process? Might be some connection to the object occlusion checking for occluded objects?

Just brainstorming, or in worst case scenario, brainfarting.

[Boris]

Did some more arsing about here, but on a couple of slower systems this time (which should be a bit more relevant to this thread):

First system, a 2005'ish CPU/mobo/memory combination:

Code: Select all

System Information
------------------
  Operating System: Microsoft(R) Windows(R) XP Professional x64 Edition (5.2.3790)
      Architecture: 64-bit
          Language: English (United Kingdom)
       Motherboard: Abit AN8 SLI Series NF-CK804
         Processor: AMD Athlon 64 X2 4400+ Dual Core Processor @ 2.20GHz
            Memory: 4.00 GB
      DIMM Modules: DIMM0: 1.00 GB @ 333 MHz
                    DIMM1: 1.00 GB @ 333 MHz
                    DIMM2: 1.00 GB @ 333 MHz
                    DIMM3: 1.00 GB @ 333 MHz
         Page File: -260100096.00 B
    .NET Framework: 4.0

Display Information
-------------------
 Display Device(s): Dell P1110 on NVIDIA GeForce 7800 GT
   Display Mode(s): 1280 x 1024 (32 bit) @ 85 Hz
    Driver Version: 6.14.13.0623 (306.23)
    Display Memory: 256.00 MB
     Multisampling: 2, 4
               DPI: 96 (100%)

Audio Information
-----------------
  Primary Playback: (none)

Second system, a 2008'ish CPU/mobo/memory combo:

Code: Select all

System Information
------------------
  Operating System: Microsoft(R) Windows(R) XP Professional x64 Edition (5.2.3790)
          Language: English (United Kingdom)
       Motherboard: BIOSTAR Group GF7050V-M7
         Processor: Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz (Physical: 4, Logical: 4)
            Memory: 4.00 GB
      DIMM Modules: A0: 2.00 GB @ 800 MHz
                    A2: 2.00 GB @ 800 MHz
         Page File: -261062656.00 B
    .NET Framework: 4.0

Display Information
-------------------
 Display Device(s): Dell P1110 on NVIDIA GeForce 7800 GT
   Display Mode(s): 1280 x 1024 (32 bit) @ 85 Hz
    Driver Version: 6.14.13.0623 (306.23)
    Display Memory: 256.00 MB
     Multisampling: 2, 4
               DPI: 96 (100%)

Audio Information
-----------------
  Primary Playback: (none)

Both systems had audio disabled, ran without virtual memory configured, shared the same HDD hosting the same PR 0981/1036 content files, and had fresh installs of XP SP3 64-bit installed and configured.

First up, I wanted to test load times. I was sure that, since the PR v1.0 release, load times were much longer than previously. I've since wanted to confirm this to be sure by comparing against PR 0981:

//--- Initial Load Times (offline profile) ...

Code: Select all

sys	pr	load	notes
4400+	0981	0:30
4400+	0981	0:30
4400+	0981	0:30
4400+	0981	0:31
4400+	0981	0:30
4400+	1036	1:26
4400+	1036	1:27
4400+	1036	1:26
4400+	1036	1:28
4400+	1036	1:31

First, results from the AMD X2 4400+ machine. Note that I used offline accounts during these tests, which disables file data verification and gamespy login stages that would otherwise occur if using an online account, slowing the process a little more. I don't think 0981 does file verification at start up (though I didn't check closely), so this should help to balance the difference between versions in that respect.

What's clear to see is that 0981 gets in there way faster than 1036 - 3x faster, in fact.

...

Code: Select all

sys	pr	load	notes
Q8200	0981	0:25
Q8200	0981	?
Q8200	0981	?
Q8200	0981	?
Q8200	1036	0:50
Q8200	1036	0:51
Q8200	1036	0:51
Q8200	1036	0:51
Q8200	1036	0:52	zero-compression zips
Q8200	1036	0:51	zero-compression zips

Same tests, but with the Intel Core 2 Quad Q8200 system. Similarly longer load times for PR 1036, though not so significant now, with 1036 being only twice as slow here. Seems I forgot to run more than one 0981 load time test here, or didn't log them down, so there's only a single 0981 showing. It should be representative though, likely repeatable...

So, given that these systems are running on the same HDD, same PR data files, same OS, same GPU/driver, why the difference in scaling between the two? It seems as though this is occurring as a consequence of differences in system processing power. But then, what's being calculated here, or more specifically, what's being calculated here that differs between the PR versions? There's a very significant difference in load times that seems to magnify as available processing power reduces - the 2005 system is like 3:1 difference, 2008 system around 2:1, and my 2012 system (not shown here) around 1.5:1 or less.

Included in those Q8200 results are a couple of "zero-compression zips" tests there for PR 1036. I'll get into this more later on, but they are load time tests after having decompressed the PR 1036 main game content zips before re-packing them as zips, but with zero compression. This was done to see if the longer PR 1036 load times were being caused by some issue with decompressing game content, possibly reliant on CPU processing power. However, as can be seen here, there was no apparent difference to the PR 1036 load time after doing this, so I think that that theory can be ruled out.

...

Load time/FPS tests...

First up, 'all-high' tests, where graphics settings are cranked up to full. The //---*,*,*,*... numbers shown represent the respective value configured in the profile folder "Video.con" files for each setting. They represent, in order:

Code: Select all

TerrainQuality
GeometryQuality
LightingQuality
DynamicLightingQuality
DynamicShadowsQuality
EffectsQuality
TextureQuality
TextureFilteringQuality
Resolution
Antialiasing
ViewDistanceScale

Key for the column header: sys = system on test; ver = map version; pr = pr version; load = time taken for the map load progress indicator to move from 0% to 100%; "corner x1" = location of test + number of graphics cards in use; gpu = gpu load as measured in gpu-z/nvidia inspector application.

First, Fallujah West map, same test location as used in some earlier posts here:

//--- 3,3,3,3,3,3,3,3,1280x1024,4,1.00 ...

Code: Select all

sys	map		ver	pr	load	corner x1	gpu	notes
4400+	fallujah_west	0981	0981	2:24	25		52	
4400+	fallujah_west	0981	1036	3:38	23		47
4400+	fallujah_west	1036	1036	3:31	22		49

Q8200	fallujah_west	0981	0981	1:48	38		73
Q8200	fallujah_west	0981	1036	2:23	30		60
Q8200	fallujah_west	1036	1036	2:24	31		58

Q8200	fallujah_west	1036	1036	2:33	30		58	zero-compression zips

For the 4400+ system, we see map load time was significantly higher in PR 1036 - over a minute longer - though with only relatively minor differences in in-game frame rates between the two versions - 3 fps in all.

Similar results for the Q8200 system, though load time difference has been reduced to around 35 seconds. In-game frame rates are showing a fair difference here though, with PR 1036 producing around 8 fps less, even when running the same 0981 version map. One could attribute this to higher graphical demands in PR 1036, though the GPU utilisation numbers don't really show that as they show a decrease, not increase, so it seems more like PR 1036 having a higher CPU demand in general here instead causing frame rates to drop.

...

Next up: Ramiel map. Also used in earlier tests here, is a pretty heavy location in the city with a bunch of of black smoke clouds in view (screenshot):

//--- 3,3,3,3,3,3,3,3,1280x1024,4,1.00 ...

Code: Select all

sys	map		ver	pr	load	hescowire	gpu	notes
4400+	ramiel		0981	0981	2:17	26		58	
4400+	ramiel		0981	1036	4:34	19		99	gpu limited

Q8200	ramiel		0981	0981	1:48	36		76
Q8200	ramiel		0981	1036	2:52	21		99	gpu limited

Big load time differences between versions as usual. Significant differences in frame rates showing, especially on the Q8200 system, but we're running into problems here as the 1036 tests are pegging the GPU @ 99%, so we're not getting true readings. No doubt it's the black smoke clouds causing that, aside from the fact the 7800GT card is laughably weak by today's standards, so we're going to have to reduce load on it by bringing graphics settings down to eliminate the bottleneck...

...

Knocking anti-aliasing off here to reduce the GPU load:

//--- 3,3,3,3,3,3,3,3,1280x1024,Off,1.00 ...

Code: Select all

sys	map		ver	pr	load	hescowire	gpu	notes
4400+	ramiel		0981	0981	2:18	28		46	
4400+	ramiel		0981	1036	4:36	21		99	gpu limited

Q8200	ramiel		0981	0981	1:48	44		69
Q8200	ramiel		0981	1036	2:47	23		99	gpu limited

Frame rates are climbing, but not by much, and still hitting the GPU limit here, so... more load reduction needed... :/

...

Dropping to 800x600 resolution...

//--- 3,3,3,3,3,3,3,3,800x600,Off,1.00 ...

Code: Select all

sys	map		ver	pr	load	hescowire	gpu	notes
4400+	ramiel		0981	0981	2:15	28		41	
4400+	ramiel		0981	1036	4:14	23		58

Q8200	ramiel		0981	0981	1:44	44		62
Q8200	ramiel		0981	1036	2:47	34		82

OK, now we got it. So, having overcome the GPU limitation, we see fps differences in a truer light; 5 fps difference for the old 2005 system, 10 fps on the newer 2008 system. The black smoke clouds in PR 1036 seem to be GPU heavy more than anything, if not all GPU load. I guess anyone running into nasty fps drops when in the vicinity of these clouds would do well to check their GPU load to make sure it's not rammed, as if it is, then you should know where the bottleneck lies. Dropping anti-aliasing, effects quality, resolution, would be the things to change to reduce this.

But still, significant differences in fps between versions, though GPU utilisation is now below maximum capability. It still feels like there's an increase in CPU load in 1036. Maybe the smoke clouds place an increased load on the CPU, too? We can disable them completely later to test for that.

...

Time to run some all "Low" graphics profile tests, which should hopefully help iron out some of the differences between the PR versions:

//--- 2,2,2,1,1,1,1,1,1280x1024,Off,1.00 ...

Code: Select all

sys	map		ver	pr	load	hescowire	gpu	notes
4400+	ramiel		0981	0981	2:01	33		42	
4400+	ramiel		0981	1036	3:47	27		40

Q8200	ramiel		0981	0981	1:28	54		65
Q8200	ramiel		0981	1036	2:34	39		66

Still big load time differences. Frame rate differences are still significant, too, especially on the Q8200 system. Interestingly though, GPU utilisation looks around the same for both systems, and both PR versions here, though with apparent differences in FPS.

...

Above settings are equivalent to setting the "Low" profile option in PRLauncher. The following settings are equivalent to going further than that by manually setting DynamicLightingQuality and DynamicShadowsQuality to "Off" - the lowest graphics settings possible:

//--- 2,2,2,0,0,1,1,1,1280x1024,Off,1.00 ...

Code: Select all

sys	map		ver	pr	load	hescowire	gpu	notes
4400+	ramiel		0981	0981	1:55	31		35	
4400+	ramiel		0981	1036	3:47	27		40

Q8200	ramiel		0981	0981	1:24	57		65
Q8200	ramiel		0981	1036	2:29	42		62

Pretty odd results really. The 4400+ system actually shows less fps for the PR 0981 test, and exactly equal for PR 1036, compared to having shadows/lighting enabled, though 0981 load time reduced. Not sure why...

Only relativly minor increases in fps for the Q8200 system, with a slight reduction in GPU load.

...

OK, reducing things down to minimal now, time to test with fire/smoke disabled. Eliminating it - along with the lowest possible graphics settings - should hopefully bring the version differences a lot closer.

//--- 2,2,2,0,0,1,1,1,1280x1024,Off,1.00, fire/smoke removed ...

Code: Select all

sys	map		ver	pr	load	hescowire	gpu	notes
4400+	ramiel		0981	0981	1:55	39		45
4400+	ramiel		0981	1036	3:38	35		39

4400+	ramiel		0981	1036	3:38	35		40	"prbf2.exe" added to driver profile

So, not a massive difference in fps between the versions there, at only 4 fps, but still, there's that extra load somewhere in PR 1036, possibly CPU, bringing things down.

For the third test I specifically added "PRBF2.exe" to the Nvidia driver profile for the "BF2" game to test for whether the driver software is effecting changes in PR 0981 due it detecting a "BF2.exe" file and consequently applying special optimisations to it, which won't occur automatically for PR 1036 with its main game executable now being named "PRBF2.exe". As can be seen though, no practical difference was noted. On an SLI system, on the other hand, doing this could make a big difference (as mentioned here in earlier posts re: AFR2 config).

Q8200 system...

Code: Select all

sys	map		ver	pr	load	hescowire	gpu	notes
Q8200	ramiel		0981	0981	1:25	62		68
Q8200	ramiel		0981	1036	2:25	49		55

Q8200	ramiel		0981	1036	2:28	49		53	"prbf2.exe" added to driver profile

Frame rate differences getting more pronounced again with the stronger setup. Again, it acts as though general CPU load is higher in 1036 causing an overall fps/gpu drop, with "PRBF2.exe" added to driver profile again making no practical difference.

Some additional tests...

Code: Select all

sys	map		ver	pr	load	hescowire	gpu	notes
Q8200	ramiel		0981	1036	2:28	50		53	no prl

Q8200	ramiel		0981	1036	2:37	50		54	zero-compression zips
Q8200	ramiel		0981	1036	2:36	50		54	zero-compression zips

For the first test I ran PR with PRLauncher out of the loop. Results show there was virtually no difference with it disabled, maybe a 1 fps increase at best, with equal loading times, so I think PRLauncher being a cause of apparent performance differences here can be ruled out.

The next two, "zero-compression zips" tests, were two simultaneous runs for testing for differences in load times after having decompressed the main game content zip files, then repacked to zip without compression. Funny thing is, load times actually increased after doing this, even after having fully defragged the HDD. One thought is that the system bottleneck at loading time could be more HDD/controller limited, than CPU-decompression-speed limited, so bigger data (uncompressed) take longer to load in than compressed data + decompression time. Who knows...

...

Enough of this misery...

[Michael Z Freeman]

Stand down soldier ! LOL

[Inspektura43]

I hope thats not a complete waste of time, Boris.

[shahram]

I hope thats not a complete waste of time, Boris.

I hope too. But maybe devs can not fix it.
( because there is lack of knowledge ).
so forget it boris.

[Murphy]

Last night I noticed there are loads of smoke/fire effects that run their animations really fast, on Ramiel I find the way the smoke plumes to look like a time-lapse film. The animations might be rushing through as fast as my computer allows them, I could post a video of how fast the effects run but my point wouldn't be furthered much. I think these smoke effects could be run half speed and actually look less cartoony, this might also help the players with frame rate issues as I'm sure on a slower computer having these smoke plumes run as fast as they can would be like the final nail on a piss poor FPS coffin.

If the dev team thinks it of merit I had the notion of messing around with the smoke/fire effects in the map editor (removing smoke from Fallujah/Ramiel, and also making a map void of everything except these effects) to see exactly how it impacts performance. The only reason I haven't sat down and spent an evening doing this test is that I wouldn't be at all surprised if this has already been looked into. I just can't get over how extremely fast the smoke plumes restart the animation.