• Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!

News Star Citizen wird 100 GB groß und ist 75 Mio. Dollar schwer

Das Thema "Drosselkom" ist doch schon lange vom Tisch....
 
Wirklich? Bei KD zb.: Überschreitet man 60GB so gibt's ne Drossel rein, wird zwar am nächsten Tag wieder aufgelöst, aber die Drosselgrenze wird für den Rest des Monats auf 10GB/Tag abgesenkt.
 
KD drosselt nur bei P2P. Normale Downloads sind weiterhin ohne Limit.
 
Korrekt und selbst P2P wird nicht immer gedrosselt. Es kommt halt aufs Netz an wohnt man auf dem Land wird bei P2P später gedrosselt als z.B. in einer Großsstadt.
 
zephram schrieb:
Jup ^^ War aber keine Kritik an dem Spiel, da überlege ich später zu kaufen, sondern an der kürzlich aufgekommenen Praxis hinterrücks Providerverträge abzuändern und "Flatrates" mit Begrenzungen zu versehen.
Das hat doch hier überhaupt und gar nichts verloren!
 
Wo sollen da denn "100gb nix" sein?
Egal wie riesig irgendeine Welt ist, es kommt auf die Anzahl, Größe und Kompression der Texturen an. 100 GB sind dafür meiner Meinung nach immer noch übertrieben und mehr PR als sinnvoll.
 
100GB hört sich erstmal verdammt viel an aber wenn man bedenkt das GTA V bereits 50GB benötigt und der Umfang deutlich geringer ausfällt als Star Citizen, dann sind 100GB angemessen. Desweiteren wird es noch eine weile dauern bis zum Offiziellen release und die spiele werden halt immer umfangreicher und benötigen daher auch viel Platz. In ein paar Jahren werden wir wahrscheinlich über die 100Gb nur lachen, so wie wir es heute tun mit den damaligen games die 20MB benötigten
 
S.Kara schrieb:
100 GB sind dafür meiner Meinung nach immer noch übertrieben und mehr PR als sinnvoll.

Diese "PR" wurde ja nicht von CIG gestreut. Die Presse hat einen der vielen, vielen Entwickler-Kommentare in den Foren hergenommen, um eine Story zu schreiben. Wie groß das Spiel tatsächlich zum Release sein wird, wissen auch die Entwickler nicht so genau, und es macht wenig Sinn, von der Größe anderer Spiele oder von der Größe der aktuellen Alpha-Version auf die Größe des finalen Spiels schließen zu wollen. Star Citizen besteht hauptsächlich aus leerem Raum, und die vier- bis fünfhundert Locations werden aus vergleichsweise kompakten Art-Asset-Bibliotheken gebaut (ähnlich wie die Level in "Diablo", nur eben sehr sehr viel detaillierter mit einer komplexen Wetter-Simulation, so dass jeder Ort einzigartig wirkt). Man kann also nicht argumentieren dass wenn schon "Arc-Corp" vielleicht 10 GB groß ist, das ganze Spiel einige hundert GB groß sein muss, denn aus den Art-Assets, mit denen "Arc-Corp" gebaut wurde, werden auch Dutzende weitere Locations gebaut.
 
Abstürze in 1.3 selbst fixen:

https://forums.robertsspaceindustries.com/discussion/comment/5878147

Wow, die neuen UIs und UI Animationen sehen klasse aus:

https://www.youtube.com/watch?v=aH81u8a8LJk

Die neuen Flybye-Sounds klingen auch deutlich besser:
https://www.youtube.com/watch?v=IdDINIHmyy4


2.0 Update:

https://robertsspaceindustries.com/comm-link/transmission/15045-Weekly-Development-Update

Also 2.0 wohl nächste oder übernächste Woche.

Monthly Report:

https://robertsspaceindustries.com/comm-link/transmission/15043-Monthly-Studio-Report

Scheinbar MISC Reliant Interieur:
SM-source-October.png


Reliant Takeoff:
https://www.youtube.com/watch?v=yqz6oaXM1uM

Klamottenladen:
Austin-Header-October.jpg


FX.gif


CPU Optimierung schrieb:
Hi Everyone, during the past month my main focus was on upping the quality of our two October releases: CitizenCon and SC 1.3.

During this time I worked on several optimizations, mostly around the ZoneSystem and CPU side object culling. Besides those, my second focus was on improving our thread backend to be more optimal for a PC only game.

CPU Performance has changed a lot over the recent years. In the old times, optimization was straight forward, there was only a single execution unit inside the CPU which did all the computations. In addition, there was an active GHz race, causing your code to automatically run faster by each new released CPU. Nowadays, the GHz of CPUs don’t change much anymore (single core performance still increases, but not on the level as it did before) and CPUs have gone “wide”, by providing more execution units.

This puts more burden on the programmer, as concurrent programming can be very complex. Since games have (by their nature) are very sequential execution; each frame first must update the state of the world, and then send this state to the GPU for rendering, It is hard to parallelize those in a way that actually gets you any performance gain. To do this, one of the most prominent models used for Games is a so called Main Thread. This Main Thread can be assumed to be like a regular game loop from the single core CPU times. The other cores are then used during a frame to help the Main Thread. If for example, we must update the state of 100 particle systems, we can distribute those over all CPU cores, to reduce the latency between beginning to update the state and being done with it. See the attached picture for a simplified example how this distribution helps.


To make all of this even more complex, the PC platform has to be more general than consoles. On consoles, the game normally has all the resources exclusively and on a known hardware set. On a PC, the game has to share the resources dynamically with an unknown number of processes running at the same time on an unknown hardware platform.

So to better utilize the PC platform, we switch the thread backend to batch oriented work stealing approach. By using this new model, we can massively reduce the cost to communicate with different threads as we only need to send a signal once per batch, and not once per entry. We also reduced the contention between the worker threads (important to scale to a higher number of CPUs), by utilizing work stealing so that threads communicate with each other instead of over a central queue.

This whole threading change was one of the major improvements for performance for 1.3, which also causes a higher CPU usage (which is good, as we now actually make use of the cores inside your CPU). Currently, nearly all legacy jobs are already ported over to this system, as well as all CPU side culling of the ZoneSystem. In the future this system will be used to parallelize parts of the game code, as well as a few additional things.

Wait, das war schon in 1.3? Stimmt da stiegen die fps im min Bereich schon etwas an aber insgesamt sind die fps immer noch total beschissen mit AMD Karte wegen zu hoher CPU Last + driver overhead
 
Zuletzt bearbeitet:
The 2.0 release stream is in lockdown now

Na, was sagen die Zweifler jetzt. :p

Server crash when spawning Multicrew ships ist ja im Wesentlichen ein Überbleibsel letzter Woche, und ansonsten ist die Liste praktisch leer.

Nightspider schrieb:

Das entfernt dann halt auch einige Optimierungen …

Nightspider schrieb:
Wait, das war schon in 1.3? Stimmt da stiegen die fps im min Bereich schon etwas an aber insgesamt sind die fps immer noch total beschissen mit AMD Karte wegen zu hoher CPU Last + driver overhead

Das ist nicht Driver Overhead, das ist schlicht fehlendes Threading, und dagegen kann CIG auch nicht viel machen außer Drawcalls zu entfernen (und damit die grafische Qualität vom Spiel zu senken)
Genau dafür kommt ja auch DX12 + Vulkan. Denn egal wie sehr das Spiel gethreaded ist, wenn der Main Thread immer noch das Rendering übernehmen muss und an Drawcalls erstickt, bringt es wenig, dort 1ms wegzuoptimieren. Wenn der Main Thread allerdings plötzlich deutlich weniger Arbeit hat, ist die eine ms auch deutlich mehr prozentual gesehen.
 
Das ist doch nur ein bisschen größer als andere spiele. Und nur ein bisschen billiger als Gta5. Was soll man davon halten?
 
Was man davon halten soll? Es gibt sehr, sehr viele Informationen zu dem Spiel und der laufenden Entwicklung. Da kann man sich selbst ein Bild machen ob das Spiel was für einen wird oder eher nicht.
 
Zurück
Oben