Performance Vergleich Konsolen-Update (9.3.2023)

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


  • Laut den Release Notes wurde im kommenden Spielupdate sowohl die Performance der Simulation als auch des Renderings verbessert. Ich wollte wissen, wieviel sich die Performance wirklich geändert hat. Dazu habe ich mithilfe von FPS Monitor die FPS und die Simulationsperformance gemessen.


    Ich habe 4 verschiedene Savegames getestet:

    1. Vanilla Spiel (mittel) mit nicht zu großen Städten, Blick auf Stadt
    2. Sehr große Desert Karte, geringe Baudichte, weiter Blick über die Karte
    3. Größenwahnsinnige Karte, Blick auf dichte Bebauung mit einigen Mods
    4. Savegame von Marcolino26 mit großen Städten (Vanilla Stadtgebäude) und hoher Simulationslast (27k Einwohner)


    VerticesBuildFPS (pause)FPS (laufend)
    Simulation (8x)
    Cmd für FPS Monitorfps.start(150)fps.start(2000,1)fps.start(300*8,8)
    Game16,6 Mio3504949 FPS44 FPS71%
    3521049 FPS44 FPS71%
    3523050 FPS45 FPS71%
    Game22,4 Mio3504947 FPS43 FPS61%
    3521045 FPS41 FPS60%
    3523045 FPS42 FPS61%
    Game38,3 Mio3504946 FPS43 FPS47%
    3521065 FPS58 FPS53%
    3523060 FPS55 FPS50%
    Game Marcolino12,6 Mio3504923 FPS23 FPS28%
    3521026 FPS27 FPS28,5%
    3523026 FPS26 FPS28,7%


    • Für die ersten beiden Savegames ist eine Performanceveränderung nicht wirklich erkennbar. Bei game2 deutet sich sogar eine minimale Verschlechterung an, was aber sehr nahe an der Messungenauigkeitsschwelle liegt.
    • Beim Savegame 3 mit größter Karte und Blick auf Szene mit einigen Mods zeigt sich eine deutliche Verbesserung der FPS und leichte Verbesserung der Simulation
    • Beim 4. Savegame sind die FPS minimal besser, während die Simulationsperformance praktisch gleich bleibt
    • Neben diesen statischen Messungen der Performance ist aber auch die Flüssigkeit beim Bewegen auf der Karte ("dynamische Grafikperformance") für das Spielerlebnis sehr wichtig. Das lässt sich nicht so einfach messen. Bei game1+2 war alles flüssig. Bei game3 (vmtl. voller Grafikspeicher) war mein subjektives Erlebnis allerdings, dass die auftretenden Ruckler in der neuen Spielversion etwas stärker und häufiger waren, auch nach mehrmaligem Überfliegen der Karte.

    Fazit:

    • Die Veränderungen der Performance hängen stark vom Savegame ab (Ausbau, Mods, Einwohneranzahl)
    • Im Allgemeinen profitieren besonders Savegames mit vielen Mods von einer FPS Zunahme bei konstanter Ansicht ("statische Grafikperformance")
    • Die Simulationsperformance hat sich leider nur marginal verbessert
    • Interessanterweise hat sich gerade für Vanilla die Performance weniger bis nicht verbessert, wo das doch der Fokus für die Konsolenvarianten sein sollte. Anhand der Draw Calls sieht man, dass sich die Vertices/Tris nicht erkennbar verringert haben. Viele Vanilla Modelle hätten eigentlich mal eine Optimierung der Lods gebraucht - anscheinend wurden wirklich nur die Fahrzeuge optimiert. Die Hecke (hedge_m) hat bei game1 sagenhafte 14%, bei game2 verbraucht eine einzelner Steintyp 177k vertices, obwohl höchstens Punkte sichtbar sind. Wie man am 4. savegame sieht, sind die Stadtgebäude immer noch ein FPS Killer.
    • Der Grafikspeicher hat sich laut Diagrammen zahlenmäßig verringert (was für die Konsolen wahrscheinlich nötig war). Als PC Spieler ist mir die Auslastung allerdings ziemlich egal, denn am Ende zählt nur wie flüssig das Spiel läuft. Daher befürchte ich dass die Speicheroptimierung leicht zu Lasten der dynamischen Grafikperformance (also Ruckler beim Bewegen der Karte) geht.

  • Du mist compression. Dieses sein sogenannte "Dependencies" und sind 'standard' packetten bei ein installation von o.a Linux-systemen und wirden nicht erkennt durch andere filesystems. Das is ein fehler bei crosscompiling das missen von dieses componenten wirdet binary 'flurb'. Dieses sind allen wirklich 'nicht benotigt' und werden door die compiler 'geskipt'


    Du kunt dieses manuell zufugen..

    Ab ein na hab erfahr ich kein last von 'stots' und 'lag' mehr ich die Terrain kwalität abhoch.





    Code
    Hrrr... этот 

    Ейн Ни`кла し :|

  • I dont quite understand your message...


    I had to compress the screenshots to jpg because only files <1MB are allowed here, unfortunately.


    The gpu timings are flickering very much and I know the FPS value there is not in line with the (correct) value of the steam overlay FPS. In the screenshots it is also lower than in the table because the debug windows have impact on the FPS.

  • Technisch gibt es diverse Änderungen im Spiel seit der letzten stabilen Release:

    - Bessere Kompressionsroutinen für Spielstände


    - Das ecs::component System ist kein lineares std::vector mehr für einzelne Komponenten mehr. Diese sind nun in Chunks aufgeteilt. Damit sollte das hinzufügen, ändern und entfernen von Komponentendaten bei Größenänderung schneller funktionieren... Sprich Spikes durch herumkopieren von Daten wird weniger...


    - std::unordered_map wurde für Metadaten in parallel hash map geändert.

    Dieses braucht weniger Arbeitsspeicher, ist schneller beim Einfügen von Daten:

    Siehe dazu https://greg7mdp.github.io/parallel-hashmap/, d.h. das Einlesen der Modell Daten wird schneller gehen.


    Zum Thema CommonAPI2:

    -Das UI Overlay benötigt eine Kopie des Framebuffers, d.h mit CommonAPI2 gibt es immer mindestens eine komplette Kopie des fertigen Ergebnis. Dieses sollte keinen Einfluss auf den Simulationsthread haben.


    Mit newstreets werden Straßenmeshs bei erstmaliger Erstellung nicht parallel erstellt, da ich leider benötige Statusdaten nur global halten kann.(Ich hab in gewissen Routinen keinen Zugriff sonst auf die Daten)


    Mit newevents gibt es im Simulationsthreads neue events (Stationsbau), die auch ein Locking des GameScriptRep benötigt. Dies ist ähnlich der Missionscallbacks und sollten daher weniger ins Gewicht fallen. In Zukunft werden weitere Events dazu kommen. Jeweils wenn ein Linien Fahrzeug sein Ziel erreicht, dauert aber noch.

  • VacuumTube Machst du die Leitungsmessung nur in der Darstellung die du auch in den Bildern zeigst. Wenn ich die Optimierungen in der Change-History genauer anschaue denke ich, dass sie in der gewählten Perspektive keine großen Auswirkungen haben. Die sollten erst beim Hereinzoomen zum Tragen kommen.

  • Dass Ladezeiten und Savegamedateigröße verbessert wurden habe ich gelesen, aber das war für mich nicht wichtig. Ladezeiten sind kein Problem mehr seit ich eine NVME SSD hab. Der Fokus des Tests war auf die reine Performance im laufenden Spiel.


    Ich wollte ein paar unterschiedliche Szenen testen (Blick über Karte, auf Stadt, auf mit Mods bebauten Bahnhof), da die GPU meist in diesen Ansichten viel zu tun hat. Wenn man nah ranzoomt, wo nur wenige Objekte sind, sind die FPS meist kein Problem.

  • I dont quite understand your message...


    I had to compress the screenshots to jpg because only files <1MB are allowed here, unfortunately.


    The gpu timings are flickering very much and I know the FPS value there is not in line with the (correct) value of the steam overlay FPS. In the screenshots it is also lower than in the table because the debug windows have impact on the FPS.


    This is regarding compression of datafiles and texture formats that are enhanced.


    They are missing essential systemfiles for third party projects to work with the same Coder's paradigm. One of them is a port for Libjpeg. Some systems also require "MingW64" compiler to be added or included with LLVM to function properly. (Getting unstable results due to binary 'blob' in crosscompilation). This is a compiler error because at crosscompilation these will just get 'skipped over' and are not properly flagged as a dependency but are included in the License file. There on you will be able to make a diagram of dependencies.

    So they require you to manually include the software by adding it to the root of the package.

    They either went missing or did not get included while distributing the package but they do exist on the developers distro. I had this aswell but i no longer possess pre- and afterwards. Where the timing of the Terrain texture's and "Model Opaque" where beyond 22000ms after i included xxHsum and LZ4 *I still do not recommend compiling on the newer systems without having proper backups due to a formatting error so get precompiled binaries and libraries and include them in TF2 root" resolves any "Results non-available" except for 'one missing file'. This one i could not guess exactly.


    This greatly improved my gameplay and i am able to game on Megolamania with my recently cross-fired AMD R9 200 (Club 3D RoyalAce 9790. I saw great 'rendering' improvement in the distance but it is by not enough for the game. Most game still do not get up to that amount of VRAM unless it is a leak. The SDL SDK is designed for applications at 8 gigabyte RAM and 1024MB VRAM.


    Considering due to grains and the texture format of the 'terrain' it should not be '4096MB' for all the groundtexture's at maximum. Even with a High-DPI display this is not possible. This is invisible towards the human eye.
    Some of these files might be skipped on by other parties such as the clouds distributing and or might be skipped on by other 'virus protection'. I do not know this.


    And there is no determining what if because certainly this package has been made on a platform for "Multiplatform" but was originally created for another platform so expect some trouble conversing binary executable's. They are uninterpretable towards each other like germans and dutch but they speak the same language. So stack 0x8fe becomes ?¿¿ /? but is a link towards a .so file.

    So this generates a typical "Whitespace" error everytime it is 'missing something' it does not recognise. You want to check that.


    Ейн Ни`кла し :|

    Einmal editiert, zuletzt von OurGreatReader ()

  • Was die Ruckler angeht: Bei größenwahnsinnigen Maps mit aktiviertem NEP (oder erhöhter Renderdistanz) wird das besonders deutlich. Das war früher einfach flüssiger.


    https://steamcommunity.com/gro…ns/7/3788128618784317059/

  • Sorry to repeat, but you post about SDL Mingw seams to be generated by ChatGPT? Your posts make no sense. TPF2 Windows you are using is compiled with Microsoft Visual C++. You would get incompatible binary code if you use Mingw64. There is no cap of VRAM imposed by SDL. SDL is used for Input and Window Interaction (GDI). You get a a vulkan context or opengl context, your driver tells the max amount of vram it can handle.


    VacuumTube


    Es könnte sein das UG nun viel schneller Texturen die nicht im Bild sind direkt aus den Speicher wirft, da beim verschieben dann ne Tonne Texturen geladen werden müssen, kann das Leistung kosten.. Ggf. kannst du über das UG Debug Fenster beobachten?

  • Sorry i do not use ChatGPT i translate everything myself and i look it up myself.

    Do not use translators..... (sehr slechte ubersetzung oder vertalung)


    ------------------------


    "Mingw-w64 is an advancement of the original mingw.org project, created to support the GCC compiler on Windows systems. It has forked it in 2007 in order to provide support for 64 bits and new APIs. It has since then gained widespread use and distribution


    ------------------------


    SDL_MemoryBarrierReleaseFunction


    Memory barriers are designed to prevent reads and writes from being reordered by the compiler and being seen out of order on multi-core CPUs.

    This function is available since SDL 2.0.6.



  • Meine laienhaften, subjektiven und nicht gemessenen Eindrücke sind: Bei Schwenks (speziell enge Kurvenfahrten aus dem Führerstand) und Zooms ruckelt es mehr als vorher, bei eher statischen Ansichten oder Führerstandsmitfahrten auf gerader Strecke ist es etwas besser geworden, aber nicht umwerfend. Wobei ich eher einen Low-End-Rechner habe, aber gerade deshalb hatte ich mehr erwartet. Die Ladezeit hat sich erheblich verbessert, allerdings scheint es wohl beim ersten Laden länger zu dauern, weil da jede Menge gecached wird. Korrigiert mich, wenn ich da falsch liege.

    ... don't know much trigonometry ... don't know much about algebra ... don't know what a slide rule is for ...

  • Es könnte sein das UG nun viel schneller Texturen die nicht im Bild sind direkt aus den Speicher wirft, da beim verschieben dann ne Tonne Texturen geladen werden müssen, kann das Leistung kosten.. Ggf. kannst du über das UG Debug Fenster beobachten?

    Ich hab das neuste Update noch nicht sonderlich viel gespielt ... aber wäre schön blöd, wenn UG den VRAM nicht ausnutzt und dadurch das Spiel sichtbar ruckelt. Ich hab aber jetzt nicht vor Messungen durch zu führen, nicht mal für ne subjektive Meinungen. Das erste was ich immer mache, ist ein mal über die gesamte Karte fahren damit alle Daten schön im Speicher sind. Und dann versuchen so gut es geht Micro-Ruckler zu ignorieren. :S

    Zum Thema Simulationsperformance ... die ist in den FPS nicht unbedingt ablesbar. Die Berechnungen passieren ja in extra Threads und sind (zum größtenteil) abgekoppelt vom Rendering. Jetzt mit Vulkan würde ich davon ausgehen, das die ja sogar zu 100% abgekoppelt ist. Ist bei all den Performance-Balken im Debug-Fenster nicht auch etwas dafür dabei, womit sich das evt. vergleichen ließe? Interessieren würds mich ja schon, ob sich da wirklich was getan hat oder es am Ende nur subjektiv wahrnehmbar ist.


    OurGreatReader don't be afraid of translation-tools, DeepL.com is a very good tool. Use it to translate from your mother-language to english. (and the other way around to understand us)

    Can't say much about ChatGPT translation capabilities, but there is a high chance that they are very good, too.



    MFG PMV

  • Der FPS Monitor misst auch die Simulationsperformance, ich hätte es nach dieser Ergänzung umbennen können. Die Simulation ist in der Theorie unabhängig von den FPS, richtig. Der Ansatz ist, sich im ausgelasteten Simulationszustand (8x) die vergangenge Zeit für die update Ticks anzuschauen und mit der normalen Zeit für Echtzeitdarstellung (5ticks/sec bei 1x) zu vergleichen. Also 100% wenn die Berechnungen hinterherkommen und sonst weniger, das ist der Wert für die Sim Performance. Mehr Infos bei FPS Monitor oder dem verlinkten Beitrag Simulationsperformance zu den Diagrammen.


    VRAM nimmt jetzt auch nicht ständig wieder ab, bleibt konstant, aber ich glaub vor dem Update höher. Von 6,8GB Texturen entfallen 4,9 auf terrain

  • Im Beitrag wurde geantwortet, dass es folgende Einstellungen gibt (settings.lua)

    -enableDeferredTextures

    -terrainTesselationEnabled

    Die sind mit dem Update hinzugekommen. Ich habe beide auf false gesetzt und es ist wieder ein gutes Stück besser.

  • Wenn VRAM im Überfluss da ist, mag es sinnvoll sein, enableDeferredTextures = false zu setzen.

    Wenn es wie bei mir 6 GB sind, sollte es wohl besser an bleiben.


    Edt:

    Ja, kann ich bestätigen, es ist bei mir schlimmer mit enableDeferredTextures = false


    Edit:

    Noch was - mit enableDeferredTextures = false ist allerdings der Spielstand schneller geladen

    2 Mal editiert, zuletzt von Sandtorhai ()

  • VacuumTube

    Hat den Titel des Themas von „Performance Vergleich Spielupdate (35210)“ zu „Performance Vergleich Konsolen-Update (9.3.2023)“ geändert.
  • Hab auch mal bei mir getestet, glaube ist nicht das gleiche Savegame das du hast sondern ein neueres und hab teils nur 5-15 fps, Simulation ist nur minimal besser (2x speed geht grade so, 4x garnicht) und das Spiel macht nach wie vor wenig Spaß, wenn man ein paar größere Städte hat.


    Schade.

    3, 2, 1, meins... Lg Edith

BlueBrixx