Beiträge von Graf Romanic

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


    Wir reden hier aber über VRAM...das ist was ganz anderes. Normal werden texturen entladen und geladen..aber nicht nur teilentladen und neue dazu. Kenne kein Spiel welches nur ansatzweise so viel VRAM benötigt..oder mit der Zeit immer mehr verbraucht.

    Ich kann mein VRAM auch mittels Container-Klassen verwalten. Verwaltungsobjekt im Hauptspeicher mittels Container erstellen und im Konstruktor des Verwaltungsobjekt den VRAM allokieren. Beim Freigeben des Verwaltungsobjekts wird der zugehörige VRAM-Bereich wieder deallokiert. Also nichts anderes sondern eine ganz normale Heransgehenweise. Irgendwo im Hauptspeicher muss ich halt die Handle für den Zugriff auf den allokierten VRAM ablegen.

    Habe den Beitrag eben noch upgedated. Das Spiel hat nen Memoryleak beim RAM und VRAM. Verbrauch schaukelt sich hoch bzw. fällt nicht wieder komplett ab, wenn Texturen von einer höheren Stufe auf eine kleinere gesetzt werden.

    Nö, dass Spiel nutzt die C++-Container und die halten den Memory vor anstatt ihn nach Nutzung wieder frei zu geben. Allokation und Deallokation von Speicher ist zu teuer in der Laufzeit, wenn man ihn in jedem Zyklus machen würde. Bei manchen Containern wäre das sogar ein ziemlicher Performance-Fresser.

    IntrepidKlasse Prozessor ist trotzdem nicht alles, sofern die Prozessor-Architektur nicht ausgenutzt wird weil Spielesoftware nicht für den Highend-Number-Cruncher entwickelt wird sondern für einen geläufigen am Markt verfügbaren Rechner. High-End-Prozessoren bringen nur Leistung wenn alles passt, Motherboard, Speicheranbindung, Software und das zu berechnende Problem. Das ist die wichtigste Lektion, wenn es um HPC geht.

    Du hast 12 Kerne und das Spiel nutzt nur maximal 4 Kerne. Nach der Windows-Berechnung der CPU-Last ist damit eh schon ein Grenze von maximal 33% erreicht. 100% Auslastung ist bei Parallelverarbeitung nicht zu erreichen, weil es immer Bereiche gibt, welche sich nicht parallelisieren lassen. Nächster limitierende Faktor ist dann der Speicherzugriff, du hast nur einen Adress- und Datenbus. TpF2 ist halt sehr speicherintensiv und das schlägt sich auch entsprechend nieder weil die vier Cores halt beim Speicherzugriff ausgebremst werden.

    Ich vermute einmal so ein Mod gibt es nicht, weil er auch nicht gerade sinnvoll ist, außer man möchte Konkurs gehen weil die neueren Fahrzeuge wegen höherer Geschwindigkeit und Ladekapzität am Ende alles blockieren.

    Den Fall hatte ich auch schon einmal und nach längeren Herumprobieren hatte ich heraus gefunden, dass der Umweg über das Zwischenlager zu groß war und dadurch kein Weg mehr gefunden werden konnte. Die Wegfindung hat da wohl einen oberen Faktor der sich aus der Länge der Luftlinie mulitpliziert mit einem Faktor für den maximalen Umweg gebildet wird. Wird der Faktor bei der Wegsuche überschritten, wird die Suche ohne Ergebnis abgebrochen (Typisch für Travelling-Sales-Man-Probleme).


    Ich glaube, ich hatte die gefundene Lösung in meinen damaligen Faden dazu nicht geschrieben.

    Direkt beim Einrichten kann man allerdings die Rate mit dem bereits zugewiesenden Fahrzeugen abschätzen und gegebenenfalls justieren. Nach einer Weile noch einmal nachschauen ob sich Staus an der Verladestelle gebildet haben, sofern man Warten auf Vollladen einer Fracht gewählt hat. Wenn das der Fall ist, dann sind noch eine paar Fahrzeuge wieder zu entfernen. Ist die Rate noch kleiner als die zu transportierende Menge muss noch einmal nachjustiert werden.

    Danke für das Feedback eis_os. Bei den Script fiel mir ein, dass es in dem Ordner auch die run.sh gibt über das ich nach Release auch den Fehler ermitteln konnte.


    Es sieht so aus, als ob ich mich dann doch einmal in der nächsten etwas freieren Zeit in das Thema Linux-Kernel selber bauen einfuchsen muss. Ich bin immer noch geschädigt davon, dass ich vor Jahren einmal selber einen IO-Treiber zur Zeitsynchronisation schreiben musste. Die ersten vier Byte einer Nachricht waren immer der Zeitstempel der Nachricht die sich auf das Ende des ersten Bytes bezieht. Ich war nur noch am Fluchen bis ich die Lösung des Problems in einer commit-Message zum Kernel gefunden habe....

    Ich konnte jetzt wieer auf den 390.144-oubuntu0.20.04.1 zurück, damit geht zwar das Suspend nicht, aber das ist nicht so negativ wie ein Treiber der hinten und vorne nicht funktioniert. Die Leistung des quelloffenen nouveau ist zwar schon miserabel, aber trotzdem besser als die vom 470er NVIDIA-Treiber. Nach den X-Settings wird die Karte auf die minimalste Frequenz runter getaktet. Da krankt noch mehr am Treiber. Vielleicht sollte ich ihn mal über die Konsole testweise installieren. Dann sehe ich wenigsten das Log vernünftig.


    Summa Summarum, ich kann erst einmal wieder TpF2 spielen und die nächste Grafikkarte wird AMD. Man könnte es auch mit den Worten von Torvald sagen "Fuck you NVIDIA". :P