Major Performance Issues

[Boris]

Did that,,,al running processes set to core #1,, only PRBF2 set to run at core #2.. Odd to say but frames went down by 8/12 .. Any ideas???

The idea in doing that was so that you can see for yourself that the PRBF2.exe process (actually, the main game engine part of it) is actually using the CPU to the best of its ability, not as a means of achieving a higher frame rate.

How did you compare frame rates anyway? Proper A/B test? Run PR windowed in the background, map loaded, run fraps for fps readout (or use renderer.DrawFps 1), open task manager, change affinity on the fly, compare rates without moving position in game. I do not see any fps drop here when doing that.

There's also PRBF2.exe child-processes (Direct3D, DirectSound, etc) to consider that run on separate threads than the main game engine thread, which when forcing affinity to a single core constricts these to having to share the same core, where they would otherwise use other cores, away from the main game engine thread (as far as I understand it anyway - tests here seem to prove this).

[Prevtzer]

It could be that other processes running on your machine are using the same core that you set PRBF2.exe to use, with the result being them stealing a portion of the cycles. What I did here to minimise that was to set other applications that use any significant degree of CPU, like PRLauncher, Process Hacker, etc, affinity to use other cores to ensure PRBF2.exe was getting the most it could.

...

Anyhow, no work today, so did a load more faffing about. F'ing long-winded, and boring as hell, but FWIW:

Code: Select all

#	map		pr	load	hangar		gpu
m	ramiel		0981	32s	155fps		95%	0981 map loaded in 0981, high settings
n	ramiel		1036	43s	67fps		41%	0981 map loaded in 1036, high settings
o	ramiel		0981	28s	205fps		93%	0981 map loaded in 0981, low settings
p	ramiel		1036	39s	172fps		78%	0981 map loaded in 1036, low settings

All are Ramiel STD map, local server. I used the 0981 version map as PR 0981 wouldn't know how to handle the 1036 version ARF faction (couldn't be arsed messing to get it to work).

"m" - PR 0981, high video settings, position inside a hangar set looking a particular direction.

"n" - PR 1036, high video settings, same position inside hangar. Increased loading time, big fps drop, and GPU under-utilisation by comparison.

"o" - PR 0981, lowest possible video settings (for 1036 - 2,2,2,0,0,1,1,1).

"p" - PR 1036, lowest possible video settings (for 1036). Increased loading time, moderate fps drop, moderate GPU under-utilisation.

Code: Select all

#	map		pr	load	repaircrate	gpu
q	ramiel		0981	21s	257fps		93%	0981 map in 0981, low settings, no statics
r	ramiel		1036	32s	252fps		92%	0981 map in 1036, low settings, no statics
s	ramiel		0981	29s	163fps		96%	0981 map in 0981, high settings, no statics
t	ramiel		1036	40s	69fps		40%	0981 map in 1036, high settings, no statics

I removed all staticobjects (buildings, walls, etc) from the map for the next tests to eliminate them as an influence (except for the U.S. repair station which I used as the test point location).

"q" - PR 0981, low graphics settings.

"r" - PR 1036, low graphics settings. Increased load times again, but fps is not far off the PR 0981 result.

"s" - PR 0981, high graphics settings.

"t" - PR 1036, high graphics settings. Very big fps drop here, with typical increased load time.

Code: Select all

#	map		pr	load	repaircrate	gpu
u	ramiel		0981	28s	205fps		95%	0981 map in 0981, high settings, no objects
v	ramiel		1036	39s	82fps		38%	0981 map in 1036, high settings, no objects

Went further by stripping all movable objects from the map (vehicles, bipods, etc).

"u" - Lean & mean 0981 reference.

"v" - Same map in PR 1036. Very big fps drop, with usual longer load times. Hmm, what's going on? Surely with all these objects removed we should be boiling the cause it down pretty soon?

Code: Select all

#	map		pr	load	repaircrate	gpu
w	ramiel		0981	27s	208fps		95%	high settings, no objects, no overgrowth
x	ramiel		1036	38s	83fps		38%	high settings, no objects, no overgrowth

Removed all overgrowth from the map (trees, bushes, etc), too. Enviroment is almost totally empty now other than for terrain, a few rocks, and basic ground texturing.

"w" - ok...

"x" - PR 1036 - So, huge fps drop again. Why?

I noticed something odd happen. As I approached the single, lone object remaining on the map - the U.S. repair station being used as the reference point - I noticed the fps drop out all of a sudden. Move away, or look away, and fps comes back up, move closer it drops out. I ran some more tests between versions to be sure:

Code: Select all

PR 0981, high graphics settings, repair station up close = gpu load 96%
PR 1036, high graphics settings, repair station up close = gpu load 40%

I didn't record fps in the above, but the general result is about the same as for tests "w" & "x" above.

Ran the same test using low graphics settings:

Code: Select all

PR 0981, low graphics settings, repair station up close = gpu load 94%
PR 1036, low graphics settings, repair station up close = gpu load 94%

OK, so some graphics setting is causing a huge fps drop when close to objects. To cut a long story short, the switch point turns out to be the 'Level of Detail' (LOD) point (if you want to call it that) where shadows on objects start to be rendered by the engine. It's about 50 metres from the object at a guess. Every time the object come into range, fps took a nose dive.

So, I ran a bunch more tests, one for each shadows config setting:

Code: Select all

PR 1036, vehicle_depot_us lod point, shadows off,  gpu: 94%, 248fps (no switch point)
PR 1036, vehicle_depot_us lod point, shadows low,  gpu: 38%/94%, 84fps/233fps
PR 1036, vehicle_depot_us lod point, shadows med,  gpu: 38%/95%, 85fps/234fps
PR 1036, vehicle_depot_us lod point, shadows high, gpu: 38%/95%, 83fps/228fps

The two values between the "/" separator represent the difference in measurements between the switching point where shadows become enabled/disabled. What becomes apparent here, is that at any shadows setting beyond "off", CPU utilisation appears to take a big hit, causing fps and GPU utilisation to drop out. There was practically no difference as far as performance figures go between Low, Medium, and High settings. Only switching shadows off completely cured it, when using PR 1036. What's odd though really is that the only object on the map is this single U.S. repair station, so it's not like there's tons of shadows to calculate here, just a single object consisting of crates, cammo net, etc. So it just seems that as soon as shadows become enabled at all, irrespective of complexity, there will be this big CPU hit accompanying it, at least based on what I saw here in these tests.

Anyway, that's as far as I've got. I guess I need to look at how PR 0981 acts with shadows now at this point, as it might be significantly different judging by some of the results seen above.

BTW, I'm not saying this is the cause of people's problems here at all, just that it could explain part of it, at least here where I'm seeing these big fps differences between versions. This lot won't mean anything to anyone already running all low graphics settings, with shadows set to "off", but still having fps problems. But for anyone playing with shadows enabled having fps trouble, it could be worth try running without them to see if things improve much.

Quoting for awesomeness! Great job.

Your efforts are much appreciated, Boris!

In light of his testing, can you add an option to disable all shadows in Launcher?

[Boris]

In light of his testing, can you add an option to disable all shadows in Launcher?

It's already possible to configure this, you just need to set the individual option for it on the "Graphics" tab. You can set both "Dynamic Shadows" and "Dynamic Light" to "Off" there.

Using the in-built "Low" graphics profile option actually leaves these turned on, so it's not the lowest possible graphics option available. Anyone struggling should definitely manually set these off, or at least shadows, as this seems to be by far the biggest fps killer here.

[Prevtzer]

It's already possible to configure this, you just need to set the individual option for it on the "Graphics" tab. You can set both "Dynamic Shadows" and "Dynamic Light" to "Off" there.

Using the in-built "Low" graphics profile option actually leaves these turned on, so it's not the lowest possible graphics option available. Anyone struggling should definitely manually set these off, or at least shadows, as this seems to be by far the biggest fps killer here.

Weird, I remember trying to turn off lighting and shadows and I still saw them. I'll try again today.

[SShadowFox]

Actually, that would be "Lighting" settings, which on "Low" is set to be what used to be "Medium", and that kills quite a lot of FPS, "Dynamic Lighting" and "Dynamic Shadows" never affected my FPS in a huge way.

[Boris]

Thought I'd put up some screenshots that relate to the previous post I made that illustrate the difference between PR 0981 and PR 1036 in how shadows appear to operate. Apologies for the file size of this lot (in their original PNG form)...

These are all using the 0981 version Ramiel map, heavily modified to remove virtually all objects except for the U.S. repair station. They show the point at which shadows start to be rendered for the object in view, and its effect on frame rate. Due to the distance involved - where the shadows switch on/off - the images don't really show anything different other than the slightest change in lighting on the crates in the distance. Quoted frame rates are taken using Fraps FPS overlay, which produces a more stable reading than the in-built BF2 counter, which will show up as discrepancies in apparent value here.

First up is all "High" graphics settings, shadow off at this point (just outside of the range where it switches on):

PR = 0981, FPS = 268, GPU = 95%


Next up is the same setup, but running in PR 1036:

PR = 1036, FPS = 267, GPU = 94%


The frame rates there are as good as identical between versions.

Next up is the same scenario, though with the player model moved just into the range where shadows start to be drawn:

PR = 0981, FPS = 232, GPU = 95%


So, a 36fps drop for 0981 when shadows switch on.

Next up, same thing but using PR 1036:

PR = 1036, FPS = 92, GPU = 37%


Here's the big difference I see here between the versions: PR 1036 dropped 175fps here where PR 0981 only dropped 36fps. I don't know why this happens at this point, and haven't decided on whether it's actually that much of a problem during real world usage, but it does seem to show that there is some significant difference going on somewhere that could potentially cause the game to run poorly compared to older versions.

I ran the same tests on low graphics settings in an effort to eliminate other aspects of PR 1036 having an effect on the way shadows operate. I won't post the screenshots, but here are the results from that:

All "Low" graphics settings:

Code: Select all

PR = 0981, Shadow = OFF, FPS = 360, GPU = 93%
PR = 1036, Shadow = OFF, FPS = 344, GPU = 89%
PR = 0981, Shadow = ON, FPS = 333, GPU = 93%
PR = 1036, Shadow = ON, FPS = 121, GPU = 34%

So, looks pretty similar here to how things were when on all "High" graphics settings. There's not much difference between versions when the shadow engine is inactive (out of range of being turned on), but again, a significant drop in PR 1036 when it becomes active, with an apparent CPU demand increase being revealed through the decrease in GPU utilisation, having the effect of starving the graphics cards the frames they could otherwise produce if fed better.

I ran a bunch of comparison tests between Low, Medium, and High shadows quality, too, but as yet haven't noted any discernible difference between them as far as quality goes. I guess I'm probably missing something about that... :

...

In conclusion, what seems odd about all this is that apparently if you have shadows enabled at all, at any quality setting, and are near to any object in-game that produces a shadow, then you're going to see this CPU hit, irrespective of shadow complexity. It's as though if the shadow engine ever switches on for any reason, then game efficiency is going to take a big nosedive. But, it doesn't appear to operate in this way in PR 0981, so it could be something to be looked at in PR 1036.

...

Anyhow, and again, I'm not saying there's a fault with PR 1036 here, and none of this means anything to anyone having problems even with shadows turned off - that'll be a consequence of issues in other areas - but hopefully the info here is at least a little useful to some.

[shahram]

PR v 1.0 is a fail in coding ( or whatever you call it ) although it is good in look.
thanks boris; It seems there is a serious problem with object's shadow in game and I hope it will be fixed very soon.
Fallujah and Ramiel are unplayable for me.
if you can't fix it, it is better to come back to 0.981 version and just add new properties in the way before you did that through patch.

[SShadowFox]

The better thing to do, for me, is to put back the capability of having Low settings on Lighting, at least until they can resolve these issues, it would probably not resolve the problems with people that have good computers and have these issues, but it would certainly help some people.

We lived with people using those settings for 8 years, can't we live with that for another few months?

[-1-Gabe-1-]

The idea in doing that was so that you can see for yourself that the PRBF2.exe process (actually, the main game engine part of it) is actually using the CPU to the best of its ability, not as a means of achieving a higher frame rate.

How did you compare frame rates anyway? Proper A/B test? Run PR windowed in the background, map loaded, run fraps for fps readout (or use renderer.DrawFps 1), open task manager, change affinity on the fly, compare rates without moving position in game. I do not see any fps drop here when doing that.

There's also PRBF2.exe child-processes (Direct3D, DirectSound, etc) to consider that run on separate threads than the main game engine thread, which when forcing affinity to a single core constricts these to having to share the same core, where they would otherwise use other cores, away from the main game engine thread (as far as I understand it anyway - tests here seem to prove this).

I see..
Test was done as u described it,,chose a position to remain,,alt tabbing the game,,task manager,, an so on..

I know i might sound stubborn but my frames do go down,,,

Thanks a lot for taking the time to answer man!!

[Michael Z Freeman]

But for anyone playing with shadows enabled having fps trouble, it could be worth try running without them to see if things improve much.

I tried with all settings set to as low as they would go. Frame rate dropped to around 16 to 17 at some points . At first I thought the launcher had failed to reduce the settings, but there was breakup on road textures due to minimal texture filtering. I am very curious as to what is causing this because, as I said, none of my other BF2 1.50 mods do this. In my experience certain shaders can often cause this kind of thing. Maybe they are not getting turned off at lower settings ? But I'm only guessing. Anyway I look forward to the launcher doing some update magic sometime in the future then I can PR party on again .

[Stealth Clobber]

I find it ironic that BF4 Beta is now suffering the same problems PR 1.0 had when it was released, horrible frame rates and 100% CPU usage.

[KaB]

The good thing about BF4 is that in case you meet performance issues, you can still go back to BF3, as it's pretty much the same game.

Whereas for PR, there's nothing else to do than waiting... Or crying.

[SShadowFox]

The good thing about BF4 is that in case you meet performance issues, you can still go back to BF3, as it's pretty much the same game.

Whereas for PR, there's nothing else to do than waiting... Or crying.

ArmA 3, or maybe even vBF2.

[Michael Z Freeman]

The good thing about BF4 is that in case you meet performance issues, you can still go back to BF3, as it's pretty much the same game.

Whereas for PR, there's nothing else to do than waiting... Or crying.

I have BF2 v1.41 and v.1.50 installed on the same machine and multiple versions of various mods. I have PR version 0.981, think it is (EDIT: actually its 0.87), which I modified by replacing the menu with an old version so that it runs on BF v1.41 (this is so I can have commander artillery in Coop). However you don't have to install v1.41 of BF. Multiple versions should be able to exist in the BF 1.50 mods directory. This may involve changing the directory name to "pr" every time you swap versions around. I have not tried this yet but it should be possible. Just find the old downloads for previous versions.

[Arab]

I tried with all settings set to as low as they would go. Frame rate dropped to around 16 to 17 at some points . At first I thought the launcher had failed to reduce the settings, but there was breakup on road textures due to minimal texture filtering. I am very curious as to what is causing this because, as I said, none of my other BF2 1.50 mods do this. In my experience certain shaders can often cause this kind of thing. Maybe they are not getting turned off at lower settings ? But I'm only guessing. Anyway I look forward to the launcher doing some update magic sometime in the future then I can PR party on again .

Run it in Windowed Mode, All Low, AA off, Right-click on Start Menu, Properties and Click on Auto-Hide, Open PR, Control-Alt-Delete -> Task Manager, Right-Click on PR and Maximize.

I think there's rendering bugs that needs to be looked at.

[tankninja1]

Some maps seem to be big offenders of laggyness. I made my own little program that passively monitors lag and takes the average.

Muttrah City: >15fps
Fallujah West: 15fps
Dovre: 18fps
Ramiel (aas version only): 17fps (for some reason get much better fps on ins)
Saareema: 18fps
Korengal: 20fps
Lashkar: 15fps

Some maps that run much smoother
Black Gold: 30fps (though that map always cause ctd when the map ends)
Shijia: 25fps
Qwai: 24fps
Xiangshan: 27fps
Charlie's Point: 25fps
Kashan Desert: 29fps

Several key factors that I have noticed:
Player concentration
High number of rounds exploding/being fired
Smoke
Low view distance (fog/dust)
1k maps

Also it's worth mentioning that I got much better fps on Muttrah, Lashkar, Ramiel, and Fallujah in .98

[Souls Of Mischief]

Any official word on the performance issues or it's time to get 2x Titans, i7 and 16 GB's of RAM?

[iwingi]

Any official word on the performance issues or it's time to get 2x Titans, i7 and 16 GB's of RAM?

What don't people understand??? That won't help you at all unless you have a real completely shit PC. If you run other games fine, then don't upgrade!

[Michael Z Freeman]

Or go play paint ball. No freezes !

[Prevtzer]

What don't people understand??? That won't help you at all unless you have a real completely shit PC. If you run other games fine, then don't upgrade!

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