Factorio News - Friday Facts #326 - Partikelemitter Daten-Cache
Es gibt eine neue News zu dem Steam Game Factorio vom 20.12.2019. Folgendes hat dabei der Entwickler von Factorio veröffentlicht:
Lesen Ihr diesen Beitrag auf unserer Website.
Weitere Partikel-Optimierungen (Allaizn
)Rsedings jüngste Optimierungen des Partikelsystems (FFF-322) machten die Partikel viel leichter als zuvor, aber es hinterließ immer noch Partikel als ziemlich komplexe Bestien. Eine kurze Zusammenfassung der möglichen Aktionen, die ein Partikel während seines Updates durchführen kann:
Basisspiel und die meisten Mods verwenden keine besonders verrückten Trigger beim Erstellen von Partikeln - das Ziel ist es normalerweise, einfach einen Haufen kleiner animierter Texturen zu erzeugen und sie auf dem Bildschirm herumfliegen zu lassen (was etwas ironisch ist, was man normalerweise "Partikel" nennt). Eine Idee für weitere Optimierungen von Partikeln war daher, eine Art "einfache" Partikel zu schaffen, die nicht alle Arten von Triggern anwenden könnt, um sie in der Masse zu handhaben, was normalerweise schneller ist, als sie einzeln zu handhaben. Diese Massenhandhabung würde von einem Ding, das "Partikel-Emitter" genannt wird, erledigt werden, dessen ganze Aufgabe es ist, die einfachen Partikel, die es handhabt, zu erzeugen, zu aktualisieren, zu zeichnen und schließlich zu zerstören, mit der Idee, dass ein sterbender Beißer nicht hunderte von Partikeln erzeugen müsste, sondern nur einen/wenige Emitter.
Aber das ist nicht alles: einfache Teilchen sind nicht in der Lage, andere Spielzustände zu verändern, und würden daher nur aktualisiert werden, um ihre eigenen internen Werte - hauptsächlich ihre Position und Geschwindigkeit - zu erhalten. Eine kleine Physikübung später wurde die Idee geboren, die Teilchen überhaupt nicht zu aktualisieren - man kann ihre aktuelle Position doch aus ihrer Startposition berechnen! Noch besser: wenn die Partikel nie gerendert werden, dann macht es keinen Sinn, sie überhaupt erst zu erzeugen, also gibt es keinen Grund, das zu tun, bis der Emitter in Ziehweiteilung kommt - Millionen von Beißern, die in riesigen Blutfontänen abseits des Bildschirms sterben, würden also im Grunde genommen für Eure Frame- und Update-Zeit überhaupt keine Rolle spielen! https://cdn.factorio.com/assets/img/blog/fff-326-emitter.mp4A Visualisierung des Emitters in Aktion: der rote Kasten stellt den eigentlichen Bildschirm dar. Partikel, die von Emittern außerhalb des Schirmbereichs gelenkt werden, gibt es einfach nicht.
Dass die Partikel selbst keinen Einfluss auf den Spielstand haben dürfen, hat noch einen weiteren Vorteil: In einem Multiplayer-Spiel muss jeder Spieler nur die Partikel selbst erzeugen, die er sieht, und nicht die, die für jeden sichtbar sind. Dies legt auch nahe, nicht die Update-Funktion des Emitters zu verwenden, sondern stattdessen eine Draw-Funktion, die sogar noch mehr Vorteile bringt, da die Draw-Funktion während der Render-Vorbereitungsphase aufgerufen wird, die auf so vielen Threads läuft, wie Ihr ihr erlauben.
Doch all dies funktioniert nicht nur magisch korrekt, und es gibt Randfälle, die gehandhabt werden müssen. Zum Beispiel: Was passiert, wenn ein Emitter außerhalb des Bildschirms erzeugt wird und dann in Sichtdistanz kommt? Was passiert, wenn Ihr speichern und wieder laden? Was passiert, wenn man mit einem Mod-Set speichert und wieder lädt, das die Partikel nicht mehr definiert
hat? Es wäre sehr merkwürdig zu sehen, wie Euch Raketensilo in unzähligen Teilen explodiert, wie sie fliegen und in den Boden krachen - dann speichern und nachladen und alles noch einmal sehen, weil der Partikeleffekt neu gestartet wurde.
Der Umgang mit solchen Problemen nahm einige Zeit in Anspruch und erhöhte die interne Komplexität des Systems glücklicherweise nur geringfügig, so dass ich mich auf die Erweiterung der Funktionen konzentrieren konnte. Derzeit werden folgende Dinge unterstützt, um auf einem Emitter präsent zu sein:
)Die Startzeit des Spiels (Zeit, um das Hauptmenü zu erreichen) ist für uns genauso wichtig wie die Kompilierzeit (siehe FFF-206). Mit der Häufigkeit, mit der wir das Spiel kompilieren und starten, um Dinge zu testen, ist jedes zusätzliche bisschen Zeit, das wir mit dem Warten auf das Laden des Spiels verbringen, verschwendete Zeit. Es gibt 2 Hauptteile des Factorio-Startprozesses
In der Vergangenheit haben wir eine experimentelle Einstellung gemacht, die das Laden und Verarbeiten der Sprites zwischenspeichert, so dass wir nie darauf warten müssen, wenn sich
nichts um sie
herum geändert hat. Allerdings hatte das Spiel immer noch den Prozess alle der "Daten Bühne" jedes Mal, wenn das Spiel beginnen würde.
Während der normalen Entwicklung war das nicht wirklich ein Thema - es würde in den meisten Fällen in einem Bruchteil einer Sekunde geschehen. Doch mit dem Wachstum des Spiels hat sich auch die Menge der Dinge, die während der Datenphase verarbeitet werden, erhöht. Außerdem würde sich die Zeit für jede aktivierte Mod, die in dieser Phase etwas hat, ungefähr verdoppeln. Kürzlich begann ich mich zu fragen, was man braucht, um die gleiche Art von Cache-System zu erstellen, das wir für das Laden der Sprites für die Datenphase haben.
Da die Ergebnisse zwischen den Neustarts meist gleich sind, würde es bedeuten, dass die meiste Arbeit nicht gemacht werden muss - und schneller sein sollte. Nachdem ich etwa einen Tag lang daran gearbeitet hatte, hatte ich einen funktionierenden Prototyp; aber es war eigentlich nicht schneller, nur mit dem Basisspiel. Da ich
noch nicht aufhören wollte, verbrachte ich einige Zeit mit dem Profiler und schaffte es, ein paar Bereiche zu finden, die ich optimieren konnte und die Zeit, die die Cache-Logik verbrachte, um etwa die Hälfte zu
reduzieren. So hatte es schließlich einen gewissen Nutzen für das Basisspiel (wenn auch recht klein).
Was ich nicht erwartet hatte, war, wie sehr es sich für das modifizierte Gehäuse verbessern würde. Was in meinen Tests 25 Sekunden dauerte, dauerte mit der neuen Cache-Einstellung nur 4 Sekunden. Die Zeitersparnis wird noch besser, wenn die Anzahl der aktivierten Mods steigt. Die Einstellung ist immer noch standardmäßig deaktiviert, weil sie sehr experimentell ist, aber wenn sie stabil genug ist, könnt wir sie standardmäßig einschalten. Weihnachtsmods (Klonan
)Dies ist die letzte FFF vor Weihnachten, also dachte ich, wir würden einige der Mods feiern, die darauf abzielen, etwas Feiertagsstimmung im Spiel zu erzeugen.
verschneites Gelände ist einfach schön. In den Einstellungen des Kartengenerators könnt Ihr die Option
'Cold Climates' einschalten, so dass Eure ganze Welt nur ein gemütliches Winterwunderland ist.
müssen auch daran denken, die Liebe zu unseren Beißerfreunden zu teilen, dieser Mod lässt dich Geschenke weit und breit liefern und verschönert den Artillerie-Geschenk-Lieferwagen/Turm mit einer schönen roten und grünen Lackierung.
natürlich ist keine Winterfabrik komplett ohne einen schönen Weihnachtsbaum.
[previewyoutube=dljJijRJ6vQ;full][/previewyoutube
]Wir wünschen Euch ein frohes Weihnachtsfest und lassen Ihr uns wie immer in unserem Forum
wissen, was Ihr denken.
Weitere Partikel-Optimierungen (Allaizn
)Rsedings jüngste Optimierungen des Partikelsystems (FFF-322) machten die Partikel viel leichter als zuvor, aber es hinterließ immer noch Partikel als ziemlich komplexe Bestien. Eine kurze Zusammenfassung der möglichen Aktionen, die ein Partikel während seines Updates durchführen kann:
- Die eigene Position verschieben.
- Verschieben Ihr ihre Animation auf ein anderes Bild.
- Landen Ihr im Wasser und betätigen Ihr den Auslöser.
- Legen Ihr einen weiteren Trigger mit einer bestimmten Frequenz an.
- Entfernen Ihr sich von der Spielwelt, sobald ihre Lebenszeit endet.
Der PartikelemitterDas
Basisspiel und die meisten Mods verwenden keine besonders verrückten Trigger beim Erstellen von Partikeln - das Ziel ist es normalerweise, einfach einen Haufen kleiner animierter Texturen zu erzeugen und sie auf dem Bildschirm herumfliegen zu lassen (was etwas ironisch ist, was man normalerweise "Partikel" nennt). Eine Idee für weitere Optimierungen von Partikeln war daher, eine Art "einfache" Partikel zu schaffen, die nicht alle Arten von Triggern anwenden könnt, um sie in der Masse zu handhaben, was normalerweise schneller ist, als sie einzeln zu handhaben. Diese Massenhandhabung würde von einem Ding, das "Partikel-Emitter" genannt wird, erledigt werden, dessen ganze Aufgabe es ist, die einfachen Partikel, die es handhabt, zu erzeugen, zu aktualisieren, zu zeichnen und schließlich zu zerstören, mit der Idee, dass ein sterbender Beißer nicht hunderte von Partikeln erzeugen müsste, sondern nur einen/wenige Emitter.
Aber das ist nicht alles: einfache Teilchen sind nicht in der Lage, andere Spielzustände zu verändern, und würden daher nur aktualisiert werden, um ihre eigenen internen Werte - hauptsächlich ihre Position und Geschwindigkeit - zu erhalten. Eine kleine Physikübung später wurde die Idee geboren, die Teilchen überhaupt nicht zu aktualisieren - man kann ihre aktuelle Position doch aus ihrer Startposition berechnen! Noch besser: wenn die Partikel nie gerendert werden, dann macht es keinen Sinn, sie überhaupt erst zu erzeugen, also gibt es keinen Grund, das zu tun, bis der Emitter in Ziehweiteilung kommt - Millionen von Beißern, die in riesigen Blutfontänen abseits des Bildschirms sterben, würden also im Grunde genommen für Eure Frame- und Update-Zeit überhaupt keine Rolle spielen! https://cdn.factorio.com/assets/img/blog/fff-326-emitter.mp4A Visualisierung des Emitters in Aktion: der rote Kasten stellt den eigentlichen Bildschirm dar. Partikel, die von Emittern außerhalb des Schirmbereichs gelenkt werden, gibt es einfach nicht.
Dass die Partikel selbst keinen Einfluss auf den Spielstand haben dürfen, hat noch einen weiteren Vorteil: In einem Multiplayer-Spiel muss jeder Spieler nur die Partikel selbst erzeugen, die er sieht, und nicht die, die für jeden sichtbar sind. Dies legt auch nahe, nicht die Update-Funktion des Emitters zu verwenden, sondern stattdessen eine Draw-Funktion, die sogar noch mehr Vorteile bringt, da die Draw-Funktion während der Render-Vorbereitungsphase aufgerufen wird, die auf so vielen Threads läuft, wie Ihr ihr erlauben.
Doch all dies funktioniert nicht nur magisch korrekt, und es gibt Randfälle, die gehandhabt werden müssen. Zum Beispiel: Was passiert, wenn ein Emitter außerhalb des Bildschirms erzeugt wird und dann in Sichtdistanz kommt? Was passiert, wenn Ihr speichern und wieder laden? Was passiert, wenn man mit einem Mod-Set speichert und wieder lädt, das die Partikel nicht mehr definiert
hat? Es wäre sehr merkwürdig zu sehen, wie Euch Raketensilo in unzähligen Teilen explodiert, wie sie fliegen und in den Boden krachen - dann speichern und nachladen und alles noch einmal sehen, weil der Partikeleffekt neu gestartet wurde.
Der Umgang mit solchen Problemen nahm einige Zeit in Anspruch und erhöhte die interne Komplexität des Systems glücklicherweise nur geringfügig, so dass ich mich auf die Erweiterung der Funktionen konzentrieren konnte. Derzeit werden folgende Dinge unterstützt, um auf einem Emitter präsent zu sein:
- Handhabung einfacher Partikel mit individuellen, zufälligen Startpositionen und Geschwindigkeiten.
- Handhabung einfacher Partikelströme über Normal- und Instant Tails wie in FFF-325 gezeigt.
- Handhabung einfacher Partikel mit einer Rauchfahne dahinter (FFF-325 hat einige Beispiele dafür, aber der Effekt war schon vorher vorhanden) .
- Handhabung einfacher Partikel, die auf den Boden aufschlagen, indem sie beim Auftreffen auf Wasser möglicherweise durch einen Wasserspritzer ersetzt werden.
- : Ihr könnt nur eine einzige Partikelart (und technisch bedingte Rauch- und Wasserspritzer) handhaben. Um eine Montagemaschine in Metallkleckse und Ölspritzer zerplatzen zu lassen, wären also zwei Emitter erforderlich.
- Die Partikel, die von einem Emitter gemanagt werden, könnt nicht zu weit vom Emitter wegfliegen (der sich selbst nie bewegen wird), denn wir müssen wissen, wie weit außerhalb der Ziehstrecke wir nach Emittern suchen, die ihre Partikel vielleicht rendern wollen.
)Die Startzeit des Spiels (Zeit, um das Hauptmenü zu erreichen) ist für uns genauso wichtig wie die Kompilierzeit (siehe FFF-206). Mit der Häufigkeit, mit der wir das Spiel kompilieren und starten, um Dinge zu testen, ist jedes zusätzliche bisschen Zeit, das wir mit dem Warten auf das Laden des Spiels verbringen, verschwendete Zeit. Es gibt 2 Hauptteile des Factorio-Startprozesses
- : Gehen Ihr über jede aktivierte Mod und sammeln Ihr die Daten des Prototyps, die sie definiert/generiert (die 'Datenphase').
- Lade und verarbeite die Sprites, die das Spiel benötigt, um zu laufen.
In der Vergangenheit haben wir eine experimentelle Einstellung gemacht, die das Laden und Verarbeiten der Sprites zwischenspeichert, so dass wir nie darauf warten müssen, wenn sich
nichts um sie
herum geändert hat. Allerdings hatte das Spiel immer noch den Prozess alle der "Daten Bühne" jedes Mal, wenn das Spiel beginnen würde.
Während der normalen Entwicklung war das nicht wirklich ein Thema - es würde in den meisten Fällen in einem Bruchteil einer Sekunde geschehen. Doch mit dem Wachstum des Spiels hat sich auch die Menge der Dinge, die während der Datenphase verarbeitet werden, erhöht. Außerdem würde sich die Zeit für jede aktivierte Mod, die in dieser Phase etwas hat, ungefähr verdoppeln. Kürzlich begann ich mich zu fragen, was man braucht, um die gleiche Art von Cache-System zu erstellen, das wir für das Laden der Sprites für die Datenphase haben.
Da die Ergebnisse zwischen den Neustarts meist gleich sind, würde es bedeuten, dass die meiste Arbeit nicht gemacht werden muss - und schneller sein sollte. Nachdem ich etwa einen Tag lang daran gearbeitet hatte, hatte ich einen funktionierenden Prototyp; aber es war eigentlich nicht schneller, nur mit dem Basisspiel. Da ich
noch nicht aufhören wollte, verbrachte ich einige Zeit mit dem Profiler und schaffte es, ein paar Bereiche zu finden, die ich optimieren konnte und die Zeit, die die Cache-Logik verbrachte, um etwa die Hälfte zu
reduzieren. So hatte es schließlich einen gewissen Nutzen für das Basisspiel (wenn auch recht klein).
Was ich nicht erwartet hatte, war, wie sehr es sich für das modifizierte Gehäuse verbessern würde. Was in meinen Tests 25 Sekunden dauerte, dauerte mit der neuen Cache-Einstellung nur 4 Sekunden. Die Zeitersparnis wird noch besser, wenn die Anzahl der aktivierten Mods steigt. Die Einstellung ist immer noch standardmäßig deaktiviert, weil sie sehr experimentell ist, aber wenn sie stabil genug ist, könnt wir sie standardmäßig einschalten. Weihnachtsmods (Klonan
)Dies ist die letzte FFF vor Weihnachten, also dachte ich, wir würden einige der Mods feiern, die darauf abzielen, etwas Feiertagsstimmung im Spiel zu erzeugen.
Alien-BiomeAlien-Biome
verschneites Gelände ist einfach schön. In den Einstellungen des Kartengenerators könnt Ihr die Option
'Cold Climates' einschalten, so dass Eure ganze Welt nur ein gemütliches Winterwunderland ist.
UrlaubsartillerieWir
müssen auch daran denken, die Liebe zu unseren Beißerfreunden zu teilen, dieser Mod lässt dich Geschenke weit und breit liefern und verschönert den Artillerie-Geschenk-Lieferwagen/Turm mit einer schönen roten und grünen Lackierung.
WeihnachtsbaumUnd
natürlich ist keine Winterfabrik komplett ohne einen schönen Weihnachtsbaum.
[previewyoutube=dljJijRJ6vQ;full][/previewyoutube
]Wir wünschen Euch ein frohes Weihnachtsfest und lassen Ihr uns wie immer in unserem Forum
wissen, was Ihr denken.
Die vollständige News zu Friday Facts #326 - Partikelemitter Daten-Cache findet ihr auf der Factorio Steam Seite