(Dev's please review this.) How PS2 Works and Where it can be Optimized

One of the performance issues I notice occurs when particle generation is initiated. IE: smoke.

Also the ability to turn off the skybox would be hugely beneficial and should give a significant performance increase on some of our machines.

You are absolutely correct, and it makes very little sense, but when I bump up the graphics quality, the game actually plays significantly better.

Great research, thank you!

I think OP would like to see a standardization on pack / unpacked. IE: 1 place for bundles

I do concur though, that packing will NOT hinder the hacking. Runtime = unpacked, even obfuscation of packs isn't going to significantly slow them down. Likewise at this point the hacks are occurring primarily in the network stream.

We can discus the fps issue till we weight 10 kilo's but what it boils down to is that PS2 engine needs massive ammounts of work, this can take many months.
People have alot of options these days when it comes to gaming, they lost players by releasing this game way to early.

It feels like alpha stage at this point and iam glad i dint spend a euro on this game yet.
Hawken + Mechwarrior seems to be good enough to play soon and we always have GW2 for our pvp needs.

SEO has way to much work to do with hackers / cheaters + optimasation + bugs that we leave and might come back over 2 months or more when they might have improved this game to be playable.

Warning: My post contains random ramblings, but all concerned with technicalities of performance issues plaguing PS2. I don't intend on hijacking the thread, but I like the tech talk, and OP prompted me to post my thoughts

In my experience, every game that uses Shockwave Flash for its UI is slow as hell. It's nice for prototyping, but in practice, it's a hulking turd. In said game, FPS improves by 10-20 frames just by disabling the UI alone.

The most offensive part of Flash is the scripting language. Interpreted languages have no place in real-time gaming scenarios. Lua is also a poor choice. Parsing XML is pretty ridiculous too. I don't understand what is gained by storing data in a tag-polluted human readable text file versus just storing the data in a flat compressed binary format that can be quickly loaded into memory. Parsing is SLOW. Now, I don't have many issues streaming new areas, but if the game actively parses XML during firefights and parses SWF ActionScript, something is very wrong with their engine architecture.

As far as the PhysX goes, it's my understanding the hardware only portion of PhysX is currently disabled, which they only used to render massive amounts of particles. PhysX is both a software and hardware interface library. It's also my understanding that PhysX (the software portion) has received a lot of flak for being CPU heavy. Supposedly, this has been fixed in a very recent (or unreleased?) version of PhysX that takes advantage of multi-core CPUs significantly more than previous versions. Also, it requires careful usage by the programmer to ensure it's hitting each core properly.

Another issue with performance is clientside prediction and LERPing. I understand that absolutely GIGANTIC proportions of CPU power can be chomped up by predicting more and more milliseconds of movement. It's very expensive to rewind, interpolate, and extrapolate every single moving object in the vicinity of the player. Higher ping = more interpolating. Less frequent server updates hurt too, i.e. if server smart adjusts to lower to something like 10 FPS in a big fight (which I swear it does). That can hit client performance pretty big where all the demand transfers from server updates over the network to your CPU's responsibility to predict player and CPU heavy physics objects. This makes me wonder what the server tick rate is anyway. Sometimes I swear it's so bad that bullets pass between a player's last location and current location without a proper lerp.

So all this blabber, any solutions?

A few.

- No more Flash; as a reference, Natural Selection 2 used flash for their UI and eventually eliminated it, giving their whole community anywhere between 5 and 20 more frames per second!
- No scripting languages for real-time systems. Nothing is more offensive to a high performance application than compiling code at run time.
- "Compile" XML files to some sort of release version binaries for rapid client consumption versus ALWAYS interpreting them. Interpreting them should be for the development phase, not for releases!
- Optimize client side prediction by reducing or completely ignoring interpolation on culled objects and rely only on server messages to get updates. With some proper ad-hoc "portals" for indoor areas or big bases, huge performance gains could be realized for clients as well as the server! Less messages exchanged = better performance!
- Make sure the PhysX library is properly taking advantage of multi-core CPUs.
- Encourage better distribution of the player base to reduce extreme load on just a few servers.

Neither of which are MMOs - And GW2 is not a shooter.

Is this supposed to be some troll post?

Hey dev, let me show you how your engine I don't know a thing about works

This has plagued 3D games since 3dFX became popular and 3D acceleration took off. I really thought after a decade, all the performance issues of transparency would be solved. I assume modern engines run through so many passes that simple transparency could stack on multiple passes....

But yeah, being up close to smoke wrecks my FPS, as always. *sigh*

Krizzen,

I would imagine that the size of the tick data packages are MASSIVE in large battles. I wonder about the interpolation of culled objects... But I am not certain how the calcs are done server side to reduce this burden.

It would be interesting to see just how optimized the stream is, UDP, whether they are requiring an ACK back on each packet, and default packets sizes. I bet there is some network optimization that could be done.

Hmm I might have to take a peek at them...

Unless it is imperative to the game, IE: fog of war (smoke), then I can do without its' framerate laggifying visual

Render Thread, the big bottleneck is the render thread.

One cannot simple break the render thread in multiples tasks without loosing sync.

And the render thread runs on CPU.

That means, PS2 will be optimized, but not so much like so many of you guys expect.

I had many, many, many problems related to render threads trough my entire game developer life. And it is a pain in the *** if the game engine is not forged with the multiple render threads concept from the beginning.

Good luck coders.

You can test that statement easily by manually parking cores/setting core affiliation in the taskmanager.

Testing on an i7 W3520 Xeon cpu ( server binned i7 920 ) I found that the game uses 2 cores maybe 3 cores ( could also be that the OS jumps to the 3rd core and offloads resulting in smoother performance, no actual fps gain in my case going from 2 to 3 cores but game ran smoother ). No gains going to 4 cores, game ran pritty bad on 1 core.

Also I noticed a 100% increase in FPS going from 1 to 2 cores.

I think the problem lays here aswell.

The best for now is if people experiment with the renderdistance value in the useroptions.ini file to try and find their sweetspot FPS vs rendering bubble. In cramped spaces like a tech lab chances are that won't work very well regardless of setting since the action will be, cramped instead of spread out.

Alternativly the devs can make the render thread run 100% on a single thread ( core 3 ) and run the rest of the game assets on core 0 1 and 2. Don't know if that is very bandwithd effective though

we need ALL the cores working hard......... specially in large battles.....not just 1 or 2 or 60......is ALL the cores available in the system.....they need to find a solution than let the game scale depending on the number of cores available in the system......not the current dam method

Great thread, nice to see some insight and it would be interesting to see how much of this engine comes from the FreeRealms engine and how much was just a bit of copying and pasting here and there. Without a doubt for a game like this it seems like the best bet would have been to build it from the ground up but maybe that just wasn't in the cards

to everyone throwing in their 2 cents about Flash, keep in mind that Scaleform is pretty much the defacto standard for Game UI these days. If you've played a game powered by Unreal, CryEngine, Ogre or even Unity(although it's not as widely used here as nGUI) then you're playing a game with a flash based UI and to say that every game with a flash based UI is laggy is saying 50%+ of the blockbuster games released are laggy which they most certainly are not.

The only solution I can see from all of the discussions here is that they just need to create a completely separate DX11 64Bit client that is made with 4-8 core(physical) machines in mind and is heavily multithreaded. Anything less than this and we are just going to be chasing our tails around the maypole with duct tape solutions and Sony is going to see a continual exodus of players who feel insulted with 20fps performance on the mini super-computer that they spent their savings on

Disabling 3 cores in the game: 10 fps average. Disabling 2 cores in the game: 20-26 fps average. Disabling 0 cores in the game: 70 fps average. That's all at the busy warpgate where FPS always seems to be fine. So yes: this game does utilize more than 2 processors. It's quite easy to check that really. All you need is alt+ctrl+delete and the processor affinity setting.

But of course the fps still drops to 30 in big fights.

That's on an old i5 750 oc'd to 3.6ghz btw.

This......... for god sake sony listen this man

A note on Flash: I'm pretty sure they use Scaleform for the UI. http://gameware.autodesk.com/scaleform

It isn't very heavy on performance at all.

No,

No and scaleform is an incredibly powerful tool It's main drawback right now is how horribly buggy it is with AS3 but for PC development it's the best UI toolset you are going to get. Now for mobiles it's a nightmare but that's another can of worms. *Images PS2 on my Galaxy S2 and shudders*

I am very happy the community is taking a step forward to help the devs fix the FPS issue of the game.
SOE should hire you guys to make things right once and for all.
Just an enthusiastic follower waiting patiently for a decent fix.

To the people claiming this to be a troll or saying 'oh look its some random guy trying to be smart',
I personally don't care how you see me, but a brief introduction. I'm a former contributor to the Nexuiz project (2.4.2 - 2.5.3), a former dev of Red Eclipse and Tremz: New Dawn. At current I work as a Software Reverse Engineer and Cyber Security Consultant.

Those commenting on the packing of the files have truth in their statement, In fact one could easily just use something like Win Commander to dump an unpacked .exe at run-time. However, those who are just straight up opening the files will have a harder time and all known unpackers for AsPack, for example, do not work properly on win7 though will work on winxp. The main issue regarding the packing is the content control, it shouldn't be all over the place, especially when there are pack files in use.

As for the utilization of cores, windows does allow and often will automatically move things to other cores to balance load. However, without such code in the game to utilize the cores, we'd continuously have to manually un/park cores each time. In doing so, we do see an increase in performance, but the gain is small compared to what an official update will do.