Nightdive says Dark Forces has been ‚difficult to change‘ because LucasArts created its own version of multi-threading years before it became popular. (pcgamer)
Turok 3: Shadow of Oblivion Remastered, Verschoben auf den 30. November, ausser Nintendo Europa & Australien. (twitter)
Nintendo omg, sie winken jedes Indi Schrottspiel im Eshop durch aber wollen dann auf einen Fixpatch nicht warten, seltsam.
Update 15.11.: T3 bei Nintendo Europa und Australien aus Versehen veröffentlicht. (eurogamer)
Am 5. November twitterte KAISER über T3:
Nothing’s better than failing PS4 certification one week before a game is shipped because it crashes when loading a specific level, only on a PS4 Pro, only on 4k resolution, and only when a debugger is not attached. Yup, I sure do enjoy that. (Bug ist inzwischen gefixt)
Spannend, multi-threading in Dark Forces.
Zu welchem Zweck? Es gab zwar Mainboards mit mehreren CPU-Sockeln, für Workstations, Server etc; aber das hatte ja kein Heimanwender.
ID Software hatte zu Q3 zeiten eine Sun-Workstation mit 8 CPU’s in der Besenkammer, zum kompilieren (q3map).
Hier steht nichts darüber
https://en.wikipedia.org/wiki/Jedi_(game_engine)
>CPUs weren’t multicore back then, this wouldn’t have been to improve performance really, they’d use “green threads” to conveniently run code with waits in it, and it sounds like they had a task queue of green threads
https://sh.itjust.works/post/9099995
Nicht wegen Performance
Ein Computerprogramm unter MS-DOS ablaufend. Das Programm kann zu einer Zeit nur eine von drei Aktionen ausführen.
Sun OS implementiert User-Threads als sogenannte green threads um einem einfachen Prozess die asynchrone Ausführung mehrerer Aufgaben zu ermöglichen, beispielsweise playing a sound, repainting a window, oder auf ein Bedienerereignis zu reagieren wie die Anwahl des stop button.
https://de.wikipedia.org/wiki/Thread_(Informatik)
Vielleicht um eine Aktionen Limitierung aufzuheben. Aber merkt man das, ist es besser?
Oder vielleicht irgendeiner hatte grade was gelernt, wollte was ausprobieren etc.
Die Programmiersprache Python hat auch „Threads“, obwohl nur einer zur Zeit laufen kann pro Prozess (selbst auf modernen Maschinen).
Das ist dann eher eine Abstraktion, damit man so tun kann als würden mehrere Dinge gleichzeitig laufen, auch wenn sie in Wirklichkeit (da man nur einen CPU-Kern hat, oder nutzen kann) abwechselnd laufen.
Also z.B. kann ein Thread Daten von der Festplatte lesen, während ein anderer weiterhin Eingaben (Maus, Tastatur, …) entgegen nimmt und Frames rendert, und wieder ein anderer die aktuell abgespielten Sounds zusammenmixt.
Oder man könnte jedem Gegner nen eigenen Thread geben in dem er sein kleines Programm immer wieder abspult (checken ob er getroffen wurde, ob er Gegner „sehen“ oder „hören“ kann, darauf basierend irgendwo hinlaufen und -schießen) und an irgendnem Punkt sagt er „ich bin jetzt erstmal fertig, jemand anders darf rechnen“ („yield“) und schläft dann bis er wieder drankommt – und wenn er wieder drankommt, kann er genau da weitermachen wo er vorher war und seine ganzen lokalen Variablen usw sind noch da.
Ist das sinnvoll für ein DOS-Spiel? Glaub eher nicht.. und andere Spiele aus den 90ern sind ja auch ohne ausgekommen..
Nightdive scheint das ja ähnlich zu sehen „It is very heavily over-designed“ – dürfte also eher ein Fall von „irgendeiner hatte grade was gelernt, wollte was ausprobieren“ sein.
Ich schätze das ist schwer zu portieren, weil man nicht einfach diese Pseudo-Threads durch echte Threads ersetzen kann – denn dann laufen die wirklich gleichzeitig und es gibt Probleme wenn zwei (oder mehr) Threads gleichzeitig auf die selben Daten zugreifen wollen (insb. wenn mindestens einer diese verändert und nicht nur liest). Also brauchen sie wohl eine Green-Threads (aka Fiber) Implementierung die auf moderner Hardware läuft (oder müssen das alles neu schreiben). Soweit ich weiß gibt es da keine gängige plattformübergreifende Lösung, erst recht keine die auch Konsolen unterstützt.. deshalb wird das wohl ein bisschen schmerzhaft sein.