Theory on the Horrid FPS - why it happens

A few renditions back of the "Horrid FPS" thread (ie: a couple thousand posts ago), I saw someone post some info he had learned by fooling around with how he thought the game worked. What he said to do was this:

Stand on the fleet. Jump. While in the air, open your bags.

Doing this causes a quick and total freeze of the game right before your bags open. To prove its not just something tied to a new UI element opening, he said to do the same thing while hitting ESC to open the preferences menu. No freeze.

His theory was that the actual games rendering process is being blocked by the games call for Data from the server to get info on what is in your bags. Ultimately, just bad programming.


So I started to think about some of the other things people have discovered here. How most of the steady low FPS that people get on fleet and in warzones only seems to start once other players are around. IE: you can stand in the start point of the warzone, and get a good framerate, but as soon as the match starts and enemies show up, it drops down to a steady 15-20 fps (even if you normally get 70+ outside of warzones)

What if, similar to the "freezing while bag is opening" method above, the games rendering code is being blocked/lagged while the game fetches data over the net for other players that are nearby.

Its not that your cpu, or your graphics card is being overworked (data shows this by low cpu/gpu usage), but rather, its sitting there unable to render the graphics because something else is blocking it. IE: the call to get data about the other players in your area.

Why would this seem worse when enemy players were on the screen? Perhaps more, or different types of player data are requested when it concerns enemy players, rather than friendly, since you cant attack friendly players, nor can they attack you. But, get enough friendly players in an area at once (Ie: the fleet), and now you have enough smaller data sends happening to cause the same type of slowdown.

Note: Mention of getting data about the players isnt something that would necessarily affect your ping or net lag. The amount of actual net data is still pretty small. Its seems like its the simple fact that WHEN the call is made to get this data, the graphical rendering process that might send data to your GPU, is being blocked until that call is done.

The end result:

Good Ping
Low CPU usage
Low GPU usage
Horribly low Framerate.

Just a theory, since all other logical things seem to be ruled out now. Anything that might help the devs look in a direction they may not have thought about yet. It seems like if Bioware is focused on looking at what the CPU and GPU are trying to do, they may miss this concept entirely as I do not believe the horrd FPS is being caused by either.

interesting though we all know BW will never admit they screwed up and are hoping to keep this as low as possible until they can fix it or get their money back

Its not Bioware's fault.

Its the fault of EA. They clearly rushed the game to be released for Christmas time, when the game needed a couple more months of just development time.

Its up to Bioware to fix the handicap that EA put on them, just like they did WAR, but you really can't blame them - not yet.

What I dont get is this problem didnt exist in the last weekend beta. Not at all.

Yeah, shadows were laggy, sure, but my FPS in warzones was the same as anywhere else, typically 60+

They need to at least compare code from the release version of the game with the last beta.

Sourcsafe, winmerge or some similar software that lets them see what parts of the code changed, so they can figure out why the new code either 1. causes it, or 2. Where the bug is.

im pretty sure BW has at least one person who has thought of this. i would say that, i agree, the game was rushed out to meet holiday sales and should have had more time. so, now we are paying to beta test, while they keep going about what they should have been doing in the first place before releasing it.

my guess, as the patches come down the line we will see things get better. more content and more fixes and more happy...

Not necessarily bad to get data. How else can your client be made aware of changes to your inventory without re-checking what your inventory should be? Like crafting results. What if some items are temporary and vanish after X amount of time? Also a lot of resynch with the server helps the server detect hacking/tampering on the client side.

The bad part would be allowing a request for data get in the way of physics and graphics - as they should be asynchronous of each other.

I've been saying for the last week or so this is the problem. Pressing C does the same thing. Something about the way the game loads in data of other players on some computers is whats causing FPS drops in high populated areas.

Having to query the server to get your bags contents is fine.

Blocking the games graphical rendering to do that query = bad programming

Another way is to have your client first report back your bags contents, that are confirmed via the server data any time a new item goes into your bag or is removed from your bag, not when you only open it. This would mean that you wouldnt need to query the server to open your bags, unless, an item went into your bag right as you were opening it. It puts the workload on the client.

Anyway, this is a side problem. Like I said, the main issue is how the actual query to the server seems to all out block/stop/interupt the graphical rendering process, not just the opening of the bag.

Unfortunately it is the client that cannot be trusted. A hacked client can lie to the server and not report some things, or to avoid reporting into the server at all. Capacity-wise clients tend to not have nearly the same upstream as downstream so burdening clients to transmit more info is typically undesirable.

At any rate your original point about the rendering freeze when the window pops up is noteworthy.

I know nothing about programming, but bad fps is my #1 complaint about the game. I'd really like it fixed BW.