Project Reality Forums

Boris wrote:Nope, already ruled out here.

My experience begs to differ.

Souls Of Mischief wrote:My experience begs to differ.

Mine also, but in 100-200p tests prior to 1.0 fps drops were never an issue. So, it's not just the player count.

FYI, when I was firing the mini-gun on the Huye, there was a major FPS hit - 50 FPS, even when firing it into the sky.

Souls Of Mischief wrote:My experience begs to differ.

But you don't seem to understand. What you're experiencing is a consequence of a general lack of processor power available to process the game. Increasing player count does increase CPU demands, but it's not the underlying cause of the problem here, as it's been shown that these problems have also occurred with low player counts where they did not do so prior to v1. The problem is deficient processing ability, whether this be due to a general increase in demands from the newer v1 content/processes, or by an underlying fault in the application design that is restricting the availability of processing power available to the game. In my experience, it is not being caused by player count specifically. You could add a bunch more vegetation to a map, or bots, or animated objects, sounds, or particles, and likely produce exactly the same outcome as processor resources become insufficient to process the game.

Really, the PR devs responsible for working on the PRBF2.exe and other associated binaries/scripting processes need to take a close look at what specific processes are causing what demands, where possible. I mean, even v1 beta managed to get released with relatively massive CPU hogging from the PRLauncher process, as nobody had even noticed. It was only strong user feedback that pointed specifically to PRLauncher being the cause of the issue at the time that got the ball rolling towards it being put right. There's nothing to say that there isn't other areas here that need looking at, too, but it just isn't that obvious to the end user where the problem may lie by comparison. If there's still a problem somewhere, it's probably deeper within the internal game processes.

Can you explain why load times are also laboured in v1 compared to earlier versions? These are questions that need answering by people with a deeper technical understanding of the application and processes involved.

But, they're staying silent on the issue...

Souls Of Mischief wrote:FYI, when I was firing the mini-gun on the Huye, there was a major FPS hit - 50 FPS, even when firing it into the sky.

So there you go; you just proved that the problem isn't specifically player count. Understanding now?

I'll test it further on servers with lower player count, hopefully. Will post back when I get the chance.

Also, some official word on these issues would be nice.

While I don't believe the increased player count is solely to blame I wouldn't be surprised if drawing more players on screen impacts the overall FPS. Think about the geometries, player models, and all the animations that happen even when standing completely idle in main. Compounded by more demanding effects and all those unoptimized assets (you guys may have tidied up a lot, but there are still some buildings/environmental effects in Fallujah that brings some rigs to their knees).

I think a lot of people are experiencing a cumulative result where frames are concerned.

player count seems to be the largest factor, speaking for myself. once fallujah is running past maybe 80 players, the drop is obvious and consistent. that's not to say that i dislike 100p. many maps still run fine at capacity.

Back in 0.98 on 128 player servers I could run without lag, the same thing on FH2 128 servers, so I don't think the player amount is the issue here.

I'm fairly certain that player count is related to the majority of the performance issues, BUT it is not the root cause of them. I would expect the cause to be one of the changes to the core functioning of the game that has changed in 1.0.

If I get a new computer soon with a i7 4770, 8 gb of 1600 ram 2 DIMM standard HDD and a NVIDIA GTX 680 ill be okay performance wise on 1.0? Following this thread has me a bit worried.

Lange wrote:If I get a new computer soon with a i7 4770, 8 gb of 1600 ram 2 DIMM standard HDD and a NVIDIA GTX 680 ill be okay performance wise on 1.0? Following this thread has me a bit worried.

I'd like to say yes for sure! But... I'm not sure...

iwingi wrote:I'd like to say yes for sure! But... I'm not sure...

Hope so this comp should do BF3 on ultra at 80 fps average easily but many people are reporting having that kind of performance and doing crappy with PR so we will have to see.

Lange wrote:If I get a new computer soon with a i7 4770, 8 gb of 1600 ram 2 DIMM standard HDD and a NVIDIA GTX 680 ill be okay performance wise on 1.0? Following this thread has me a bit worried.

All I can tell you is that you should be good performance-wise. If you're not, it's not your computer's fault.

Also, ditch the i7 4770 processor for something cheaper and get an SSD IMO.

I'm getting this and I'm not in a 100 player MP server. I'm playing in Coop with 48 bots. I get ~20fps while in other BF2 1.5 mods I'm getting ~30 - 50fps. I just played Forgotten Hope (in BF 1.5) with 48 bots and was getting ~40fps. I suspect this all to be due to scripting bugs slowing everything down. I was not getting this frame rate problem in previous PR versions. Is there a bug that has already been put in for this ?

DJ Barney wrote:I'm getting this and I'm not in a 100 player MP server. I'm playing in Coop with 48 bots. I get ~20fps while in other BF2 1.5 mods I'm getting ~30 - 50fps. I just played Forgotten Hope (in BF 1.5) with 48 bots and was getting ~40fps. I suspect this all to be due to scripting bugs slowing everything down. I was not getting this frame rate problem in previous PR versions. Is there a bug that has already been put in for this ?

Generalized, yes.

So, did some testing with the Fallujah West map here and found the following:

Most performance-affecting settings between the versions should (hopefully) have been the same, as video.con, audio.con, and general.con config files were duplicated across profiles before testing. FWIW, video settings were:
Results:
OK, so "test" = identifier for the test; map = "fallujah west std" layout, local server, no bots; "pr" = PR version used; "load" = map load time in seconds; "corner x2" = test location where fps readings were taken, x2 (ancient) 7800GT video cards in sli; "gpu" = gpu-z reported gpu load average.

As can be seen, test "a", PR 0981, produced by far the highest framerate in the test @ 99fps. This is effectively at the default framerate cap of 100 FPS in BF2 (game.lockfps default) - I didn't bother to unlock it during testing, so it may even go higher unleashed. GPU-Z showed general GPU core utilisation at around 77%, indicating no GPU restriction involved in limiting FPS. CPU utilisation is probably less than 100% here, too, given the game.lockfps cap @ 100 limiting.

Test "b" shows the result in PR 1036 - same video settings, same location, etc. Framerate has taken a big hit here @ 54fps, with GPU utilisation dropping right down to 43%. This appears to indicate a CPU/other bottleneck occurring.

So, OK, maybe it's just the newer fallujah_west map version in v1.0.36.0 having higher system requirements than the older v0.981 version? Right, so let's swap out the 1036 version map for the older 0981 version, but load it in PR v1.0.36.0. Presumably, if the newer version map has higher demands, then the old version should probably run faster?

Test "c", 0981 version fallujah_west map loaded in PR v1.0.36.0. Surprisingly, framerates are identical to the new version map test, @ 55fps, with 43% GPU utilisation. Load times for the old map were also the same as with the new version, taking somewhat longer to load in PR 1036 than PR 0981.

Test "d" (added later) - Ran the 0981 test with the default framerate cap removed. This allowed framerate to increase a bit to around 103fps. This is probably where the CPU limitation comes in, as overall GPU continued to show under-utilisation @ 82%.

Questions I'm asking:

Why do maps take longer to load in PR 1036?

Why is there such a significant FPS difference between PR versions, but not map design related?

I'm not saying there's for-sure something wrong with PR 1036 here; I'm just curious as to what's causing the discrepancies here.

...

OK, did some more tests...

Maybe PR 1036 runs extra special effects settings on high settings compared to 0981, causing extra load times/lower framerates? K, so set video.con profiles to the following (the lowest possible for 1036):
Results:
game.lockfps was set to 10000 to remove the fps cap. As can be seen for test "e", PR 0981 still rules the day, with a 25 second load time, and 124 fps framerate. 74% GPU utilisation hints at CPU being the bottleneck on higher FPS.

Running the same 0981 version fallujah map in PR 1036 raised load times by 11 seconds to 36 seconds, with framerate dropping to 108 fps for 66% GPU utilisation. Again, CPU bottlenecking being the likely fps limiter here.

Test "g", 1036 version fallujah on 1036 PR showed no discernible performance difference in comparison to the 0981 map version, with identical results throughout.

So, conclusion? Some aspect of PR 1036 appears to cause it to perform poorly compared to 0981, at least during this simple test.

A little info on the test location: location used was the corner hmmwv garage in the U.S. base, facing the wall, looking towards the city. Position was identical each time, mouse aligned with the wall edge.

System specs (the newer system): https://www.realitymod.com/forum/f26-pr ... ost1942526

^Best post 2013.

Yes, best indeed. Serious testing ! Confirms some suspicions I've had. I still have an older PR installed so can play that at the moment for the higher frame rate.

iwingi wrote:Generalized, yes.

Thanks. Saves me putting in unnecessary bug report posts.

Awesome test Boris,,,really,,Thanks for the time spent in it!!