Skandal! Vertikale Synchronisierung bremst RW-Ladezeiten aus

Coole Sache Jungs, denn die minutenlange Laderei (und das ständige Advertising für die Swiss Nr.1 etwa bei KD) ist mühsam, wobei so richtig minutenlang dauerts bei Norhtern Europe und Hamburg-Bremen (sind natürlich beides große Strecken) sonst ist alles ziemlich erträglich ...

Einfach mal den Logmate benutzen und dort schauen was da so lange dauert. Ich hatte es glaub ich schon mal erwähnt. Fehlende Einträge in Blueprints oder überhaupt fehlendes Gezeugs halten den Ladevorgang enorm auf. Bei NE kommen die unzähligen Gleismarker dazu die alle als mögliche Ziele "gefetcht" werden für den Dispatcher. Bei KD sind das um die 500 aber das geht schnell. Schlimmer sind hunderte Objekte als "Scripted Scenery" die aber gar kein Script eingebunden haben. Da wird jedes einzelen angemosert und das dauert.

Hallo Leute,

also das mit den Ladezeiten hängt folgt zusammen - es gibt nur Möglichkeit a) oder b).

a - Synchrone Ressourceninitialisierung
Der RailWorks wird intern wohl so programmiert sein, dass er pro Frame nur eine bestimmte Anzahl von Objekten lädt. Dies würde zumindest erklären, warum unten der Wanderbalken ab und zu stehen bleibt. Diese Technik ist sehr alt und eine Pseudo-Assynchronität, um euch ein paralleles Laden vorzugaukeln. Sie ist der einfach zu programmieren.

b - Assynchrone Ressourceninitialisierung
Der Zähler für die interne Ressourcenanzahl muss für den Schreib- und Lesezustand "gelockt" (= gegen andere Zugriffe gesichert) werden. Wenn der Darstellungsprozess den Lock auslöst, können Loader die Liste nicht fortführen, da sie gegen anderen Zugriff gesperrt sind. Ist beim Rendern der VSync an, wartet Direct3D, bis es auf den Monitor das Bild darstellen darf. Ist er aus, erfolgt die Präsentation des Bildes unmittelbar. Dadurch wird der Lock unmittelbar aufgelöst und der Loader kann weiterarbeiten, da der Zähler nicht mehr benötigt wird.

Ich hoffe das ist jetzt nicht zu technisch.
Aber für Computereinsteiger: Willkommen in der Welt des praktischen Parallelismus.

Stellt sich noch die Frage warum macht man das so wenn man doch weis dass es von der Power der Grafikkarte abhängt? Die CPU als Taktmittel zu benutzen wäre doch viel sinnvoller und konstanter in der Abarbeitung.

Deswegen werden assynchrone Loader bevorzugt.

Der einzige Fehler wäre, den die Jungs bei einen assynchronen Loader machen würden, dass der Lock nicht für den Moment an dem die Zahl ausgelesen wird gilt, sondern über den ganzen Rendering-Prozess.

Aber: Wie wahrscheinlich ist es, dass deren Loader assynchron ist? Ich rate mal 10%. Weil der Aufwand ist riesig. Und das hat mich auch schon ganz schön gefordert. Nachtrag: Und die Daten müssen sowieso irgendwie von der HDD in den Memory, um dann in den VRAM zu gelangen - wenn überhaupt.