Operation: Make Faster Game

Ryan tell your brother we miss One Must Fall

Thank you guys for this! I'm so glad this is finally happening. :3

i would really like to see render distances worked on to be more reliable and fix infantry popping in and out all the time
i have more problems with infantry pop in/out and low renderdistances than i do framerate

Question: are you also upgrading NVidia PhysX and APEX as part of the process?

I'm glad to see that optimization is finally a priority. I have a ridiculously high-end PC and get surprisingly terrible framerates in this game. I can run BF3 on Ultra at around 150 FPS, in a fairly crowded scene. I get around 25-30 FPS in a busy biodome, in PS2. =/

Lot of good stuff, and hearing a bit of what's happening the scenes is always nice to players like me who also happen to be coders.

Now, if I may ask, how high on the priority list is the benchmark stuff?
I'm assuming the optimization pass is not going to come in one big patch but gradually. So the sooner we have this, the sooner we can objectively test those patches and tell you how things are evolving.

how can you compare that? Are there 200+ BF3 players on that map? .. right

I knew that by mentioning BF3, I'd get some fanboy with a comment like this. That's fine. The comparison is still valid.

PS: You do realize that even SOE admits there's an optimization problem, right? It's OK for you to admit it too.

Right, so:

Physics

Basically you are going to shoehorn in an ALoD system for Physics, reducing the complexity of the calculations depending on the number of objects in the scene or the distance of the object from the control object, filling in the gaps with prediction (of some description). I can see this doing some funky **** straight away, especially with how temperamental PhysX can be.
If you're going to spend the time developing an ALoD system, why not also try using another physics engine, one that can be offloaded to all graphics cards? (and hopefully be more stable...) Granted, Bullet doesn't yet have Next Gen support (or even accelerated particle physics for that matter), and Havok still has poor support for massively multiplayer games, but you will run into a lot of walls with your proposed changes to the PhysX engine. Either way, the physics will be borked for a while.

Player Updates

Do you not already use any form of bit mask to check if clients actually need to be updated?
E.g. Clients server-side object updates position as per clients latest packet, server "flags" clients server-side object as dirty via a bit mask, server only sends updated position data to other clients when/if required (client-side prediction (interpolation (triple parenthesis)) fills in the gaps) in the next packet.

Or are you packing everything to everyone regardless? If so, why?
Multithreaded Renderer
Good stuff. However, any chance now of a DX10 or DX11 renderer for those who can use it?

No, you don't speak for me.

"moves your jaw up and down to make you mimic saying YAAAAAAAAAAAAAYYYYYYYYYYYYY!!!!"

True, but you still can't compare Battlefield to Planetside. It's okay for you to admit it too.

That was an interesting read, to be sure.

Perhaps this is the appropriate thread to ask;

Hardware;
I have a GTX 680, and using the "ultra" preset at windowedfullscreen 1920x1080 with vsync, motion blur, fog shadows, and PhysX off with the framerate limited to 80 and a maxed-out FoV & render distance.

Situation;
In a warpgate with no-one else there, far away from other stuff, staring down at the ground.

Questions;
In the above circumstances, with GPU load at 60% and my FPS hovering around 76.6-76.7(very stable);
1. Why does my GPU load spike to 99% whenever I open up a UI page that renders a model?
(the pages showing a weapon//vehicle//infantry when you hit escape)
2. It's clearly heavy for the game to render UI pages featuring these models - should it be?
3. And if it should, would it be possible to add a checkbox somewhere to opt out of these models showing?

Curious regards,
-Z

The random colored punctuation threw me for a loop. Thought I had suddenly gotten a bunch of dead pixels.

Good stuff to hear though, and hilarious post.

BF3 looks nicer and runs smoother. I don't see how you can't compare it. Just because there's 64 players instead of "200" (not sure I've ever seen 200 players anywhere other than the Crown, which I avoid like the plague), doesn't mean that PS2 should run at 15-20% the framerate.

Consider me more than slightly worried, at least on the CPU utilization front.

I see a whole lot of mention of threads, threads, threads. What I don't see a whole lot of is jobs, jobs, jobs. What plans are there for data-level parallelism? It's incredibly unlikely that the various tick operations are going to take consistent amounts of time across frames and areas considering the highly dynamic (in your own words) nature of the gameplay, and instead of having die area sit idle it would make sense to have all available cores be doing something useful even if they've finished their update task for the frame.

What's going to happen to processors that are released later on in the rather extensive five-year roadmap that's been announced so far? You've already run out of tasks to split off into their own threads, and it seems like the game is going to run into further walls later on. In fact, it's almost the exact same problem we're experiencing now, whereupon the fundamental designs are not designed to scale beyond hardware years behind state-of-the-art. For reference, that's working in the era of the Core 2 and Athlon II X2 in comparison to today.

What's going to happen to processors that *aren't* state of the art, and those that *can't* service the needs of 6 (by my count, correct me if I'm wrong) threads simultaneously? Are they just going to starve/waste however many thousands of cycles per frame doing context switches? What about signaling work? The Windows scheduler is notorious for being rather imprecise with thread wake events unless you putz around with timer granularity, which can have system-wide consequences if tweaked. Intel figured out this was a bad parallelism model with their own Smoke framework in 2008. I can't really see a way for this to scale *down* as-is, and I think the last thing people with low-end rigs want is CPU utilization to get worse.

And on that note, why use D3D9 if you're expressing interest in renderer scaling? There's no real vehicle for threads here short of queueing commands for later submission, which is generally only good for increasing input latency, aka Grand Theft Auto IV AIming Syndrome. The driver's already doing this for you to some extent; without multithreaded submission to actually spread driver work out across cores I think this is basically a waste of effort.


So anyway, big ol' rant. Sorry to rip into you, Mr. Elam, but I do it because I love your game and want the best for it. Good luck with the update though, as I'm well aware this sort of thing is really, really tricky work. And, hey, maybe you're already aware of and working on this stuff and I just can't read

See, that's exactly what planetside 2 needs - developers talking to community.
This kind of posting defuses a lot bad things that could happen on forums.

Just remember guys, when "The Big Patch" comes out, it's extremely likely the game will be broken for a few days regardless of how much testing they do beforehand.

I don't understand the link between the NC and Seattle hard rock band Soundgarden. Please advise

WHERE ARE THE RAGDOLLS