Game Discussions Star Citizen Discussion Thread v12

CIG are not inventing DX12 they were creating an alternative to DX11 because it was too limited for what they wanted to do, CIG are not the only ones who felt like this, the CPU - GPU vendor AMD created a brand new Open Source API in 2013 to replace DX11 for the same reason, it was called Mantle, it was later given to the Khronos group (creators of OpenGL) who renamed it "Vulkan"

AMD did partner with a bunch of game developers in 2013 to promote Mantle, DICE was one, CIG was another.

Source: https://youtu.be/XD9_L5o4mhQ?t=610


My own side by side video of DX11 on the left vs Mantle (Now Vulkan) on the right. FPS top right both sides.

Source: https://www.youtube.com/watch?v=vPxyVesz2Ps

Star Citizens main render thread has actually been largely (tho not entirely) solved through their work with AMD. those of us who have been playing it for many years will remember in 2016 getting 30 FPS at port Olisar and we were glad to get that much, its where the whole "Star Citizen runs like dog poo" comes from, the performance and for a few years now in the same location is much better, despite Port Olisar actually being more complex than it was in those days.

Other areas such as large cities don't run great, but they just wouldn't be possible at all without that work.

There is more that can be done with a full Vulkan implementation to increase performance, not just for CPU Draw Calls but also the graphics render.
 
Last edited:
No, they've not been working on it for years lmao. Where are you getting that from? Looking into an API to maybe be used for your game is not working on it for years.
I actually agree, they haven't been working on it. Partly because they were hoping Amazon would do the heavy lifting and add support to Lumberyard for them, before LY was instead spun off into O3DE, but also because they've made such a pig's ear of "StarEngine" in the last decade that "refactoring" it for Vulkan in a a way that would actually benefit from it would mean rebuilding SC from the ground up.
 
That's just... very wrong. Culling isn't the only thing that makes a game perform bad or good. Even though they've added it EDO my FPS stayed pretty much the same, doomed!

Source: https://youtu.be/-E2MOyO6Nnk
I have no doubt, there are other things CIg are doing badly, as well. Thanks for clarifying.
FPS has improved a bit for me in EDO, since update 11. SC's performance has only gotten worse for me.
 
I have no doubt, there are other things CIg are doing badly, as well. Thanks for clarifying.
FPS has improved a bit for me in EDO, since update 11. SC's performance has only gotten worse for me.

Yeah, its offtopic, but performance has increased a little bit for me in EDO as well. And i think the lighting has improved a little bit (although that's subjective of course).
 
I have no doubt, there are other things CIg are doing badly, as well. Thanks for clarifying.
FPS has improved a bit for me in EDO, since update 11. SC's performance has only gotten worse for me.
Other things they're doing badly? CIG is really good at culling, even better than FDev.
 
No no no the product is released! Or is it! Or is it not.... Again 400 million over a decade is absolutely nothing! Warzone made a billion in the first week! It's not "normal" but, why should it be? Normal is boring!
Cope & Seethe!

The fact you could type this and then accuse other people of a cope is just
carl-chef-kiss.gif
 
I have no doubt, there are other things CIg are doing badly, as well. Thanks for clarifying.
FPS has improved a bit for me in EDO, since update 11. SC's performance has only gotten worse for me.
For me it has improved, but the graphic quality has only decreased since the DLC release.
 
You will never see 1000 players in your local in Star Citizen, and here is why.

Source: https://www.youtube.com/watch?v=E1jwF8CPdkM

Oh god I love Ray.

He concludes his whole Server Meshing series by majoring on... client limitations (polygons yo ;)). And the physical capacities of existing assets (an old favourite of his).

And sure, he's not wrong. Those things are absolutely blockers to 1000+ player densities. But he's totally faffing around the edges of the issue, avoiding the Idris in the room...

Y'know... the networking stuff. The devs have plenty to say on how both player concentrations and dispersal are issues in that respect too. And that they don't have solutions nailed down either technically or via game design compensations:
  • Player concentrations:
    • "Clearly that is going to be a problem if we allow shards to have many more players than the 50 we have right now in our single-server “shards”. So, don’t expect player counts to increase much with the first version. That avoids the issue of a single server node becoming full before players get there since we’ll limit the maximum player count per shard based on the worst case."
    • "Without mechanics to prevent every single player going to the same location, a large mega shard will be very hard to achieve, especially on the client. For example, there could be a mechanic to temporarily close jump points to crowded locations, or create new layers for certain locations."
  • Player dispersal:
    • "Actually the worst case is if all the players decide to spread themselves out between all the locations assigned to a single server node. That way, the poor server will be trying to deal not only with all of the players but it will also need to have streamed in all of its locations. The obvious answer is to allow more servers per shard, so each server node has fewer locations it may need to stream in. However, because this is a static mesh and everything is fixed in advance, having more server nodes per shard also increases running costs."

Ray prefers to dreamcraft scenarios where numerous complementary XenoThreats happen in concert, rather than visit these dev thoughts with their blunt MVP 'blockade the fun zone' musings.

I wonder whose dream game is more likely to come true? :unsure:

---

Shouldn't be surprised though. After all Ray is the guy who managed to identify the unscalably recursive nature of the old Server Meshing design. And then conclude:

What I hope this really impresses you is that the full implementation of 'Dynamic Server Meshing' will be truly revolutionary both in terms of having a much more lively dynamic and densely populated world but also in something really never having been done before.

Rather than the more obvious conclusion of: "Holy crap, this is never going to work!" 😁

Even when he thinks he's speaking hard truths, Ray is still mainly laying on the honey ;)
 
Last edited:
or create new layers for certain locations.

Ah layers, you know we sometimes get put into "layers" in LOTRO, it says when the current area is seperated into multiple layers and has a little icon that looks like a stack of papers in the corner so you know while you may be in the same area as a friend you won't see them unless you both join a fellowship outside the area before entering so you get assigned to the same layer. Date of LOTRO release? 2007, yes 2007, and CIG are still talking about "layers".
 
Ah layers, you know we sometimes get put into "layers" in LOTRO, it says when the current area is seperated into multiple layers and has a little icon that looks like a stack of papers in the corner so you know while you may be in the same area as a friend you won't see them unless you both join a fellowship outside the area before entering so you get assigned to the same layer. Date of LOTRO release? 2007, yes 2007, and CIG are still talking about "layers".

Well it frightens uber-backers less than "instances" ;)
 
Depends on who actually believes this tosh

Ray strikes me as someone who is very much in earnest. A classic long-term fan, with an unrelated technical background, and lots of time and desire to fan-craft between the dots. The many, many dots, which make up the constellation of SC promises ;)

(And yes, I think he's being very daft too. Despite gargling a lot of the nuts and bolts of what they've said, he's mainly regurgitating dreams of his very own devising...)
 
Back
Top Bottom