Xaerael posted:

Almost 100%, but the music was loving generic and terrible. Citizens got excited because there was a bit of music transition swells which have been in games for about 18 years now.

his nibs posted:

Hello space friends..

Just caughtupwiththethread.gif over a few days on the mobile on intermittent wifi whilst travelling abroad.

So if I've got this right:

3.0 has been released to all backers and is jank filled gently caress fest
A delayed SQ42 trailer/gameplay thing has been released and is pretty in places with some good music, but has no game play
There has been an abundance of rubbing

Milky Moor posted:

Can't believe this hasn't been pointed out.

The SC inner thoughts thing is - surprise, surprise - borrowed from Wing Commander. Whenever the player would make a choice for Blair, there'd be two options and when highlighted Mark Hamill would read them out. For example, the first choice in WC4 is 'help him out' VS 'straighten him out'.

Hamill, however, wouldn't have such flat, droning delivery. But yes, Chris is just ransacking a previous title for ideas.

his nibs posted:

I've not been able to view any video, but it all sounds hilarious. Crobblers was kinda screwed either way, but releasing 3.0 to all is by far the best outcome for comedy value.

E: Plz some kindly goon pay my tax

Sarsapariller posted:

It mostly depends on what people are up to on your server. If they just do quiet cargo runs you'll be fine, but as soon as they start spawning NPCs there is no limit to how low your FPS can be. NPCs don't even seem to despawn, so that makes everything worse.

happyhippy posted:

I love the CoD IW storyline, I have had a soft spot for anything futuristic war style.
It has some good set pieces and locations.

Alchenar posted:

There's some major revisionist history going on over IW in this thread.

Mne nravitsya posted:

So, if I understand ths correctly, the framerate could go SO LOW that it starts hitting negatives and taking frames back from my PC? Wouldn’t that create some sort cosmic blackhole type event localized entirely in my computer room?

Mr.PayDay posted:

I love how the r/sc narrative is now „don’t show potential new backers 3.0 because the performance is poo poo and they would run away immediately“

Thanks for releasing that desaster, Chris

Spiderdrake posted:

It feels like anyone in the industry in all honesty should avoid it. There's a bit of a bubble that extends to here, but outside of the bubble I do not encounter many gamers who have even heard of star citizen. It's a niche product with already better versions of the product dominating that niche. Inside the bubble, there's a pretty slim number of viewers and shills, all of which make for rather repulsive discussions. There's no money in it, all the money is going to CIG, so you get lovely comments on youtube and nothing else.

Also if you at all discuss consumer treatment by the industry, watching Roberts shovel shoddily put together 7 fps poo poo and be rewarded with millions off people buying jpegs has to be a certain kind of soul crushing.

Cao Ni Ma posted:

I think that the campaign was mostly well received. Most people considered it one of the better ones in the franchise. Its the multiplayer that was just as dreary as always

trucutru posted:

Well, his whole shtick is that he speaks about abusive practices in game development, and he's well-aware of star citizen, so I have always wondered why has he decided to ignore this particular piece of abusive-as-hell project.

Mne nravitsya posted:

my right hand is a blur.

Sarsapariller posted:

My uncle who works at CIG said that Dr. Smart and Chris Roberts were in the closet making babies and he saw one of the babies and the baby looked at him

Alchenar posted:

There's some major revisionist history going on over IW in this thread.

Sarsapariller posted:

Performance Theory posted:

Performance, i.: Where is the PC Master Race?

A core tenant of the PC Master Race is the increased performance provided by the vastly more powerful hardware of a fully decked out PC when compared to consoles. A mere thirty frames per second is seen as simply unacceptable to the discerning palettes of the gaming elite, where sixty is the norm, and if you have a capable monitor and a truly outrageous GPU setup, your eyeballs can drink in one hundred and twenty beautiful frames of buttery smooth action.

A core tenant of Star Citizen's advertising was appealing to this facet of the PC master race, remaining unshackled by the plebeian hardware of consoles and leaving the sky as the limit for the smooth, buttery goodness of a game that utilized more fully the current - and future - maximum potential of gaming PC hardware.

And yet Star Citizen is currently a slideshow that frequently dips into the single digits. This is unacceptable for even a console title, of which there are many TCRs (Technical Certification Requirements, i.e., "the console maker won't let you ship your game on it if it fails these") regarding performance. That is why, for all of Reddit's angst, you very rarely see a console game that actually has noticeably poor performance. As has been consistently demonstrated over the past decades, 30 FPS is simply Good Enough.

But Star Citizen doesn't even have that. And it is unlikely to have that in the near term. And it is unlikely to remain sustainable as ever more features are bolted on. Performance is, ultimately, one of the final litmus tests by which a game's programming is judged. It is the sum total of all of its parts, working in concert, in real time, on a player's hardware. Performance is unlike any other aspect of game development, in that it can almost never be simply patched after the fact. It must be explicitly designed for from the start, as no matter how many people you assign to the task of "performance is bad," eventually, they stop being able to continue to claw back the framerate in 1 and 2 FPS increments through additional work.

Why is this? Join me for a guided journey of the dark and mystical land of low-level performance optimization in video games; a glimpse behind the curtain of what outwardly appears to be nothing short of wizardry with extra steps.

Performance, ii.: Design philosophy.

Every project is different, as is the way that performance impacts it. Some projects never need to worry about performance, such as the common meme of the student's simple Python script that processes some small amount of data, perhaps putting it into an excel spreadsheet, which is sufficiently small that it simply doesn't matter how poorly optimized it is. So long as the data is good, no one cares if it takes one second or three seconds to execute.

Some projects, such as games, live and die by performance, as no one will play a game that is a literal slideshow. Therefore, the game's architecture must be designed properly from the very beginning, as perhaps a mere 25% of performance optimization is the result of clever programming tricks, with the remaining 75% being the result of good design.

The house analogy has constantly been used to describe this phenomenon. And with good reason, as it is quite accurate. The design of code is tricky business, as it is something invisible to players. Anyone can see if the jackets have enough fidelity or not, and anyone can see whether the fluid dynamics in the drink glass provide sufficient immersion for the eventual drink mixing minigame. Conversely, only a tiny fraction of individuals, who are both highly technical and highly experienced, will be able to see whether or not code design is proper.

But blah blah foundation important, blah blah CIG is designing wallpaper first, blah. You probably already know all of that so I won't bore you by going over it once more.

Performance is special because, with enough time and effort, you can usually get Cool New Feature working no matter how poor the foundation is. It may take a whole lot longer than it needed to, but it will eventually function to some degree. Not so with performance optimization. That is where all of those poor choices begin to cross the threshold from "this just takes much longer to do than it should" to "this is physically impossible to do without rewriting half of the engine".

<.....>

"But it's an alphaaaaaa," come the cries of the faithful. No. The entire point of this is to expound upon the fact that these issues are ones which should never be encountered by the time a game gets into the alpha stage. These are things that must be executed properly before many of the game's systems are in place.

And by all accounts, the people at CIG who were experienced enough to properly guide the design left long ago, leaving what seem to be primarily inexperienced members to attempt to do so. I have nothing bad to say about those working in the trenches, as it is not their fault at all. If someone gets told to implement volumetric fog, and they do so, then that should in fact be celebrated - it is the management who decided to mis-allocate the resources to prioritize volumetric fog over more important tasks which should earn one's ire. Similarly, I have nothing but respect for those who still attempt to fix and improve the code's design even if they are unqualified to do so - I trust that they are in fact trying their best. These criticisms should be, once more, directed to those who mismanaged the project and put them in that position to begin with.

Performance, part iii.: Case study of poor design.

"For 3.0, the team will continue to look into the major performance offenders on the client with a lot of people on the server. One issue is with animation updates of attachments, specifically doors. Moreover, we have a big issue with badly spawned ships for interdiction that causes significant but unnecessary physics that delays the execution of the next frame on the main threads (and thus severely impacts frame rate). Moreover, the team’s going to build a thread local queue to push physics commands in order to avoid synchronization cost caused by the large amount of physics parameter update calls (in order to ultimately get down to reasonable numbers again). In addition to that, the engineers are trying to reduce the amount of items / entities / components and their updates that contribute to the high baseline cost on the client."

Oh boy. Let us dissect this technical piece of information line by line:

"One issue is with animation updates of attachments, specifically doors."
Doors!
Doors are a prime example of something which has been needlessly over-engineered. Before, I have heard stories of ridiculous things such as fixing an issue with moving through doorways by placing invisible physics objects inside of them rather than properly fixing their collision bounds. While not directly related to performance, this is the kind of thing that we call a 'kludge' - a quick and dirty fix that is not considered proper. It's like fixing a rotting stairway by covering it up with pieces of plywood. It might work in the short term and allow you to continue traversing the stairway with less risk of putting your foot through a weak piece of wood as you take a step, but it is certainly not a proper solution. Because next month, you might want to add a ramp to your stairway to allow access to those in wheelchairs, but now you not only have to work around the rotting steps, but the plywood you dumped over it to cover it up. Similiarly, the next time they want to change how doors work in game - perhaps they need a new type of sliding door, for example - they now have to work around the kludge they left in there from last time, assuming that anyone even remembers it in the first place.

The fact that there are evidently performance implications regarding doors should therefore be of little surprise to anyone. It having to do with animation is quite odd, and without knowing more, it is difficult for me to speculate on the specifics, as animation is usually a very, very inexpensive operation, performance-wise.

"Moreover, we have a big issue with badly spawned ships for interdiction that causes significant but unnecessary physics that delays the execution of the next frame on the main threads (and thus severely impacts frame rate)."

Here we go, a nice meaty subject. There are two parts to this:

1) Objects with physics that we don't need.
2) Multithreading delays.

The first issue is quite clear cut: due to the eldritch horrors of their frankencodebase, they're performing physics calculations on objects that do not need them. This is indicative of those systemic issues I've just described, as this sort of thing should be very, very easy to trace back to where it is occurring. Since it's not, as it should theoretically be a five minute fix in a properly designed engine, their ship spawning system can be assumed to be a rats nest of different things interacting rather than one neat, orderly, centralized thing which handles all of the necessary spawning logic.

The second simply means that the physics thread has too much work to do, which is causing the game to run slowly. It sounds simple - "hey, we just need to do less physics work, and then we'll be safely back in the 120+ FPS PC Master Race, right?!". Sadly, it is not. In fact, it describes something really, really bad for Star Citizen.

In most game engines, physics (all those math-y calculations that the computer uses to figure out whether your commando is properly standing on top of a ramp or T-posing his way into the great unknown, for example) and rendering (drawing all of those fidelitious layers of jackets, for example) happen separately. This is very important to maintaining PC Master Race membership, because it means that if too many physics things happen at once, the framerate will not drop. In a properly designed engine, you could have ten thousand commandos running into each other at once, and the game would still remain at the same framerate - the simulation would simply slow down, and everything would move in slow motion.

An easy example of this is EVE Online - there can be huge engagements that crawl along, with actions that normally take seconds taking hours, but during it all, you can still move through the game at a high framerate. This is because the simulation and rendering are decoupled, and the simulation taking longer does not slow down the rendering.

In SC, as they just described, this is not the case. This is Very, Very, Bad. If EVE Online were designed in the same way, then those enormous engagements would be completely unplayable, as the game could only render a new frame after it was done doing the simulation calculations that took an hour to do. In the meantime, the game would appear to hang, and be completely unresponsive - for all you know, it crashed. This is exactly what is currently going on in SC, just at a much smaller scale. The design is neither scalable nor sustainable, and is a really bad thing as it only works if the physics will never, ever be doing enough that it slows down rendering. Assuming that networking works perfectly tomorrow, how exactly are those capital ship battles going to play out, with this limitation in mind?

"Moreover, the team’s going to build a thread local queue to push physics commands in order to avoid synchronization cost caused by the large amount of physics parameter update calls (in order to ultimately get down to reasonable numbers again)."

This is the sentence that actually prompted me to begin writing this series, as it struck fear into my very soul.

The system they describe is fundamentally changing the manner in which commands are issued to other objects in code - in this case, related to physics.

Most code written for games is directly invoked:

Object.DoThing();

Object Does the Thing as soon as this is called. Pretty simple. But let's say that you need to Do A Thing on a different thread, such as physics. You now need to worry about how to properly synchronize data between those different threads, because in any multithreaded system, code running on one thread does not know about anything running on a different thread unless you specifically and carefully make them aware of each other.

One way of doing this is to block both threads. This works, and is easy to implement:

BlockPhysicsThread();
Object.DoPhysicsThing();
UnblockPhysicsThread();

Remember Spinlock? It's the same thing. And remember how it tanks performance? Yeah, same thing.

A queue is another programming construct which attempts to solve this issue, and looks like this:

Object.DoPhysicsThingLater();

Internally, this creates a little note that says "hey, mr. physics thread sir, next time you get a chance, could you Do This Thing? kthxbai". Simple and elegant, and how many games handle this type of situation.

The problem is that it has to be designed for in advance, or an unending amount of subtle bugs will be created. What happens in this situation?

Object.DoPhysicsThingLater();
Object.HeyWhatIsOurPhysicsThingDoingRightNow();

Here, the second function call attempts to read the current state of the object. Under the prior system, you could safely assume that DoPhysicsThing() has completed. Maybe the results of DoPhysicsThing() are integral to the second call. If they are, you are now completely screwed, because you have no way of knowing whether or not DoPhysicsThing() has been run on the separate thread or not - due to the nature of multithreading, maybe it did, maybe it didn't. You now have to write even more code to check on that, or you have to write even more code to make the second function a message as well, which in turn might create even more issues down the line if you had a third function that relied upon the results of the first and/or second functions... And so on, endlessly, with absolutely no upper limit to the total amount of complexity that has been introduced.

Remember, all of these systems work with each other and talk with each other. All of those other systems are expecting one thing - that calls are immediately executed. Now, with the system they propose, all of those other systems have to take into consideration the fact that they might not be immediately executed.

If this system was properly designed in the first place, it would be no big deal at all - all other code would have been written with that in mind. But now, they have to go back and change it in order to prevent even more bugs - or worse, outright crashes - from being created as a result.

"In addition to that, the engineers are trying to reduce the amount of items / entities / components and their updates that contribute to the high baseline cost on the client."

This is the same as previously covered - things are being updated that don't need to be. Let's explore that issue on a deeper level. A performance optimization that I have heard much about of late is distance-based culling - which is, quite simply, "don't update things that are too far away." That sounds pretty simple, right? It is. In fact, it should theoretically take about two lines of code:

if(Distance(Player, OtherThing) < WayOverThere)
{
UpdateOtherThing();
}

Or at least, it should be that simple if the engine was designed for it in the first place. Since 1) it is clearly taking them months and months to do this instead of about twenty seconds, and 2) this technique is one of the simplest and most cost-effective optimizations that almost every game ever written ends up using it in some way or another, we can surmise that there is something causing a problem. What could that be?

There are a multitude of reasons as to why you can't simply bolt this on after the fact. Many of them stem from the same problem as in multithreading: there's a lot of other code that expects the code you're trying to optimize to behave one way, and changing its behavior as part of a performance optimization can introduce more bugs and crashes, or even become impossible without also changing all of the other code in some way.

Maybe you have a seemingly innocent bit of code tucked away somewhere that checks something innocuous, such as whether a chariot's lights are turned off or on so the renderer knows whether it needs to prepare some extra lighting calculations for them or not. Maybe that piece of code was hastily thrown in every ship's Update() function, because some guy came barging into your office and demanded that the lights look extra fidelitious in the next check-in, and you wanted to go home because it was already 11 PM and sleep started to look more appealing than bulletproof code design. We've all been there. Maybe this was lost in the shuffle, hidden in a tiny note in your source control commit message that you promised yourself you would fix later. Maybe later never came because someone barged into your office the next morning and insisted that you work on important logic for AI commandos to recognize mopping as their highest purpose in life.

And now, months later, someone else is desperately trying to improve performance at 10:30 PM for a big demo the next day, and tries to add in culling logic that stops calling Update() on ships that are far away. And when he compiles and runs this, he now finds that the lighting is wrong on all of the chariot's lights. Stymied, he now has to trace through all of the code that could potentially impact that. If he's lucky enough to eventually find out that tucked away UpdateStupidLightsSoICanGoHomePlz() function in a bad place, now he has to decide how to fix it. Does he properly refactor the light checking to work on the renderer's side, staying until 1 AM? Or does he pull that bit of code out and plop it into the messaging system he's been writing all day, kicking the can ever further down the road just so that he can get home at a reasonable hour such as midnight? Decisions, decisions...


This is very complex, abstract stuff, and even professionals have trouble getting it right on the first try. Software is somewhat unique in that respect, as in most other fields involving complex technical endeavors, such as building a huge skyscraper, you have the benefit of being able to touch and see it. Building a tower makes logical sense. We instinctively know how gravity works, and that a pyramid is a very strong structure and an upside-down pyramid is probably not.

But in software, we do not have that luxury. It's all abstract concepts. And while we can make fancy flow charts attempting to show relationships between pieces of code, it can often feel like the flatland problem - that we're mere 2D beings helplessly flailing about, trying to visualize 3D concepts that our poor brains simply weren't designed to handle. Software development is all about taking those abstract concepts and solidifying them into functional code.

And that code is, by design, very brittle. If everyone agrees that we're making a pyramid, and then halfway through stacking blocks to build it, someone waves their hands and insists that we're actually making an upside-down pyramid, it's probably going to fall over. And when software is poorly designed, on any level, that is exactly what happens.

Performance optimization has the worst of all worlds because it is bound by hard technical limitations. Time and money to add new features may indeed be infinite, but at the end of the day, the CPU cycles on the player's computer are very much finite.

El Grillo posted:

Also also, where are all the black people and women. It's 900 years in the future and all flight deck crew and navy pilots are exclusively white men.

Combat Theory posted:

A friend who would like to stay anonymous felt compelled to write an effortpost about the performance situation in star citizen 3.0 and CIGs future outlook.

trucutru posted:

Well, his whole shtick is that he speaks about abusive practices in game development, and he's well-aware of star citizen, so I have always wondered why has he decided to ignore this particular piece of abusive-as-hell project.

Breetai posted:

He's gone on the record as saying that there's just so much stuff surrounding Star Citizen that to do it justice he would need to either spend weeks researching it or pay someone to do so. He mentioned it in the Wing Commander episode of the Spinoff Doctors podcast.

SelenicMartian posted:

Today, kid, I'll teach you the honourable art of commando tracking.
See, kid, a commando is always on the move, because the places where they come to life - or 'spawn' as the folks in the biz call it - are so friggin far from the places where they spend most of their lives, and die, that many commandologists argue that the main purpose of a commando's existence is to be in transit. I'm not entirely sold on this, kid, but I know is that if your regular commando survives spawning, he gets on his way like salmon migrating to the supermarket shelves. I'm saying 'he,' because commandos are all males, inexplicably. It's something to do with penises, they say.
Now in this here 'verse, kid, a commando faces many troubles. One of them is vicious asteroids popping into existence whenever a commando goes, like those dry pellets a goat leaves. Think of commandos as bald goats in space.
We track these goats by them's pellets. Here's a good steady trail, kid. Very regular, that shows a steady framerate of about... seven. That's someone with money to burn. Most likely, a streamer. Don't make that face, not all of them smell.
Now, kid, we load Star Citizen streams on the ol' tablet, and check 'em. I don't like staying and watching too long, so as not to get those guys excited over a 25% increase in their viewership.
There, see, that's badnewsbaron that keeps running face-first into rocks just like our trail here. Now, going by the light on those rocks in his stream, I'd say he's going thataway, towards Laymar, or Daycar, or whatever it was that they call that map.
Let's go set a surprise for him. Bet, he won't be expecting anyone to enter his field of view and drop his fps to three, eh? Kid? Kid! Oh, goshdarnit, he's crashed aga

El Grillo posted:

Also also, where are all the black people and women. It's 900 years in the future and all flight deck crew and navy pilots are exclusively white men.
e: wait from that clip from a few pages back, there is more diversity in loving Call of Duty than in this game 0_0

Cao Ni Ma posted:

I wonder if the guy that did the move/jump/shoot latency tests will do one for the 3.0