Danke für die ausführliche Antwort, so lässt sich viel besser diskutieren.

Zu Kuju: Wenn das so rübergekommen ist, als würde ich den Entwicklern damals Schlamperei vorwerfen, dann habe ich mich schlecht ausgedrückt. Ich habe großen Respekt vor dem, was Kuju unter den damaligen Bedingungen gebaut hat. Das Grundkonzept mit Blueprints, Lua und offenem Asset-Format ist genau der Grund, warum TSC nach über 15 Jahren noch lebt und warum ich überhaupt darauf aufbauen kann. Dass ich heute an manchen Stellen sehe, was man anders lösen würde, liegt an 15 Jahren mehr Erfahrung in der Branche. Mit Überheblichkeit hat das nichts zu tun. AP ist ein gutes Beispiel dafür, wie viel in der Engine steckt.

Zu den Rechenzentren: Da gebe ich dir ehrlich recht. Die Hardwarepreise und der Energiebedarf sind ein echtes Thema. Ich klammere das nicht aus, ich habe mich nur entschieden, das Werkzeug trotzdem zu nutzen.

Zur Verschlüsselung, und das ist mir wichtig: Eine Entschlüsselung der DTG-Geometrie wird es in keinem öffentlichen Code geben. Ohne offizielle Zusage von DTG wird nichts veröffentlicht, was geschützte Inhalte zugänglich macht. Das Problem, das du beschreibst (Algorithmus offen, Besitz nicht geprüft, DLC per Torrent), sehe ich genauso, und genau deshalb passiert das nicht. Wie verschlüsselte Inhalte sauber eingebunden werden können, etwa mit Besitzprüfung über Steam, kann nur mit DTG zusammen geklärt werden. Bis dahin gilt die Einschränkung, die du ansprichst, da hast du recht.

Zu OpenRails: Der Vergleich passt nur teilweise. OpenRails musste das MSTS-Verhalten rekonstruieren, und die MSTS-Dateien waren oft nicht streng definiert. TSC hat mit den Blueprints ein deutlich strengeres Format. Ich lese die Werte direkt aus den Dateien, statt sie zu schätzen. Dass trotzdem Sonderfälle kommen, bei denen einzelne Addons sich anders verhalten als im Original, bezweifle ich nicht. Daran wird man lange arbeiten.

Zum Renderer: Freut mich, dass wir da einer Meinung sind. Orbiter ist ein gutes Beispiel.

Zur Euphorie: Die Skepsis ist berechtigt, und ich nehme sie ernst. Es kommen sicher noch Hürden, technische wie rechtliche. Ich verspreche niemandem etwas, das ich nicht halten kann. Meinungsaustausch in dieser Form ist mir jedenfalls lieber als Jubel ohne Nachdenken.

Deine Unterscheidung zwischen „Datei geladen“ und „im Betrieb korrekt“ trifft den Kern des Projekts. NEXT ist inzwischen ein funktionierender technischer Prototyp, aber noch kein vollständig kompatibler Ersatz für den Train Simulator Classic.

Die Engine liest Inhalte direkt aus einer vorhandenen TSC-Installation, darunter Archive, Blueprints, Streckenkacheln, Geometrie, Texturen und Szenarien. Sie stellt die Welt mit einem eigenen Renderer dar und führt originale Lua-Skripte in einer eigenen Laufzeitumgebung aus. Die Originalshader werden dabei nicht verwendet; ihre Materialinformationen werden für den neuen Renderer interpretiert. Dass eine Strecke sichtbar ist und ein Zug geladen wird, sagt allerdings noch wenig darüber aus, ob eine komplette Fahrt wie im TSC abläuft.

Die genannten Prüfzahlen beziehen sich vor allem auf technische Abdeckung. In einer Bestandsaufnahme wurden 901 Fahrzeug-Blueprints und 887 davon mit Skripten erfasst. 2.661 Testprofile prüfen unter anderem Initialisierung und Bedienreaktionen. Dabei traten bei 56 Fahrzeug-Blueprints Laufzeitfehler auf. Ein fehlerfrei gestartetes Skript gilt für mich deshalb ausdrücklich nicht als Nachweis, dass PZB, Bremsen oder Fahrzeugfunktionen korrekt arbeiten.

Für das Betriebsverhalten nutze ich gezielte Fahrversuche und vergleiche Daten und Abläufe mit dem Original: etwa gespeicherte Fahrwege aus den jeweiligen Saves, Signalstellungen, Skriptzustände und Bremsdrücke. Einen durchgehend automatisierten Live-Vergleich, der dieselbe Fahrt parallel in TSC und NEXT ausführt, gibt es derzeit nicht. Auch ein erreichbares Ziel im Gleisgraphen beweist noch nicht, dass der Zug denselben Fahrweg nimmt: Bei einer Prüfung von 475 gespeicherten Originalwegen waren 471 Ziele erreichbar, doch die Prüfung zeigte auch konkrete Abweichungen im Verlauf.

Undokumentierte Besonderheiten der alten Engine gehe ich daher fallweise an: Ich lese die Originaldaten und Skripte, beobachte nach Möglichkeit das Verhalten im TSC und baue für eine bestätigte Abweichung einen reproduzierbaren Test. Wo das Originalverhalten noch nicht belegt ist, kennzeichne ich die Umsetzung als Annahme.

Mein Maßstab für eine belastbare Kompatibilitätsaussage wäre eine benannte Strecke mit benanntem Szenario und Fahrzeug, die vom Start über KI-Verkehr, Fahrstraßen, Signale und Fahrzeugbedienung bis zum Szenarioabschluss wiederholt korrekt funktioniert – mit dokumentiertem Vergleich zum TSC. Eine solche allgemeine Freigabe kann ich heute noch nicht geben.

Die größten Schwierigkeiten liegen inzwischen weniger beim bloßen Lesen der Dateien als beim Zusammenspiel von Gleisgraph, Dispatcher, Signalen und den sehr individuellen Fahrzeugskripten und Bremsmodellen.

Im Kern sind wir uns einig. Ich würde zwei Details präzisieren: Tracks.bin liefert bei den Gleisen unter anderem Topologie, Eigenschaften und Höhenprofile; die X/Z-Kurven lese ich aus den Track Tiles und ordne sie über die RibbonID zu. Erst zusammen ergibt das die räumliche Gleistrasse. Auch 0xE7 würde ich nicht als allgemeines Referenz-Opcode bezeichnen: In SERZ kann ein solches Byte ein dateispezifischer Eintrag im Zeilen-Cache sein; die referenzierte Element-ID folgt dann als 32-Bit-Wert.

Bei der Engine-Geschichte sollten wir ebenfalls präzise bleiben. Die 64-Bit-Version von 2018 brachte vor allem mehr adressierbaren Speicher, keine neue Grafikarchitektur. Dovetail hat aber 2023 ausdrücklich Core-Code überarbeitet und einen experimentellen DX12-Build angeboten. „Seit 2009 unangetastet“ oder „ausschließlich DirectX 9“ wäre deshalb zu absolut. Dovetails Erklärung zur 64-Bit-Einführung bestätigt zugleich, dass 64 Bit allein keine sichtbare Grafik- oder FPS-Verbesserung versprach.

Mein Ansatz ist weiterhin, die Originaldaten unabhängig vom alten Runtime-Core zu lesen und in meiner eigenen Engine zu verarbeiten. Vom Visual Framework über RenderCore bis zum jetzigen Rust-System war der Parser nur der erste Schritt. Entscheidend ist die Übereinstimmung im laufenden Szenario: Gleisgeometrie, Weichen, Fahrstraßen, Signalzustände, Fahrzeuge und Anzeigen müssen sich wie im Original verhalten. Genau daran messe ich die Implementierung – und genau dort werden die verbleibenden Fehler sichtbar.

Ich weiß, wie TSC seine Daten verarbeitet, weil ich mich seit Langem praktisch damit beschäftige. Mit meinem TSC Visual Framework habe ich mich zunächst in die laufende 64-Bit-Version eingeklinkt und über einen D3D9-Proxy Shader, Renderzustände und Zeichenaufrufe untersucht. Danach habe ich den RenderCore der GameManagerVC64.dll analysiert. Dabei wurde klar: Ein Grafik-Proxy ersetzt nicht die Engine. Deshalb lese ich für NEXT die vorhandenen Spieldaten selbst und stelle sie mit einem eigenen Renderer dar – ohne Originalshader.

Die Tracks.bin ist komplex, aber die Beschreibung als Datei, in der wahllos alles steckt, ist falsch. Sie enthält wichtige Netzwerkdaten und Verknüpfungen; die Gleiskurven liegen beispielsweise in den Track Tiles und werden über IDs zugeordnet. Signal- und Fahrzeugskripte sind weitere Bestandteile.

64 Bit bezeichnet bei TSC die Architektur des Programms und den größeren adressierbaren Speicher. Es macht weder das Streckenformat neu noch sorgt es automatisch für einen neuen Renderer oder Multithreading. Dovetail sagte 2018 selbst, dass die Inhalte unverändert bleiben und die Grafik weiterhin DirectX 9 nutzt. Auch die Behauptung, DTG habe den Core danach nie wieder angefasst, stimmt nicht: 2023 wurde er überarbeitet. 2025 erklärte DTG, vorerst bei dieser Codefassung zu bleiben.

KI hilft mir bei der Analyse. Ob meine Engine eine Originalstrecke korrekt darstellt, muss ich trotzdem an Geometrie, Signalen, Fahrwegen, Skripten und im laufenden Szenario prüfen.

Kurz gesagt - ich kenne die gesamte Renderpipeline, ich kenne die Worker die alles verarbeiten und weitergeben. Ich mach das alles nicht ohne know-how.

Danke dir, das trifft es ziemlich genau.

„Bau mir einen TSC-Klon“ eintippen und abwarten, das funktioniert nicht und hat auch nie funktioniert. Hinter NEXT – für TSC steckt Arbeit, wie man sie aus jedem normalen Softwareprojekt kennt:

• Aufteilung: Das Projekt ist in klar getrennte Bereiche zerlegt: Grafik und Shader, Modelle und Animationen, Lua-Skripte und Signale, Fahrphysik, Sound, KI-Fahrdienstleiter, Editor. Jeder Bereich hat feste Zuständigkeiten und Regeln, wer welche Dateien anfasst.
• Nachvollziehbar statt erfunden: Werte kommen aus den Original-Blueprints und Dateien, nicht aus Schätzungen. Wo etwas eine Annahme ist, wird es als solche markiert und später überprüft.
• Prüfung von außen: Signale, Lokskripte, Shader, Sound, Physik, Kupplungen, Gelände und Dispatcher werden regelmäßig von einem zweiten, unabhängigen System gegengeprüft. Die Fehlerlisten werden dann Punkt für Punkt abgearbeitet.
• Ein Build, feste Tests: Gebaut wird zentral, mit automatischen Tests bei jedem Schritt. Was dort scheitert, geht zurück, bevor es überhaupt jemand startet.
• Abnahme im Spiel: Am Ende sitze ich selbst im Führerstand und prüfe, ob sich Signale, Bremsen, Anzeigen, Licht und KI-Verkehr so verhalten wie im Original. Erst dann gilt etwas als erledigt.

Die KI schreibt den Code, ja. Aber was gebaut wird, wie es aufgeteilt ist, ob es stimmt und was rausgeht, entscheide ich. Wer das „Vibe Coding“ nennt, hat es entweder nie selbst versucht oder das Ergebnis nicht angeschaut.

Ja es ist halt ein Unterschied ob mit KI alleine oder durch "Unterstützung" der KI.

Wie dumm wäre ich, wenn ich den kompletten Programmcode selbst schreibe, wenn das auch die KI kann.

Und was ich an dem Projekt übernheme ist auch ganz klar

* Fehleranalyse und größtenteils auch - behebung

* rechtliche Überprüfungen
* Konzepterstellung (neue Ideen)
* Korrekturen
* Detailfunktionen - wie - was macht der Dispatcher wann

* Physikalische Berechnungen
* Recherche

Ohne meine Überprüfung wird kein Code umgeschrieben ja nicht mal eine Ziffer ersetzt.

Wenn ihr so wollt - ich bin der Projektleiter, arbeite aber trotzdem komplett mit und die KI Agents sind eben meine Mitarbeiter.
Ich denke daran gibt es nichts verwerfliches.

Ich kann diesen Einwurf deshalb absolut NICHT nachvollziehen.

Es gibt KI und es gibt KI - aber es kommt auf den Menschen an der damit arbeitet.

Danke für die Einordnung. Ein paar Dinge möchte ich trotzdem geraderücken.

Zum Namen: Dass niemand „NEXT“ für sich gepachtet hat, sehe ich genauso. Gerade deshalb verstehe ich nicht ganz, warum du es nötig hattest, dich öffentlich abzugrenzen. Verwechslungen will ich vermeiden, deshalb heißt mein Projekt ausdrücklich „NEXT – für TSC“. Es ist klar als eigenständiges Open-Source-Projekt für Train Simulator Classic gekennzeichnet. Mit deinem Train Simulator NEXT hat es nichts zu tun und will es auch nicht.

Zu „fast vollständig KI-generiert“: Ja, ich arbeite mit KI-Werkzeugen und mache daraus kein Geheimnis. Das ist ein Werkzeug, so wie Compiler, Engines und Middleware. Entscheidend ist doch, was am Ende herauskommt und ob es funktioniert. Wer pauschal von „AI-Slopware“ spricht und dazu YouTube-Videos verlinkt, ohne sich das Projekt selbst anzusehen, macht es sich ziemlich einfach. Der Code ist offen, jeder kann reinschauen und sich selbst ein Urteil bilden. Das ist mehr Einblick, als du in dein eigenes Projekt geben möchtest. Das ist dein gutes Recht, aber dann ist Kritik an der Arbeitsweise anderer etwas wohlfeil.

Zum Rechtlichen: Die Frage ist berechtigt, und ich nehme sie ernst. NEXT – für TSC liefert keine Inhalte von Dovetail oder anderen Herstellern aus. Es liest nur die Dateien aus der eigenen, rechtmäßig erworbenen Installation des Nutzers. Außerdem habe ich mich bereits direkt an Dovetail Games gewandt, statt im Forum darüber zu spekulieren, was sie vielleicht unterbinden könnten. Wenn von dort eine klare Ansage kommt, richte ich mich danach.

Dir wünsche ich mit Train Simulator NEXT ebenfalls viel Erfolg. Am Ende profitieren wir alle davon, wenn es mehr als eine Idee gibt, wie es mit Train Simulator Classic weitergehen kann.

Oh und btw - das möchte ich noch hinzufügen

Mich interessiert weder deine "eigene Entwicklung" - noch deine "technische Konzeption". - hab mein eigenes Hirn welches ich dafür anstrenge.

Zitat von Kim_olesen1

Already following you on the Railworks Austria thread, very interesting project.

This is ofcourse what DTG ought to have done, but really they probably did not want their legacy simulator to actually be in competition to TSW.

That’s probably part of it. TS Classic still sells well, but every bigger upgrade would compete with TSW, so it’s understandable that DTG keeps it on a maintenance track.

That’s exactly the gap NEXT is trying to fill. It’s a free, open-source rebuild of the TSC engine that reads the existing content as it is: routes, scenarios, rolling stock, Lua scripts. Nothing gets converted or re-released. Your DLC simply runs on a modern renderer with current lighting, weather and performance.

It’s not meant as competition to either product. It just lets the content we’ve all bought over the years keep looking and playing well.

But in my opinion -
I dont see any competition to TSW.

And the main aspect of NEXT is not to have Unreal Graphics 234409873204 - it is functionality, compatiblity and stability.

Und hier zu meiner Erklärung was ich zum Originalen TSC anders mache:

So entlaste ich den Hauptkern

Der Hauptthread ist der Thread, der das Bild fertigmacht und auf den Bildschirm bringt. Ich habe alles, was sich verschieben lässt, von ihm weggenommen:

• Simulation auf eigenem Thread: Physik, Signale, Verkehr und Ton laufen parallel zum Zeichnen. Der Hauptkern bekommt nur das Ergebnis.
• KI-Skripte parallel: Die Skripte der KI-Züge laufen jeweils auf mehreren Threads, nicht nacheinander.
• Bildaufbau aufgeteilt: Ich bereite Schatten, Tiefenvorlauf, Dachkarte, Spiegel und Hauptpass auf getrennten Threads vor und setze sie erst am Ende zusammen.
• Abschicken auf eigenem Thread: Die Befehle gehen auf einem eigenen Thread an die Grafikkarte. Die Prüfungen dabei kosteten vorher auf dem Hauptkern etwa 13 ms.
• Culling auf der Grafikkarte: Welche Objekte sichtbar sind, entscheidet die GPU. Die CPU verteilt nur noch die Arbeit, und der Rest läuft auf bis zu 8 Threads.
• Kachel-Streaming im Hintergrund: Laden, Vorbereiten und Hochladen der Kacheln laufen auf eigenen Threads mit niedrigerer Priorität. Der Hauptkern setzt nur noch fertige Kacheln ein, eine alle 10 Bilder.
• Freigeben im Hintergrund: Nicht mehr gebrauchte Modelle gibt ein eigener Thread frei, in kleinen Stücken. Das kostete vorher bis zu 60 ms im Hauptthread.
• Listen im Hintergrund: Materialgruppen, Zeichenlisten und der Plan für das GPU-Culling baue ich auf einem Hilfsthread.
• Gelände-Texturen: Sie laden auf einem eigenen Thread hoch.
• Dispatcher: Der Fahrplan läuft auf einem eigenen Thread.

Alle Hilfsthreads laufen mit niedrigerer Priorität, damit sie dem Hauptkern keine Rechenzeit wegnehmen.

Was auf dem Hauptkern bleibt, ist das Zusammenbauen und Abschicken des Bildes. Dazu die Messwerte: Der Render-Thread braucht etwa 12 ms pro Bild, die Simulation etwa 10,9 ms parallel dazu.

Zitat von mikede

Relief is nice, but you should watch out with it, make sure its doesn't contain relief anymore on some distance from the camera, proper lod policy is very important with this.
its also nice if you can introduce instancing on the sleepers and its clips objects , yard full of them can eat you game engine alive.
im actually c++ developer

By the way, the name you use is also used by somebody, Train Simulator NEXT – Virtual Railroading i dont know the status from this sim, but i reminded the name from there.

Its NOT Train Simulator NEXT - its only NEXT. I did the same with OMSI.

And also its not allowed - not even for an Open Source Project to use "Train Simulator" or "Railworks" or anything which contains Stuff or Names from DTG.

And since i work with a lot of Threads - here is a List:

Rendering

• Parallel passes: The frame’s passes (shelter map, shadow cascades, depth prepass, mirror, main pass) are each recorded on their own thread. Recording used to take about 27 ms per frame on one core on the Nordbahn.
• Submit thread: The early command buffers go to the GPU queue on a separate thread. This took about 13 ms of checks off the render thread.
• Main pass split: Without the bindless path, the main pass is recorded in two halves on two threads.
• Parallel culling: Distance culling runs on up to 8 threads once the lists hold more than 4096 instances. It took about 5 ms on one core.
• Helper threads for lists: The material group and the GPU cull plan are built on a helper thread, and the new draw lists are installed only when ready.

Streaming and hitches

• Own tile thread: Tile loading and the GPU build of tiles run on their own thread, with one loader thread.
• Release thread (drop):Tile models are freed on a drop thread, 32 objects plus a 1 ms pause at a time. The world-swap hitches of 58–62 ms fell to under 0.1 ms.
• Terrain layers: The layers upload on a “terrain up” thread.
• Thread priority: All helper threads run below normal priority. That removed the last two hitches during the start-world swap.

Simulation and scripts

• Own sim thread: The simulation runs on its own thread and is now the default.
• Dispatcher: The dispatcher got its own thread, but part of it was rolled back (0.5 s switch cycle, traffic markers) because the system stopped working properly.
• Parallel scripts: AI scripts run in parallel per train, with at most 4 threads.

Loading

• Startup: Track network on 12 threads, start world in parallel, signals in parallel, and train and sound files prefetched. Together these cut the time to the first frame from 34 s cold to about 16 s warm.

Hier ein gutes Beispiel was man mit RELIEF erreichen kann.
Das gesamte Gleisbett wirklich gleich wesentlich realistischer.

So, auch hier habe ich den Namen geändert.

Und hier seht ihr auch noch ein paar Bilder.

Ich bin aktuell schon sehr weit fortgeschritten, allerdings muss ich jetzt auf die Antwort von DTG warten, da es nicht möglich ist DTG Content auszulesen, da die Geometrie Blobs von einigen Objekten auf den DLC Strecken verschlüsselt sind.

Was geht schon?

Sämtliche Scripts (angefangen von Signalen, Zügen, Waggons etc)
Eigener Dispatcher
Eigenes System zur manuellen Weichenstellung
Eigenes HUD
Sounds, ZZA's, etc
PZB, LZB, AFB, sämtliche Zugsicherungssysteme

Eigentlich bisher alles was man zum Fahren braucht.

Der Editor hat eine Suchleiste bekommen (weil das oft gewünscht wurde)
Und die Favoriten dort werden abgespeichert - auch über den Neustart hinaus.

Funktionsweise des Editors ist exakt die selbe wie beim Original.

Zitat von Forza Gamer 777

Actually, if this whole thing with the engine overhaul gets off the ground, then, to be honest and objective, graphics are practically the last problem TS. The main issues are with the physics engine (for example, the well‑known slow sliding of a train at speed 0 with brakes applied) and with loft objects (breaking bends, curved tools, and other “charms” of the editor). The only thing that really annoys me about the graphics is the very low resolution of the landscape textures (something like 512*512), which turns everything into a hellish mess when you zoom in. After fixing these issues, it would make more sense to focus on object culling so that objects load more smoothly and without such severe stutters.

All of this will have a much greater impact on the popularity of the new engine overhaul, and, in my opinion, people will support it incredibly actively. I understand that you’re mostly a 3D artist and it’s easier for you to work with graphics.
This isn’t some kind of list of requirements; these are just my dreams and wishes. If you’re going to add more modern graphics, then you should also use more modern DLLs and codebases, which in themselves can already improve performance. So, in any case, it’s great that people have started thinking about this and trying to somehow extend the life of TS, because it’s literally the only product on the market that has a lot of playable content and its average quality is quite high.

I can tell it from my own Project:

You’re right that graphics alone won’t save TS. It isn’t a graphics mod, though: the engine is being rebuilt from scratch in a modern language with current libraries, and the original content still runs on it. So it’s not new effects stuck onto the old executable.

A lot of the work goes into exactly the things you mention:

• Physics: The driving physics are being redone, with all values taken from the original blueprint files instead of being guessed. That way locos and wagons behave the way their authors set them up. Steam locos now have a real boiler simulation (pressure, water, fire, an optional automatic fireman). The famous creeping at 0 km/h with the brakes on is on my test list.
• AI and dispatching: The AI dispatcher is new as well. I compared it against the routes the original dispatcher planned in real save games. It now picks the same route in about 95 % of cases, but should get stuck far less often.
• Loft objects and the editor: There’s a separate editor in the works. Broken bends and strange curves are a known pain point there.
• Loading and stutters: Tile and object streaming has been reworked so that scenery loads more smoothly while driving. Getting rid of stutters has high priority.

Zur rechtlichen Überprüfung brauchst du dir die Frage bezüglich Payware eigentlich gar nicht erst zu stellen:

Als kostenpflichtiges Produkt (Payware) DARFST du so etwas schlichtweg nicht verkaufen.

Sobald du für eine alternative Runtime/Engine Geld verlangst, die die proprietären Dateiformate, Skripte und Assets von Dovetail Games und Drittanbietern einliest, nutzt du fremdes geistiges Eigentum für kommerziellen Gewinn. Ohne eine offizielle Lizenzvereinbarung mit DTG hängst du da sofort in einer Urheberrechtsklage.

Die einzige juristisch sichere Option für Projekte dieser Art (siehe das Vorbild OpenMW) ist ein vollständig kostenloses Open-Source-Projekt (GPL/MIT/Apache).

Nur so greift der Schutz der technischen Interoperabilität, und nur so schützt man sich vor den Anwälten der Rechteinhaber.

Wenn du es veröffentlichst, geht es rechtlich sauber also nur als freies Community-Projekt.

Es wird immer besser

Mittlerweile nutze ich Relief Mapping für das Gleisbett.

Und Spiegel sind jetzt Spiegel. Egal man auf oder zuklappt - das Spiegelbild geht mit

Ja, das ist tatsächlich noch der Train Simulator Classic.

Aber in komplett neuem Gewand.

Selber Content - neue Engine.

Westbahn zum Wochenende

Zitat von ice

Das habe ich doch schon alles oben geschrieben..also für mich nichts Neues.

Der Geschwindigkeitsvorteil von Vulkan ensteht maßgeblich durch die reduzierte Shaderlanguage im Vergleich zu DX9.0.

TSc:,

Das Spiel hat ja auch eine "Umgebungsverdeckung" die 1 oder 2 Stufen in den Einstallungen dazu schaltbar ist. Das ist nichts anderes als "Ambient Occlusion...also "AO".

Da werden Ecken Spalten, Übergänge zwischen Objekten mit Schatten belegt. Das wird über alle Objekte der Scenery angewand(eingeschalttet).

Wer saubere Arbeit als Author macht, der backt bei Texturerstellung in Modeller den Licht-Schatten gleich mit in die Textur. Das gibt nacher den Tiefen-Effekt.

In den ersten Bild oben sind keine Texturen mit AO gebacken...deswegen sehen die auch fade und fast kontourlos aus.

Alles anzeigen

Da hast du grundsätzlich recht: sauber gebackenes AO in Texturen ist natürlich die beste Basis, weil gute Assets dadurch schon von Haus aus mehr Tiefe bekommen.

Aber genau da liegt der Unterschied:

Das, was ich meine, ist kein Ersatz für gebackenes AO und auch nicht einfach das normale TSC-SSAO.

Contact AO Shading arbeitet viel lokaler. Es dunkelt nicht die ganze Szene ab, sondern nur sehr kurze Kontaktbereiche, z.B. wo Rohre am Boden liegen, Schwellen im Schotter sitzen oder Objekte direkt aufeinander/nebeneinander stehen.

Gebaktes AO ist statisch im Asset. Das spielinterne AO ist globaler und gröber.

Contact AO ist ein zusätzlicher, sehr gezielter Kontakt-Schatten im Bild, damit Objekte nicht mehr so „schwebend“ oder flach wirken und hat mit der normalen Umgebungsverdeckung im Spiel absolut nichts zu tun.

Also ja: Wenn ein Author sauber modelliert und AO baked, sieht es schon besser aus. Aber Contact AO hilft besonders bei alten oder einfachen TSC-Assets, die eben keine guten AO-Texturen haben oder im Spiel trotzdem zu flach wirken.

Zitat von ice

Da hast Du Recht und ich habe mich falsch ausgedrückt, die zwei Kerne sind auf den TSc gemünzt ...eigentlich läuft alles auf einen Kern,einwenig Berechnungen laufen auf einen zweiten Kern mit.

Es gibt aber auch Spiele die trotzdem nicht besser laufen. Auch Spiele mit Anticheat können Probleme machen.

Da nützt dann auch die beste Karte nichts.

Vulkan/DXVK macht aus TSC keine moderne Multi-Core-Engine. Der Train Simulator Classic bleibt stark auf einen Hauptkern limitiert, mit etwas Arbeit auf einem zweiten Kern.

Der Vorteil von DXVK liegt eher darin, den alten DX9-Pfad zu entlasten: weniger Treiber-Overhead, effizientere Drawcalls und ein modernerer Vulkan-Unterbau.

Aber Vulkan ist kein Wundermittel. Wenn ein Spiel selbst schlecht optimiert, stark CPU-limitiert oder durch Anti-Cheat eingeschränkt ist, bringt auch DXVK nicht immer Vorteile. Eine starke Grafikkarte hilft wenig, wenn die Engine am Hauptthread hängt.

Für das TSC Visual Framework ist Vulkan deshalb kein reiner FPS-Trick, sondern eine modernere Basis, um den alten Renderpfad sauberer und effizienter zu behandeln.

Aktuell arbeite ich an sogenannten "Contact AO Shading"

Hier eine kurze und knappe Erklärung was es macht:

Contact AO Shading ist eine sehr kurze, lokale Abdunklung dort, wo Objekte optisch Kontakt zur Umgebung haben.

Also z.B.:

• Mastfuß am Boden
• Zaunpfosten im Gras
• Schwellen im Schotter
• Räder/Objekte nahe am Untergrund
• Vegetation unten am Boden

Es ist kein großes SSAO, das die ganze Szene dunkler macht, sondern eher ein feiner „Objekt-klebt-am-Boden“-Effekt.

Kurz gesagt:

Contact AO gibt Objekten Gewicht und Tiefe, indem es nur die direkten Kontaktbereiche leicht abdunkelt. Dadurch wirkt TSC weniger flach und weniger „schwebend“, ohne das komplette Bild zu verdrecken.

Hier ein Bild ohne "Contact AO Shading"

Hier ein Bild mit "Contact AO Shading"

Es verleiht der gesamten Umgebung wesentlich mehr Tiefe - es geht nur noch um Feinabstimmungen.

Nein hat weniger mit der Karte zu tun. Ich hab ne 5080 und bei mir läuft es gar nicht mit DX12.

Vulkan über DXVK macht TSC nicht „modern“, aber es verlagert die alte D3D9-Ausgabe auf einen effizienteren Vulkan-Pfad. Dadurch sinkt oft der CPU- und Treiber-Overhead bei Drawcalls und Pipeline-Verwaltung. Shader und Renderstates werden von DXVK in Vulkan-Pipelines übersetzt und gecacht, wodurch Shader-Stutter reduziert werden kann. Die Engine selbst bleibt aber alt und meist auf wenige CPU-Threads begrenzt; Vulkan hebt diese Engine-Limitierung nicht vollständig auf.

Also: Ja, DXVK kann den Overhead reduzieren. Nein, Vulkan/DXVK ist nicht grundsätzlich auf zwei Kerne limitiert.

Warum Vulkan/DXVK für TSC sinnvoller ist als DX9 oder der experimentelle DX12-Modus

Train Simulator Classic basiert technisch weiterhin auf einer sehr alten DirectX-9-Renderpipeline. Genau dort liegen viele der typischen Probleme: CPU-Limit, alte Render-State-Logik, schwaches Ressourcenmanagement, instabile Frametimes und Probleme mit modernen Treibern. Der experimentelle DX12-Modus von TSC war laut Dovetail selbst nicht vollständig optimiert und sollte Feedback sammeln; bei Problemen wurde weiterhin empfohlen, auf der normalen 64-bit-Version zu spielen.

Vulkan über DXVK ist für TSC deshalb interessant, weil es nicht versucht, TSC intern zu einer modernen DX12-Engine umzubauen, sondern die vorhandenen D3D9-Aufrufe in eine moderne Vulkan-Ausgabe übersetzt. DXVK ist genau dafür gebaut: Es ist eine Vulkan-basierte Implementierung für Direct3D 8/9/10/11.

Für unser Framework bedeutet das:

TSC bleibt logisch D3D9, aber die Ausgabe läuft moderner über Vulkan. Dadurch können wir alte TSC-Hooks, D3D9-States und Shader-Pfade weiter nutzen, aber trotzdem von DXVK/Vulkan bei Frametimes, Backend-Stabilität und modernen GPU-Treibern profitieren.

DirectX 9 im TSC

Vorteile

• Originaler Renderpfad von TSC
• höchste Kompatibilität mit alten Strecken, Assets und Shadern
• funktioniert ohne zusätzliche Wrapper
• unser d3d9.dll-Proxy kann direkt in den D3D9-Pfad eingreifen
• RenderStates wie SetRenderState, SetSamplerState, DrawPrimitive, DrawIndexedPrimitive sind direkt abfangbar
• ideal für Debugging, Shader-Hooks und klassische D3D9-Modding-Techniken

Nachteile

• sehr alte API
• stark CPU-/Drawcall-limitiert
• moderne Treiber optimieren D3D9 oft nicht mehr so aggressiv wie moderne APIs
• Framepacing kann unruhig sein
• viele Probleme entstehen aus alter Render-State-Logik
• schlechte Kontrolle über moderne GPU-Features
• Z-Fighting, Alpha-Test-Flimmern und MIP-Shimmering bleiben enginebedingt bestehen
• Downsampling/AA löst nicht alle alten TSC-Probleme

Kurz gesagt

DX9 ist der stabilste und kompatibelste Originalpfad, aber technisch auch der limitierendste.

DirectX 12 Experimental im TSC

Vorteile

• theoretisch moderneres Backend
• kann auf bestimmten Systemen oder Szenarien bessere GPU-Auslastung bringen
• langfristig wäre DX12 als nativer Renderpfad moderner als DX9
• potentiell besseres Ressourcenmanagement, wenn vollständig sauber implementiert

Nachteile

• in TSC offiziell als experimental eingeführt
• Dovetail schrieb selbst, dass der DX12-Build noch nicht vollständig optimiert war und Feedback gesammelt werden sollte
• kann je nach Strecke, Asset, System und Treiber instabiler sein
• für Modding schwieriger, weil klassische D3D9-Hooks nicht mehr direkt greifen
• unsere bestehenden d3d9.dll-Hooks, RenderState-Hooks und Shader-Override-Ansätze passen dort nicht sauber
• bringt nicht automatisch bessere Bildqualität
• löst Z-Fighting/enge Mesh-Überlagerungen nicht grundsätzlich
• für alte TSC-Inhalte kann DX12 sogar mehr neue Probleme erzeugen, weil die Engine ursprünglich nicht dafür gebaut wurde

Kurz gesagt

DX12 Experimental ist interessant, aber für ein tiefes TSC-Framework aktuell weniger kontrollierbar und weniger vorhersehbar als D3D9/DXVK.

Vulkan über DXVK

Vorteile

• nutzt den bestehenden D3D9-Pfad von TSC, gibt ihn aber über Vulkan aus
• DXVK ist speziell eine Übersetzungsschicht von Direct3D 8/9/10/11 zu Vulkan
• unser Proxy kann weiterhin als RailWorks\d3d9.dll arbeiten
• DXVK kann als Backend aus RailWorks\dxvk\d3d9.dll geladen werden
• moderne Vulkan-Treiber können oft bessere Frametimes liefern als alter nativer DX9-Treiberpfad
• DXVK bietet zusätzliche Konfigurationsmöglichkeiten über dxvk.conf; die Datei wird üblicherweise im Arbeitsverzeichnis beziehungsweise beim Spiel-Exe-Pfad gesucht
• Optionen wie d3d9.alphaToCoverage, d3d9.maxFrameLatency und LOD-/Sampler-Einstellungen können gezielt getestet werden
• guter Mittelweg: alte TSC-Kompatibilität behalten, aber moderneres Backend nutzen
• ideal für unser Framework, weil wir D3D9-Hooks behalten und trotzdem Vulkan als Ausgabe verwenden können

Nachteile

• zusätzliche Übersetzungsschicht
• nicht jede D3D9-Spezialität verhält sich exakt wie beim nativen DX9-Pfad
• manche alte Fixed-Function- oder Shader-Edge-Cases können anders reagieren
• DXVK-Konfiguration muss manuell angelegt werden; DXVK erzeugt die dxvk.conf nicht automatisch
• Debugging wird komplexer, weil man TSC → Proxy → DXVK → Vulkan betrachtet
• nicht jedes Flimmerproblem wird gelöst, besonders nicht echtes Z-Fighting durch Mesh-auf-Mesh
• kann je nach GPU/Treiber/Strecke eigene Nebenwirkungen haben

Kurz gesagt

Vulkan/DXVK ist für TSC aktuell der beste Kompromiss:

mehr Modernität als DX9, aber deutlich mehr Kontrolle und Kompatibilität als der experimentelle DX12-Pfad.

Mein Fazit

Für TSC ist Vulkan über DXVK aktuell der sinnvollste Weg, weil wir damit drei Dinge kombinieren:

1. D3D9-Kompatibilität
   
   TSC läuft weiterhin über seinen bekannten Renderpfad.
2. Framework-Kontrolle
   
   Unser d3d9.dll-Proxy kann weiterhin RenderStates, Shader, SamplerStates, Depth und Postprocessing kontrollieren.
3. Modernes Backend
   
   Die eigentliche Ausgabe läuft über Vulkan/DXVK statt über den alten nativen DX9-Treiberpfad.

Deshalb ist Vulkan/DXVK für unser TSC Visual Framework besser geeignet als nativer DX9 oder der experimentelle DX12-Modus. DX9 ist zu alt und limitiert, DX12 Experimental ist zu unkontrollierbar, aber Vulkan/DXVK gibt uns genau den Mittelweg: alte Engine behalten, modernes Backend nutzen, Framework-Hooks weiter verwenden.

Und das ist eine Zusammenfassung aus all meinen recherchierten Quellen.

Zitat von ice

Der TSc ist eigentlich ein DirectX9.0 Spiel. Es wurde nachträglich auf DX12 möglich gemacht.

Man kann sowohl als DX9 bzw. Vulkan oder DX12 starten. Mit der jeweiligen EXE Startversion versteht sich.

Und nein kann man nicht. Bei sehr vielen Usern startet TSC im DX12 Modus überhaupt nicht.