NEXT – für Train Simulator Classic (RailWorks)

Eine neue, freie Engine für eure Classic-Sammlung

Hallo zusammen,

heute möchte ich euch ein Projekt vorstellen, an dem ich seit einiger Zeit arbeite: NEXT. Das ist eine komplett neu geschriebene Engine, die eure vorhandene Installation von Train Simulator Classic lädt – eure Strecken, Loks, Wagen und Szenarien – und sie mit moderner Technik darstellt und simuliert.

Kein anderer Zugsimulator hat einen so großen Bestand an Inhalten wie Classic: über 15 Jahre Strecken und Fahrzeuge von Dovetail Games, unzähligen Drittanbietern und der Freeware-Community. NEXT soll diese Sammlung nicht ersetzen, sondern sie auf aktuelle Hardware bringen.

Wichtig vorab: NEXT ist ein kostenloses Open-Source-Projekt. Es liefert keinerlei Inhalte mit. Ihr braucht Train Simulator Classic und eure eigenen, gekauften oder heruntergeladenen Inhalte.

WAS IST NEXT?

NEXT ist eine eigenständige Engine, geschrieben in Rust, ähnlich wie OpenMW für Morrowind. Sie liest die Original-Dateien direkt aus eurer Installation, auch aus den gepackten .ap-Archiven, und lässt die Lua-Skripte der Loks, Signale und Szenarien so laufen, wie die Hersteller sie geschrieben haben. An eurer Installation wird nichts verändert.

Dazu gehören:

• ein eigener Launcher im Stil des Original-Menüs (Schnelles Spiel, Szenarien, Karriere, Strecken, Fahrzeuge, Einstellungen)

• der Viewer zum Fahren

• ein World Editor in einer frühen Version

FAHREN WIE IM ORIGINAL

• Loks werden mit ihrer eigenen Tastenbelegung (Input-Mapper) bedient, Führerstände mit der Maus: Hebel greifen und ziehen, Schalter klicken, Mausrad rastet Stufe für Stufe.

• Die Lok-Skripte laufen vollständig: Aufrüsten, Hauptschalter, AFB, PZB, LZB, Sifa usw. funktionieren so, wie der Hersteller sie programmiert hat (z. B. ÖBB 4020, 1144, 1116, 1216, Railjet, BR 189, E03 …).

• Fahrphysik aus den Blueprints: Masse, Zugkraftkennlinien, Leistungsgrenze, Haftung, Bremskraft, Roll-, Luft- und Bogenwiderstand, Steigungen.

• Signale laufen mit ihren Original-Skripten, inklusive Formsignal-Flügeln, Zs3-Anzeigen und Bahnübergängen mit Schranken und Glocke.

• Szenarien mit Anweisungen, Halten, Kuppelaufträgen und Szenario-Skripten (z. B. Bremsprobe), Meldungen und Briefing.

• Alle Kameras wie im Spiel: Führerstand, Verfolger, Kopf aus dem Fenster, Streckenkamera, Fahrgastsicht, Kupplung, Rangierkamera, freie Kamera; Führerstandswechsel im Zug.

• Speichern und Fortsetzen von Fahrten.

LEBENDIGE STRECKE

• Ein eigener Fahrdienstleiter disponiert die KI-Züge nach Fahrplan mit Zeitfenstern und stellt Weichen.

• KI-Züge mit laufenden Fahrzeugskripten: Stromabnehmer gehen hoch, Lichter schalten, Zielanzeigen zeigen ihr Ziel.

• Fahrgäste warten an den Bahnsteigen und steigen ein und aus; Türen und Aufenthaltszeiten wie im Original.

• Straßenverkehr nach den Verkehrsregeln der Straßen, der vor geschlossenen Bahnübergängen hält.

• 3D-Sound mit Entfernung, Richtung, Doppler und Dämpfung zwischen Führerstand und außen.

• Die Strecke wird beim Fahren im Hintergrund nachgeladen.

GRAFIK UND WETTER

• Physikalisch basierte Materialien: Die Shader des Spiels werden je Familie auf ein modernes Beleuchtungsmodell übertragen, mit Lack, Glas, Wasser und Innenräumen.

• Raytracing: Schatten, Umgebungsverdeckung und Spiegelungen (optional, auf geeigneten Grafikkarten).

• Fahrzeuglichter leuchten die Umgebung aus.

• Sonne und Mond stehen dort, wo sie am Ort der Strecke zur Uhrzeit des Szenarios wirklich stehen, mit echter Mondphase.

• Echtes Wetter: Auf Wunsch übernimmt NEXT das aktuelle Wetter vom nächstgelegenen Flughafen der Strecke.

• Volumetrische Wolken, Regen, Schnee und Gewitter; Regen auf den Scheiben mit laufenden Tropfen und Scheibenwischern; nasse Oberflächen, Pfützen und liegenbleibender Schnee.

• Hochskalierung mit NVIDIA DLSS (auch Ray Reconstruction) oder AMD FSR 1 / FSR 3, dazu Frame Generation.

• Fotomodus und Kopf-Tracking mit Tobii-Eye-Trackern.

KOMPATIBILITÄT

NEXT wird laufend gegen eine große Installation getestet. Beim letzten Durchlauf wurden 4.213 Fahrzeuge geprüft, lose und aus .ap-Archiven. 3.034 davon laufen ohne jeden Befund, und von 2.948 Lua-Skripten der Installation starten 2.922 fehlerfrei. Wo etwas nicht klappt, liegt es teils an NEXT und teils an den Inhalten selbst, etwa an fehlenden Basis-Paketen oder Skriptfehlern, die das Original stillschweigend übergeht.

WAS NOCH FEHLT

NEXT ist noch in Entwicklung. Unter anderem fehlen noch:

• im Editor: Linien-, Mal- und Szenario-Werkzeuge, 2D-Karte, Mehrfachauswahl

• eine detaillierte Druckluft- und E-Bremsen-Simulation, Schleudern

• einzelne Lok-Skripte, die Engine-Funktionen brauchen, die es noch nicht gibt

SYSTEMVORAUSSETZUNGEN

• Windows 10/11, 64 Bit

• Train Simulator Classic, installiert über Steam, mit euren Inhalten

• Grafikkarte mit Vulkan-Unterstützung; für Raytracing eine raytracingfähige Karte, für DLSS eine NVIDIA-RTX-Karte

SUPPORT

Bei Fragen oder Problemen mit NEXT bitte hier im Thread melden, nicht beim Kundendienst von Dovetail Games oder den Herstellern der Strecken und Fahrzeuge. Die können für NEXT nichts.

Für eine Fehlermeldung hilfreich: Version, Strecke, Lok bzw. Szenario, was passiert ist, und die Protokolldateien aus dem Datenordner. Den öffnet ihr im Launcher über Rechtliches › Support.

RECHTLICHES

NEXT ist ein unabhängiges Open-Source-Projekt (MIT- bzw. Apache-2.0-Lizenz) und nicht mit Dovetail Games verbunden. Es wird weder von Dovetail Games unterstützt noch genehmigt. „Train Simulator Classic“ und „RailWorks“ sind Namen bzw. Marken ihrer Inhaber. Alle Inhalte, die NEXT lädt und die in den Bildern zu sehen sind, gehören ihren jeweiligen Herstellern und sind nicht Teil von NEXT. NEXT sammelt keine Daten; die einzige Internetverbindung ist die optionale Wetterabfrage. Alle Lizenzen und Hinweise findet ihr im Launcher unter „Rechtliches“.

Ich freue mich auf eure Rückmeldungen!

freds.mods

Nein überhaupt nicht. Aber ich nutze ihn aktuell nicht weil er eher Dinge verschlimmbessert und leider extrem "ungeschickt" aufgebaut ist - gerade was die Shader betrifft.

Man hat leider keinerlei Vorschau was man eigentlich genau einstellt.

Ja bei mir sieht man direkt die Veränderungen im Spiel. Also quasi ein 1:1 Live UI.

Zitat von Trip Tucker

Klingt sehr interessant.

Eine Frage dazu. Wird es auch mit Vulkan (DXVK) funktionieren? Ich habe eine AMD Karte und da bringt mir Vulkan gegenüber DirectX ca. 25-50% mehr FPS. Auf diese FPS will ich nur ungern verzichten.

Ja, es läuft mit DX9 und mit Vulkan. Da ich selbst auch mit dem RW Enhancer normalerweise über Vulkan gehe.

Zitat von NBPE

Wunderbare Sache!

Ich finde den TSC immer noch in Hinblick auf Streckenvielfalt, Anzahl der Loks und dem Edtior, als Spitzenreiter unter den Eisenbahnsimulationen.

Schön das durch dein Tool daher die Grafik, das Ambiente und technische Möglichkeiten angehoben werden.

LG

Alles anzeigen

Ja, das ist richtig und genau das ist meine Intention. So viel breiten Content wie hier hast du in keinem TSW.

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.

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.

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.