Danke für den Tipp.
Wobei es im Falle der unkomprimierten JPGs Quatsch ist, die gegen komprimierte zu tauschen (wenn man vom Plattenplatz mal absieht), denn Bilder landen eh unkomprimiert im Ram. (Deswegen funktionieren auch Dekromprimierungsbomben mit Bildern als "Sprengstoff")
Aber schön, dass durch den Tausch TIF>JPG Ram eingespart werden kann.
Eventuell kann man bei den JPGs durch Farbreduktion noch was rausholen.
aber es wäre natürlich schön, wenn DTG das gleich von Anfang an spartanisch gestaltet hätte.
DTG hätte sich mehr um den TS kümmern müssen, als mit dem TSW wieder was neues rauszubringen.
Das man "alte" Simulatoren erfolgreich auf 64bit umstellen kann, zeigen u.a. Laminar Research mit dem x-Plane11 oder Lockheed Martin mit dem P3d v4 aus dem Uralt Flusi FSX. Zudem konnten fast alle Addon Hersteller ihre Produkte ebenfalls an die neuen Versionen anpassen.
Nur DTG hat das nicht gebacken bekommen und wollte lieber was "neues" rausbringen, mit dem sie aber erfolgreich auf die Schnautze gefallen sind und sich davon auch nicht mehr erholen werden. Der TSW wird eine chronisch kränkelnde Angelegenheit bleiben.
Klar ist die RAM-Auslastung am Anfang sehr hoch aber es geht tatsächlich teilweise bis 800MB runter.
Das ist ziemlich kurios und kann nicht sein. Ein Bug im Taskmanager?
Der Ram-Verbrauch der Strecke sollte sich bei mehr als 3 GB einpendeln, aber nicht so weit absinken. Ich habe dafür keine Erklärung außer dass der TaskManager fehlerhaft arbeitet.
Nimm doch mal den ProzessExplorer von Sysinternals. Den gibt es bei Microsoft zum Download.
Doch, doch, dass der Taskmanager anzeigt, dass der TS-Prozess immer weniger Speicher belegt, ist nicht so ungewöhnlich. Das hängt damit zusammen, dass Windows unter bestimmten Bedingungen anfangen kann, den von einem TS-Prozess belegten Speicher zu komprimieren. In manchen Windows-Versionen wird der komprimierte Speicher dann im Taskmanager dem TS-Prozess abgezogen und den Pseudo-Prozess "Systemspeicher und komprimierter Speicher" zugeschlagen. Das ist aber natürlich Augenwischerei: Der Speicher ist natürlich weiterhin von TS alloziert, und es kommt zum Absturz, sobald die 4 GB-Grenze überschritten wird.
Da das recht verwirrend ist, hat Microsoft dieses Verhalten eigentlich auch mit dem Windows 10-Build 1607 wieder entfernt. Kann es sein, @floflo, dass du aktuelle Windows-Updates bei dir nicht installiert hast?
Allgemein kann ich auch nur empfehlen, nicht den Taskmanager zur Anzeige des belegten Prozessspeichers zu verwenden. Der Taskmanager ignoriert zum Beispiel den Teil des Speichers, der sich auf Standby-Pages befindet. Der TS fliegt auch generell erst, wie bei 32-bit-Anwendungen üblich, bei exakt 4 GB-Speichernutzung ab und nicht wie oft zu lesen bei 3,2 bis 3,5 GB-Nutzung. Der Taskmanager weist nur einen Teil des tatsächlich von einer Anwendung reservierten Speichers aus. Bessere Ergebnisse liefert zum Beispiel Sysinternals Process Explorer (dort die Spalte Virtual Bytes einblenden): Hier wird man viel deutlicher sehen, dass der TS bei 4 GB an seine Grenze stößt.
Da das recht verwirrend ist, hat Microsoft dieses Verhalten eigentlich auch mit dem Windows 10-Build 1607 wieder entfernt. Kann es sein, @floflo, dass du aktuelle Windows-Updates bei dir nicht installiert hast?
Hmm, ich habe hier Version 1709 mit Betriebssystembuild 16299.309, kannst du damit was anfangen? 
Das andere Programm werde ich mal ausprobieren.
Edit: So, Test gemacht mit Process Explorer. Tatsächlich läuft der Sim nun die gesamte Zeit etwa im Bereich 2,9GB - 3,9GB. Der Absturz kam auch diesmal wieder kurz vor Singen (ca. 1km vor Singen Landesgartenschau) und zwar bei einer Speicherauslastung von exakt 3,86388GB. Zwischendurch war es sogar mal noch ein klein bisschen mehr. So direkt kann es daran ja also nicht liegen....
So direkt kann es daran ja also nicht liegen....
Da zu hoffen das bei 3,86388GB noch Luft ist ..., da kommt dann ein neues Assets mit seinen Daten und will auch noch in den Speicher, geht aber nicht mehr, bumm.
(ca. 1km vor Singen Landesgartenschau)
Für die Freunde von KN-Vs und üppigem KI-Verkehr eine bekannte Absturzstelle
Ich fliege da auch oft raus, da dann ein großer Teil der Singener Objekte geladen wird.
Als Workaround immer kurz vorher speichern (Sichtweite Hohentwiel).
Beim neu Laden an der Stelle fehlen dann die Teile der ersten Streckenhälfte und meistens kommt man dann durch bis KN.
Für die Freunde von KN-Vs und üppigem KI-Verkehr eine bekannte Absturzstelle
Hmm, wo fängt üppig an? Ich habe den üblichen Personenverkehr drin (6-7 Züge) und dann noch ein paar Güterzüge (auch nochmal 5-7 Stück).
Als Workaround immer kurz vorher speichern (Sichtweite Hohentwiel).
Speichern ist ein bisschen blöd. Ich fahre mit dem IC-Steuerwagen der Expert-Line von vR und der hat die Angewohnheit alles wieder zurückzusetzen wenn man nach dem Speichern wieder reingeht. Heißt, ich muss den komplett neu aufrüsten, was aber während der Fahrt nicht geht und beim letzten Mal konnte ich nur mit Notbremse anhalten, was ordentlich Minuspunkte gibt.
Es kommt nicht darauf an, wieviel KI-Züge aufgegleist werden, sondern wieviele unterschiedliche Typen. Bei KI-Zügen Ram-sparende KI-Varianten verwenden. Generell haut dir hochwertiges Rollmaterial (zB von vr) schnell den Ram voll.
Deshalb verwende ich meistens nur TTB Material, auch wenn's ein bisschen laut ist. Beim TS hätte sich DTG einfach mehr Mühe geben müssen, und ein 64-bit Programm machen.
Das mit der Lautstärke bei TTB lässt sich korrigieren.
Ich such mal eben nach dem entsprechenden Post hier im Forum.
Edit:
Hier, bitteschön. Viel Spaß beim Basteln.
http://rail-sim.de/forum/index…?postID=347541#post347541
Hab ich vor längerer Zeit gemacht. Ich meine den Standsound der TRAXX-Loks.
Um das hier mal wieder auszugraben, damit auch alle verstehen was schleichende Züge sind:
